Task processing method and system

Abstract

This application relates to the fields of artificial intelligence and data analysis technology, and discloses a task processing method and system. The method includes: acquiring user task text, wherein the user task text describes the target task to be completed; extracting multi-dimensional features from the user task text to obtain task features; using a pre-set link decision rule base and a lightweight routing model to perform link decision on the task features, determining the processing link type corresponding to the task features; processing the task features according to the processing link type to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units for completing the target task; and fusing the execution results of the multiple atomic tasks to obtain the task processing result. This method can improve the adaptability to complex tasks and ensure the processing quality of complex tasks.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and data analysis technology, and in particular to a task processing method and system. Background Technology

[0002] In the field of intelligent task orchestration and execution, user tasks have evolved from single-form to complex forms involving multiple steps, cross-types, and strong dependencies. In practical application scenarios, such as daily office scenarios, users need to quickly complete complex tasks such as "data crawling + analysis + report generation"; in life service scenarios, it can realize multi-tool linkage tasks such as "weather query + attraction recommendation + route planning"; and in professional analysis scenarios, it can support the autonomous generation of in-depth analysis reports with data visualization and trend prediction.

[0003] Traditional solutions extract basic task types using keywords and then execute them sequentially along a pre-defined fixed path. This approach suffers from the following technical problems: First, it lacks sufficient task parsing dimensions, only identifying basic types and keywords, making it difficult to accurately break down core features such as complexity and multi-dimensional tool requirements, leading to a mismatch between the processing path and task needs. Second, the path decision-making method is simplistic; using fixed rules makes it difficult to cover complex and varied task types and hinders fine-grained scheduling based on task complexity. Third, it lacks a fusion processing mechanism, failing to effectively integrate the execution results of multi-step tasks.

[0004] Therefore, how to accurately analyze the diverse and complex tasks of users, accurately allocate processing links, and integrate the task execution results according to the processing link type has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The embodiments of this application are intended to at least partially address one of the technical problems in the related art. To this end, embodiments of this application propose a task processing method, system, electronic device, and storage medium.

[0006] An embodiment of this application provides a task processing method, the method comprising: acquiring user task text, wherein the user task text is used to describe the target task to be completed; performing multi-dimensional feature extraction on the user task text to obtain task features; using a preset link decision rule base and a lightweight routing model to perform link decision on the task features to determine the processing link type corresponding to the task features; performing task processing on the task features according to the processing link type to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units for completing the target task; and performing fusion processing on the execution results of the multiple atomic tasks to obtain the task processing result.

[0007] In some embodiments, multi-dimensional feature extraction is performed on the user task text to obtain task features, including: calling a large language model based on a preset prompt template to parse the user task text and obtain task text parsing results; generating structured task features based on the task text parsing results, wherein the task features include task complexity, task type and tool requirement information, and the tool requirement information represents the tools required to perform the task.

[0008] In some embodiments, task types include text generation, tool invocation, and analysis / creation; task complexity includes a first complexity and a second complexity, wherein the complexity of the first complexity is lower than that of the second complexity; processing link types include fast execution links, tool collaboration links, and hierarchical planning links; a preset link decision rule base and a lightweight routing model are used to make link decisions on task features to determine the processing link type corresponding to the task features, including: when the task type is text generation and the complexity is the first complexity, the processing link type is determined to be a fast execution link; when the task type is tool invocation and the number of tools does not exceed a preset threshold, the processing link type is determined to be a tool collaboration link; when the task type is analysis / creation and / or the complexity is the second complexity, the processing link type is determined to be a hierarchical planning link; for cases not covered by the link decision rule base, supplementary decisions are made through a lightweight routing model.

[0009] In some embodiments, if the processing link type is a hierarchical planning link, the task features are processed according to the processing link type to obtain the execution results corresponding to multiple atomic tasks, including: decomposing the task features into objectives to generate a three-level task tree, wherein the three-level task tree includes a top-level objective, middle-level subtasks, and bottom-level atomic tasks; performing dependency resolution on the three-level task tree to generate a directed acyclic graph of tasks; and executing each atomic task sequentially according to the directed acyclic graph of tasks to obtain the execution results corresponding to multiple atomic tasks.

[0010] In some embodiments, if the processing link type is a tool collaboration link, task processing is performed on the task features according to the processing link type to obtain the execution results corresponding to multiple atomic tasks. This includes: parsing the tool requirement information in the task features to identify synthesizable tools, wherein synthesizable tools are tools that do not exist in the preset tool library and need to be generated when executing atomic tasks, wherein the preset tool library includes a session-level tool library; generating a tool call step list based on the synthesizable tools and preset tools in the preset tool library; synthesizing tool functions on the synthesizable tools according to the tool call step list to obtain synthesizable tools, testing the synthesizable tools in an isolation sandbox, and loading the synthesizable tools that pass the test into the session-level tool library; and performing task processing on the task features based on the synthesizable tools and preset tools to obtain the execution results corresponding to multiple atomic tasks.

[0011] In some embodiments, the execution results of multiple atomic tasks are fused to obtain a task processing result, including: fusing the execution results of the atomic tasks to obtain an initial fusion result; verifying the initial fusion result to obtain a verification result; scoring the initial fusion result based on the verification result; when the score is not lower than a preset threshold, determining that the verification is passed and outputting the fusion result as the task processing result; when the score is lower than the preset threshold, determining that the verification is failed and triggering a correction strategy.

[0012] In some embodiments, the correction strategy includes at least one of the following: triggering execution retry for execution layer verification failure; triggering route optimization for routing layer verification failure; generating a new three-level task tree based on the task directed acyclic graph and the cause of failure for planning layer defects, and re-executing task processing steps based on the new three-level task tree; and triggering manual intervention for persistent verification failure.

[0013] In some embodiments, a new three-level task tree is generated based on the task directed acyclic graph and the reasons for failure, and the task processing steps are re-executed based on the new three-level task tree, including: generating a new three-level task tree by calling a large language model based on the task directed acyclic graph, the reasons for failure, and a preset planning reflection template; parsing the new three-level task tree to generate a new task directed acyclic graph; comparing the new task directed acyclic graph with the original task directed acyclic graph to determine the newly added atomic tasks and the retained atomic tasks; skipping the already executed retained atomic tasks and executing the newly added atomic tasks based on the new task directed acyclic graph; and re-executing the result fusion and verification process.

[0014] In some embodiments, the atomic tasks are executed sequentially according to the directed acyclic graph of the task, including: performing dependency resolution on the directed acyclic graph of the task to generate an execution sequence; when there are mutually independent atomic tasks, packaging the mutually independent atomic tasks into parallel tasks; when there are atomic tasks with dependencies, serially sorting the atomic tasks with dependencies into serial tasks; selecting a thread pool for execution according to the parallel tasks, or selecting a linear queue for execution according to the serial tasks.

[0015] An embodiment of this application provides a task processing system, comprising: an acquisition module for acquiring user task text, wherein the user task text describes a target task to be completed; an extraction module for extracting multi-dimensional features from the user task text to obtain task features; a determination module for using a preset link decision rule base and a lightweight routing model to perform link decision on the task features and determine the processing link type corresponding to the task features; a first processing module for processing the task features according to the processing link type to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units for completing the target task; and a second processing module for fusing the execution results of the multiple atomic tasks to obtain a task processing result.

[0016] Embodiments of this application provide an electronic device, which includes: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, which are executed by the one or more processors to cause the one or more processors to implement the steps of the method of any of the above embodiments.

[0017] Embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method of any of the above embodiments.

[0018] Embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the method according to any of the above embodiments.

[0019] The solution provided in this application utilizes multi-dimensional feature extraction to deeply analyze task text, accurately decomposing core features such as complexity, multi-dimensional tool requirements, and output format constraints. This addresses the issues of insufficient task analysis dimensions and imprecise feature recognition, preventing output deviations from core requirements due to mismatches between processing link types and task needs. By combining a pre-defined link decision rule base with a lightweight routing model, dynamic and refined link decisions can be made based on task characteristics, overcoming the limitations of fixed rule decisions that are singular, unable to adapt to complex and varied task types, and unable to perform refined scheduling. Finally, by fusing the execution results of multiple atomic tasks, this method achieves systematic integration of multi-step task results, effectively solving the problem of a lack of result fusion mechanisms in the past, ensuring the continuity of the task processing process and the integrity of the results. Therefore, the solution provided in this application improves the automated processing capability of complex tasks and solves the problems of insufficient task analysis accuracy, poor decision adaptability, and low integration of multi-step results. Attached Figure Description

[0020] Figure 1A flowchart illustrating a task processing method provided in an embodiment of this application; Figure 2 A schematic diagram illustrating the collaborative operation of the core modules of the task processing method provided in the embodiments of this application; Figure 3 A schematic diagram of a task processing system provided in an embodiment of this application; Figure 4 A block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0022] In the field of intelligent task orchestration and execution, user tasks have evolved from single-form to complex forms involving multiple steps, cross-types, and strong dependencies. In practical application scenarios, such as daily office scenarios, users need to quickly complete complex tasks such as "data crawling + analysis + report generation"; in life service scenarios, it can realize multi-tool linkage tasks such as "weather query + attraction recommendation + route planning"; and in professional analysis scenarios, it can support the autonomous generation of in-depth analysis reports with data visualization and trend prediction.

[0023] Traditional task orchestration systems driven by fixed rules suffer from several critical technical challenges that urgently need to be addressed. These systems extract basic task types from keywords, match them to preset fixed links for sequential execution, support only preset tool calls and single model generation, and can only verify results through basic checks. They lack dynamic adjustment, tool synthesis, and closed-loop optimization capabilities.

[0024] From a specific pain point perspective, at the task parsing level, existing systems have limited feature extraction capabilities, only able to identify basic types and keywords. They struggle to accurately break down core features such as complexity, multi-dimensional tool requirements, and output format constraints, leading to a mismatch between the processing chain and task requirements, and outputs that deviate from the core demands. In the task planning and execution phase, the fixed-chain design lacks dynamic adaptability and cannot finely schedule tasks based on complexity. When faced with cross-type fusion tasks, it is difficult to integrate tool calls, code execution, and text generation processes, and it does not support dynamic tool synthesis and parallel execution, resulting in low processing efficiency. At the quality control level, the evaluation indicators are singular and closed-loop optimization is lacking. It can only perform basic format verification and does not adequately consider core dimensions such as accuracy and logical coherence. After failure, it only mechanically retryes, failing to accurately attribute issues such as routing errors and planning defects, and it cannot optimize models and processes through feedback.

[0025] From a causal perspective, the three root causes—insufficient task analysis dimensions, rigid and inflexible link design, and lack of feedback mechanisms—lead to the system's inability to accurately adapt to diverse needs, its difficulty in supporting the execution of complex tasks, and its weak autonomy and continuous optimization capabilities, resulting in limited implementation quality and efficiency.

[0026] This application aims to address the aforementioned shortcomings and overcome the limitations of existing systems in terms of adaptability, autonomy, and closed-loop optimization capabilities in complex scenarios. By constructing a multi-dimensional and precise task parsing and dynamic routing mechanism, a cross-type hierarchical planning framework supporting dynamic tool synthesis, and a full-link closed loop for task execution and feedback reflection, it achieves efficient task adaptation across dimensions such as complexity, tool dependencies, and output formats, ensuring high-quality implementation and meeting the complex task processing needs of scenarios such as office work, life services, and professional analysis.

[0027] Figure 1 This is a flowchart illustrating a task processing method provided in an embodiment of this application.

[0028] like Figure 1 As shown, the task processing method 100 provided in this application embodiment includes steps S110-S150.

[0029] Step S110: Obtain the user task text, wherein the user task text is used to describe the target task to be completed.

[0030] For example, the user task text is used to describe the target task to be completed. For example, it can be task text generated in the user's daily office, life service or professional analysis scenarios such as "write birthday wishes", "check the weather and recommend attractions", "crawl data from website A and analyze it".

[0031] Step S120: Perform multi-dimensional feature extraction on the user task text to obtain task features.

[0032] For example, a large language model can be invoked based on pre-designed prompts to extract multi-dimensional features from the user's task text, resulting in structured task features.

[0033] Step S130: Using a preset link decision rule base and lightweight routing model, link decisions are made on task characteristics to determine the processing link type corresponding to the task characteristics.

[0034] For example, the preset link decision rule base contains multiple rule types. For instance, after receiving the structured task features output in step S120, the task features can be analyzed to obtain the link decision results, which may include the processing link type.

[0035] Step S140: Based on the processing link type, perform task processing on the task characteristics to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are the execution units that complete the target task.

[0036] For example, a preset link decision rule base and a lightweight routing model are loaded. The preset link decision rule base may contain multiple link decision rules. If the link type being processed is a link type that conforms to rule 1, rule 1 is used in combination with the lightweight routing model to make a decision and obtain the execution results of multiple atomic tasks. If the link type being processed is a link type that conforms to rule 2, rule 2 is used in combination with the lightweight routing model to make a decision and obtain the execution results of multiple atomic tasks.

[0037] Step S150: The execution results of multiple atomic tasks are fused to obtain the task processing result.

[0038] The solution provided in this application utilizes multi-dimensional feature extraction to deeply analyze task text, accurately decomposing core features such as complexity, multi-dimensional tool requirements, and output format constraints. This addresses the issues of insufficient task analysis dimensions and imprecise feature recognition, preventing output deviations from core requirements due to mismatches between processing link types and task needs. By combining a pre-defined link decision rule base with a lightweight routing model, dynamic and refined link decisions can be made based on task characteristics, overcoming the limitations of fixed rule decisions that are singular, unable to adapt to complex and varied task types, and unable to perform refined scheduling. Finally, by fusing the execution results of multiple atomic tasks, this method achieves systematic integration of multi-step task results, effectively solving the problem of a lack of result fusion mechanisms in the past, ensuring the continuity of the task processing process and the integrity of the results. Therefore, the solution provided in this application improves the automated processing capability of complex tasks and solves the problems of insufficient task analysis accuracy, poor decision adaptability, and low integration of multi-step results.

[0039] Figure 2 A schematic diagram illustrating the collaborative operation of the core modules of the task processing method provided in the embodiments of this application.

[0040] In some embodiments of this application, multi-dimensional feature extraction is performed on the user task text to obtain task features, specifically including the following: Based on a pre-defined prompt template, a large language model is invoked to parse the user's task text, resulting in a task text parsing result. Based on this result, structured task features are generated, including task complexity, task type, and tool requirement information. The tool requirement information indicates the tools needed to perform the task.

[0041] Specifically, such as Figure 2As shown, when a user task is input into the system, it is first analyzed and processed by the route parser. The route parser acts as the ingress scheduling hub, parsing user task characteristics and allocating the optimal processing link, and dynamically optimizing the routing model based on downstream feedback. The route parser comprises three sub-modules: a task analyzer, a link decision maker, and a route adaptive learner.

[0042] In terms of module interaction, in the main process, the user task first enters the task analyzer for feature extraction. The extracted structured features are then sent to the link decision-maker for link type determination, outputting the target link. In the feedback flow, the lightweight feedback loop sends feedback signals to the route adaptive learner. The route adaptive learner updates the routing model based on the feedback signals and loads the updated model into the link decision-maker to achieve continuous model iteration.

[0043] The task analyzer is responsible for extracting multi-dimensional features from the user task text. The input to the task analyzer is the user task text, and the output is structured task features. The task analyzer receives the user task text, calls a large language model through a preset Prompt template, parses the task dimensionally, and outputs structured features.

[0044] The preset core prompt template could be something like this: "You are a task feature analysis expert. Please analyze the user task according to the following requirements: 1. Complexity: Low (single-round text generation), Medium (multiple tools / multiple steps), High (cross-type fusion); 2. Type: Text generation (no tool requirement), Tool invocation (tool linkage only), Analysis and creation (tool + text + code); 3. Tool requirements: Preset tool library: [weather_api (check weather), attraction_api (check attractions), route_api (check routes), code_exec_api (execute code)]; Synthesizeable tool types: [data_crawl (web crawling), data_calculate (complex calculation), data_format (format conversion)]. Please select from the preset tool library. If there is no match but it belongs to a synthesizable tool type, please mark it (e.g., [{"type": "synthesize", "need": ...]}} "data_crawl"}]), fill in [] completely irrelevantly; 4. Output format: specify the presentation format of the results (such as short sentences, paragraphs, tables, reports); 5. Core requirements: extract the user's most core needs (1 sentence). Please return the results in JSON format, without adding any additional explanations, user task: {user_task}".

[0045] In another embodiment, the task types include text generation type, tool invocation type, and analysis and creation type; the task complexity includes a first complexity and a second complexity, wherein the complexity of the first complexity is lower than that of the second complexity; the processing link types include fast execution link, tool collaboration link, and hierarchical planning link.

[0046] Using a pre-defined link decision rule base and a lightweight routing model, link decisions are made based on task characteristics to determine the processing link type corresponding to the task characteristics.

[0047] For example, please continue to refer to Figure 2 It can use a link decision-maker to receive structured task features output by the task analyzer, load a pre-defined link decision rule base and the latest version of the XGBoost lightweight routing model, and combine the rules and the model to make decisions. Details are as follows: When the task type is text generation and the complexity is at the lowest level (i.e., low complexity), the processing link type is determined to be a fast execution link. For example, if the task analyzer extracts a task type of text generation with a complexity at the lowest level (i.e., low complexity), then the link decision-maker determines the processing link type to be a fast execution link.

[0048] When the task type is a tool call type and the number of tools does not exceed a preset threshold, the processing link type is determined to be a tool collaboration link. For example, if the preset threshold is 5, and the task analyzer identifies that the number of tools required by the tool does not exceed the preset threshold of 5 or includes a composite tool, and the number of execution steps is less than or equal to 3, then the link decision-maker determines that the processing link type is a tool collaboration link.

[0049] When the task type is analysis / creation or the complexity is second-highest (i.e., high complexity), the processing link type is determined to be a hierarchical planning link. For example, if the task analyzer can extract a task type of analysis / creation, a complexity of second-highest (i.e., high complexity), or the number of tools exceeds a preset threshold, then the link decision-maker determines the processing link type to be a hierarchical planning link.

[0050] For cases not covered by the link decision rule base, a lightweight routing model is used for supplementary decision-making. The lightweight routing model supplements the decision for edge cases not covered by the rules and outputs the link type with a confidence level greater than or equal to 0.8.

[0051] As can be seen, the embodiments of this application provide a full-link closed-loop feedback and intelligent reflection mechanism. By making up for the shortcomings of existing systems that lack closed-loop optimization, it achieves accurate attribution of failure scenarios (execution layer / routing layer / planning layer) through a lightweight feedback loop, triggering execution retry, routing optimization or planning reflection, and improving iteration efficiency by combining a partial task reuse mechanism, thus ensuring continuous optimization of task output quality.

[0052] In another embodiment, please continue to refer to Figure 2 If the processing link type is a hierarchical planning link, the task is sent to the hierarchical planner for processing. The hierarchical planner is the central hub for decomposing complex tasks, supporting dynamic tool synthesis and planning reflection, and decomposing the top-level goal into an executable task tree and dependency graph. The hierarchical planner consists of three sub-modules: a goal decomposer, a dependency resolver, and a planning reflection and refactoring unit.

[0053] The hierarchical planning chain is suitable for scenarios that combine tools, text, and code, such as generating analytical reports with data visualization. A key optimization point in the hierarchical planning chain demonstration is triggering planning reflection upon planning failures.

[0054] The execution flow of hierarchical planning links is as follows: The user's task text is input into the route parser. The task analyzer in the route parser extracts task features. The extracted features are characterized as high complexity and type as analysis and creation. The link decision-maker determines the link to be hierarchical planning based on the task features.

[0055] The link decision-maker outputs the link results and sends them to the hierarchical planner. The target decomposer in the hierarchical planner receives the link results, calls the "hierarchical task template generator" of the Prompt manager to obtain the decomposed Prompt, performs target decomposition on the task features to generate a three-level task tree, and the dependency parser performs dependency parsing on the three-level task tree to convert it into a directed acyclic graph of tasks.

[0056] Specifically, the target decomposer receives the hierarchical planning link decision results and task characteristics, calls the hierarchical task template generator of the Prompt manager to obtain the decomposition prompt template, and injects it into the large language model to generate a three-level task tree.

[0057] like Figure 2 As shown, the Prompt Manager can generate adaptive Prompts for different links and types of tasks, supporting accurate output from LLM (Large Language Model) and tool executors. The Prompt Manager includes sub-modules such as a fast execution template generator, a tool invocation template generator, a hierarchical task template generator, a tool synthesis template generator, and a planning reflection template generator.

[0058] A hierarchical task template generator is used to adapt to hierarchical planning chains. The generator takes task tree node information as input, including node ID, level, type, and dependencies, and outputs a hierarchical Prompt. The process is as follows: it receives task tree node information, loads the corresponding hierarchical template libraries (top-level, middle-level, and bottom-level), injects dynamic parameters (including dependency data and node descriptions) based on the level, type, and dependencies in the node information, and generates a hierarchical Prompt. The top level emphasizes goal integration, the middle level emphasizes step implementation, and the bottom level emphasizes execution precision.

[0059] The core prompt template generated by the hierarchical task template generator is as follows: "You are a complex task decomposition expert and need to break down the top-level goal into a three-level task tree (top-level goal → middle-level sub-tasks → bottom-level atomic tasks), with the following rules: 1. Top-level goal: {top_goal}; 2. Middle-level sub-task decomposition rules: Decompose according to "process stages" (e.g., data collection, analysis, output), each middle-level task must cover a complete process stage, with 3-5 tasks; 3. Bottom-level atomic task decomposition rules: Each atomic task corresponds to only one type (text: pure analysis / creation; tool: only call one tool; code: only execute a piece of code); Tool requirements (important): Select from the preset tool library {tool_list}. If the tool does not exist but belongs to the synthesizable type [data_crawl, data_calculate], then it must be selected." A new atomic task, "Tool Synthesis" (type='code', description='Synthesize Web Crawler Tool'), must be added and used as a prerequisite for subsequent calls to this tool task; it cannot be further split (e.g., "Crawling Data + Cleaning Data" needs to be split into two atomic tasks); 4. Output format: JSON format, including task_id, top_goal, mid_tasks (including mid_task_id, description, sub_tasks), and sub_tasks (including atomic_task_id, type, description, and tool_requirements); 5. Example reference: {example_task_tree}; please strictly follow the splitting rules and do not add any additional explanations. The three-level task tree is sent to the dependency resolver to generate a directed acyclic graph (V1) of tasks. The directed acyclic graph (V1) of tasks is then sent to the task executor for execution. The task executor receives the directed acyclic graph (V1) of tasks output by the hierarchical planner.

[0060] In other embodiments, the atomic tasks are executed sequentially according to the directed acyclic graph of the tasks, including: performing dependency resolution on the directed acyclic graph of the tasks to generate an execution sequence; when there are mutually independent atomic tasks, packaging the mutually independent atomic tasks into parallel tasks; when there are atomic tasks with dependencies, serially sorting the atomic tasks with dependencies into serial tasks; selecting a thread pool for execution according to the parallel tasks, or selecting a linear queue for execution according to the serial tasks.

[0061] The task executor is the central execution terminal. It receives the task sequence after dependency resolution, schedules resources, selects the execution mode, and completes the execution of specific tasks. It includes two modules: a task scheduler executor and an atomic executor. The task scheduler executor includes three sub-modules: a dependency link resolver, an execution mode selector, and an executor allocator.

[0062] The dependency link resolver parses the directed acyclic graph (DAG) or tool dependency rules of the tasks, generating an "execution sequence" (parallel tasks are packaged, and serial tasks are ordered). The execution mode selector chooses the execution strategy based on the parallel or serial markers in the execution sequence, where parallel tasks are processed using a thread pool, and serial tasks are completed using a linear queue. The executor allocator then allocates tasks according to task type, assigning text, tool, or code tasks to the corresponding LLM executor, tool executor, or code executor for execution, respectively.

[0063] Please continue reading Figure 2 The atomic executor comprises three sub-modules: an LLM executor, a tool executor, and a code executor. The LLM executor receives prompts and context information and selects a model based on task complexity. Low-complexity tasks use lightweight models, while high-complexity tasks call larger models. After the model generates text results, the executor cleans up redundant content and outputs the final result. The code executor has two modes: execution mode and synthesis mode. In synthesis mode, the executor receives a tool synthesis task containing tool synthesis prompts generated by the prompt manager. The executor calls a large language model or a dedicated code generation model to generate the corresponding function code and test cases. These test cases are then executed in an isolated sandbox to verify the function's functionality. Upon successful testing, the function is dynamically loaded into the current task's session-level tool library for subsequent calls, and a synthesis success message and tool signature are ultimately output. In execution mode, the executor receives code snippets and environment parameters, runs the code in an isolated sandbox, intercepts dangerous operations during execution, and finally outputs the results, including data or chart paths and corresponding execution logs.

[0064] After processing by the atomic executor, the execution results corresponding to multiple atomic tasks are obtained.

[0065] In another embodiment, the execution results of multiple atomic tasks are fused to obtain the task processing result. For details, please refer to [link to previous document]. Figure 2 The atomic results output by the atomic executor are sent to the result aggregator, which consists of four sub-modules: a fast stitcher, a tool result integrator, a full aggregator, and a dependency validator. When handling hierarchical planning links, only the full aggregator and dependency validator sub-modules are needed in the module collaboration process.

[0066] The full aggregator receives atomic results and merges them from bottom to top. In the bottom-level aggregation stage, atomic task results are merged according to the dependency chain. In the middle-level integration stage, the results are sorted according to the top-level logic. In the conflict handling stage, differences are marked and the results are synthesized. In the format unification stage, the results are converted to the target format and packaged into an execution context for subsequent verification.

[0067] The aggregator then merges the execution results of the atomic tasks to obtain an initial fusion result. The initial fusion result is then sent to a lightweight feedback loop, where a full verifier verifies the initial fusion result to obtain a verification result.

[0068] The lightweight feedback loop is the central hub for end-to-end quality governance in the system. It is responsible for verifying execution results, attributing failure types, and triggering adjustment measures, including execution retries, route optimization, planning reflection, or manual intervention. The lightweight feedback loop comprises four sub-modules: a rapid validator, a tool result validator, a full validator, and a strategy adjuster. When processing hierarchical planning links, the full validator is used to determine the phenomena; when processing tool collaboration links or rapid execution links, the tool result validator and rapid validator are used respectively; and the strategy adjuster is shared across the entire link.

[0069] The full validator in the lightweight feedback loop is used to adapt the hierarchical planning link. The inputs to the full validator are the full aggregation result, the top-level goal, the task directed acyclic graph, the execution context packet, and the current retries. The output is the validation result or a failure report with a score. The full validator's process is as follows: it receives the initial fusion result, the top-level goal and the task directed acyclic graph; it evaluates the goal matching degree (score out of 100), logical consistency, data accuracy (e.g., error compared to official trends), and format completeness; and it outputs the validation result, with a score greater than or equal to 80 considered passing.

[0070] The failure scenarios and criteria for the full validator include the following: Low target matching (score below 80 points), indicating a missing top-level target element (e.g., a report lacking "3-year trend forecast"). Logical conflict, indicating contradictory module conclusions (e.g., data showing an increase but analysis stating a decrease). Insufficient data accuracy, indicating a tool or code result with an error greater than 5% compared to official data. Incomplete format, indicating failure to meet output format requirements (e.g., a PDF lacking charts or a table of contents). Planning layer defects, indicating low target matching or logical conflicts, with the root cause being a defect in the directed acyclic graph structure. Low confidence, indicating a score between 60-80 points, with usable but imperfect results. Continuous failure, indicating more than 3 retries on the same node due to insufficient data accuracy or other issues.

[0071] Based on the verification results, the system evaluates target matching degree, logical consistency, data accuracy, and format completeness, and outputs a score. If the score reaches a preset threshold, such as 80 points, the full validator determines that the verification has passed, and the initial output fusion result is used as the task processing result. If the verification fails and is determined to be a planning layer defect, such as a missing target, the full validator outputs a failure report, and the strategy adjuster triggers a correction strategy.

[0072] As can be seen, in the embodiments provided in this application, in order to address the shortcomings of the rigid fixed links in the existing system, a three-level decomposition mode of "top-level goal - middle-level sub-task - bottom-level atomic task" is constructed. This decomposes complex tasks into a manageable hierarchical structure and determines the execution order based on a directed acyclic graph, thereby realizing cross-type (tool + text + code) integrated tasks and achieving refined implementation of complex tasks.

[0073] In other embodiments, a new three-level task tree is generated based on the task directed acyclic graph and the reasons for failure, and the task processing steps are re-executed based on the new three-level task tree, including: generating a new three-level task tree by calling a large language model based on the task directed acyclic graph, the reasons for failure, and a preset planning reflection template; parsing the new three-level task tree to generate a new task directed acyclic graph; comparing the new task directed acyclic graph (V2) with the original task directed acyclic graph (V1) to determine the newly added atomic tasks and the retained atomic tasks; skipping the already executed retained atomic tasks and executing the newly added atomic tasks based on the new task directed acyclic graph; and re-executing the result fusion and verification process.

[0074] During the reflection process, the strategy adjuster calls the planning reflection and refactoring unit of the hierarchical planner to generate a new three-level task tree. The dependency parser then transforms it into a new task directed acyclic graph (V2) and resubmits it to the task executor for execution.

[0075] In another embodiment, the correction strategy includes at least one of the following: triggering execution retry for execution layer verification failure; triggering route optimization for routing layer verification failure; generating a new three-level task tree based on the task directed acyclic graph and the cause of failure for planning layer defects, and re-executing task processing steps based on the new three-level task tree; and triggering manual intervention for persistent verification failure.

[0076] The strategy adjuster is a shared decision-making component across the entire process. It receives failure reports from the validator, including the failure type and execution context, and outputs specific adjustment strategies, such as remapping parameters, re-executing tasks, optimizing prompts, and including retry parameters. Its decision-making process analyzes the failure type in the failure report and executes the corresponding decision logic to drive the process loop. For example, when the failure type is an execution-level failure, including tool call failure, parameter mapping error, or non-compliant format, the adjuster will trigger execution retries. Instructions: (Based on the specific error phenomenon in the FailedReport, select one or more of the following to execute) LLM re-execution: Send an instruction to the ExecutorPool to re-invoke the LLM (with an optimized Prompt if applicable). Prompt optimization: Send an instruction to the PromptManager to generate an optimized Prompt (e.g., adding length constraints) and return it to the ExecutorPool. Parameter remapping: Send an instruction to the ParameterMapper to correct the mapping rules and return it to the ToolExecutor. Tool re-execution: Send an instruction to the ExecutorPool to re-invoke the tool (changing to an alternative API, extending the timeout). Node re-execution: Sends a command to the ExecutorPool to re-execute the target atomic task and its dependent nodes. Result integration re-execution: Sends a command to the DynamicAggregator to supplement fields and then re-integrates the results.

[0077] For routing layer validation failure, the action is to trigger route optimization. The instruction (asynchronous) sends a "routing failure" signal (including task features) to the TaskRouter's route adaptive learner for the next iteration of the model. The instruction (synchronous) (optional) attempts to upgrade the current task's link (e.g., from "fast" to "hierarchical planning") and then re-executes, or simply returns failure.

[0078] For planning layer verification failure, the action is to trigger planning reflection. The instruction is to send a "planning failure" signal (including the original task directed acyclic graph and the reason for failure) to the HierarchicalPlanner's planning reflection and refactoring tool, and start the new task directed acyclic graph planning process.

[0079] For persistent validation failures or low confidence levels: Action: Trigger manual intervention. Instruction: Stop automatic retries. Package the "execution context package" provided by DynamicAggregator. Push the task (including context) to the "manual review queue". Suspend the task, awaiting manual instructions (e.g., approve output / reject and trigger planning reflection / release after manual correction).

[0080] The lightweight feedback loop accurately categorizes failure scenarios, automatically triggering corresponding strategies. The relevant modules then re-execute the task, followed by a second verification process to confirm success, thus achieving end-to-end self-correction. Each failure type is associated with a clearly defined responsible module and operational rules; for example, parameter errors correspond to a parameter mapper, and the operational rules cover retries and resource adjustments. This mechanism ensures a complete closed loop from task input to output, effectively improving the system's fault tolerance and output quality.

[0081] As can be seen, the embodiments of this application provide a multi-dimensional accurate parsing and dynamic routing mechanism, which can make up for the limitations of insufficient task parsing dimensions in existing systems. It achieves accurate task profiling through multi-dimensional feature extraction (complexity, type, tool requirements, etc.), allocates the optimal processing link by combining the hybrid decision logic of "rules + XGBoost model", and solves the link mismatch problem by realizing dynamic model iteration through a routing adaptive learner.

[0082] In one example, a user task could be: "Generate an analysis report on online fresh food sales in 2024, including the percentage of sales on each platform, quarterly trends, and Python visualization charts, and output a PDF."

[0083] The input to the routing resolution module is the user task text, and the output is (task analyzer): { "task_id": "T20251030007", "complexity": "high", "type": "Analysis and Creation", "tool_requirements": ["data_crawl_api", "code_exec_api"], "output_format": "PDF analysis report (including data tables, visualization charts, and analysis conclusions)", "core_demand": "Generates an online fresh food sales analysis report with data visualization" } Output (Link Decision Maker): { "route_type": "hierarchical planning link", "route_params": {"tool_list": ["data_crawl_api", "code_exec_api"]}, "task_id": "T20251030007" } The hierarchical planner (V1 planner) then takes the hierarchical planning link decision results as input and outputs (target decomposer - V1 task tree): { "task_id": "T20251105003", "top_goal": "Generate an analysis report on online fresh food sales in 2024", "mid_tasks": [ {"mid_task_id": "M1", "description": "Data Acquisition and Preprocessing", "sub_tasks":[ {"atomic_task_id": "A1", "type": "tool", "description": "calls data_crawl_api to crawl sales figures"}, {"atomic_task_id": "A2", "type": "code", "description": "Python data cleaning"} ]}, {"mid_task_id": "M2", "description": "Data Visualization and Analysis", "sub_tasks":[ {"atomic_task_id": "A3", "type": "code", "description": "Python generates platform percentage pie chart"}, {"atomic_task_id": "A4", "type": "code", "description": "Python generates quarterly trend line charts"}, {"atomic_task_id": "A5", "type": "text", "description": "LLM writing analysis conclusions"} ]}, {"mid_task_id": "M3", "description": "Report Generation", "sub_tasks": [ {"atomic_task_id": "A6", "type": "code", "description": "Integrating charts and text to generate PDF"} ]} ] } Output (depending on the resolver): Generate V1DAG(A1→A2,A2→[A3,A4,A5],[A3,A4,A5]→A6).

[0084] Task executor: Executes A1-A6 in V1DAG order; Input: Task DAG, Output (Atomic executor): A1: The tool executor calls data_crawl_api to crawl sales data.

[0085] A2: The code executor runs a Python script to clean the data.

[0086] A3: The code executor runs the visualization script, generates a pie chart, and returns the chart path.

[0087] A4: The code executor runs the visualization script, generates a line chart, and returns the chart path.

[0088] A5: The LLM executor calls GPT-4 to write the analysis conclusion text based on the A2 data.

[0089] A6: The code executor runs a script that integrates A5 text with A3 and A4 charts into a PDF.

[0090] The full aggregator in the results aggregator then generates a V1 PDF report (containing percentages and trends, but missing "forecasts") and packages it into an "execution context".

[0091] Finally, a lightweight feedback loop is used to output the following: If successful, the output (full validator) is: "Passed, score 90: Covers platform share, trends, visualization, and logical coherence"; if unsuccessful, the first execution plan reflection is conducted, with the following content: Full validator output (assuming the top-level objective implicitly includes prediction requirements): {"status":"Failure","failure_type":"Planning Layer Defect","error_type":"TargetMissError","message":"Report missing '2025 Trend Forecast'","score":70}.

[0092] Strategy Adjuster (Receives Planning Layer Defects): Triggers "Planning Reflection".

[0093] Output instructions: {"operation":"Planning Reflection","target_module":"Hierarchical Planner.Planning Reflection and Refactoring","params": {"FailedDAG":{...},"FailureReason":"Report missing '2025 trend forecast'","TopGoal":"..."} } Entering the reflection process, the hierarchical planner (V2 planner): the planning reflection and refactoring tool is invoked.

[0094] Call the PromptManager's planning reflection template to generate the V2 task tree in LLM: Add an atomic task A7 in M2: Python performs trend prediction based on A2 data (code), and modify the dependencies of A5 and A6.

[0095] The task executor (V2 execution) receives the V2DAG. The task scheduler executor analyzes the differences, skips the already executed A1, A2, A3, and A4, and re-executes A7 (new task), A5 (dependent on A7), and A6 (dependent on A7 and A5).

[0096] Results Aggregator (V2): The full aggregator generates a V2PDF report (including percentages, trends, and forecasts).

[0097] Perform a second verification: The full validator outputs: {"status":"Pass","score":95}, and returns the final result to the user.

[0098] In some embodiments of this application, if the processing link type is a tool collaboration link, task processing is performed on the task characteristics according to the processing link type to obtain the execution results corresponding to multiple atomic tasks, as follows: Please continue to refer to this. Figure 2 The execution flow of the tool collaboration link is as follows: The user's task text is input to the route parser. The task analyzer in the route parser extracts task features, including the type (tool call) and whether the tool list contains synthesizable tools. The link decision-maker determines whether it is a tool collaboration link based on these features. When the link decision-maker determines that the link type is a tool collaboration link, the task is sent to the tool scheduler for processing. The tool scheduler is the central hub for scheduling pure tool tasks, supporting dynamic tool synthesis. It breaks down tasks into tool call steps and handles parameter passing. The tool scheduler includes two sub-modules: a tool step and dependency generator, and a parameter mapper.

[0099] The tool requirement information in the task characteristics is analyzed to identify synthesizable tools. Synthesizable tools are those that do not exist in the preset tool library and need to be generated when the atomic task is executed. The preset tool library includes the session-level tool library.

[0100] Based on the synthesizable tools and the preset tools in the preset tool library, a list of tool invocation steps is generated. Specifically, the link decision-maker sends the link results to the tool scheduler. The tool step and dependency generator in the tool scheduler identifies synthesizable tools and automatically inserts a tool synthesis step at the beginning of the steps. The tool step and dependency generator receives the tool collaboration link decision results, calls the tool invocation template generator in the Prompt manager to obtain the step decomposition prompt template, and injects it into the large language model to generate a list of tool invocation steps.

[0101] The tool invocation step list includes step ID, tool name, parameter template, and execution order. The generated prompt template requires the large language model to generate steps according to the following rules: each step invokes one tool, explicitly defines fixed parameters and dynamic parameters extracted from previous steps, defines step dependencies to ensure logical coherence, and outputs the parameter template and output requirements for each step. The tool list is checked; if it contains composable tools, a tool composition step is automatically inserted at the beginning of the step list, pointing to the code executor.

[0102] The parameter mapper takes structured data from the tool scheduler's output and current tool parameter requirements (e.g., dynamic parameter rules and fixed parameters) as input. Its output consists of standardized parameters and a mapping log; the standardized parameters can be directly invoked by the tool. The parameter mapper's process is as follows: it receives the preceding tool output (structured data) and the current tool parameter requirements (dynamic parameter rules and fixed parameters), verifies the preceding output format, extracts and transforms dynamic parameters according to rules (e.g., "rain" → indoor=true), merges fixed parameters to generate a standardized parameter set (which can be directly invoked by the tool), and synchronously outputs the mapping log (for easy traceability).

[0103] The tool invocation template generator takes the following inputs: tool type, parameter requirements, and task scenario (e.g., "attraction recommendation with accompanying weather query"); and outputs a tool invocation specification Prompt (including parameter constraints, format requirements, and exception handling). The process involves receiving the tool type, parameter requirements, and task scenario; matching them with the tool's metadata dictionary (including parameter constraints and format requirements); adjusting the focus based on the scenario (e.g., "attraction recommendation" should emphasize precipitation probability); and generating the tool invocation specification Prompt (including dynamic parameter mapping rules and exception handling).

[0104] The core prompt template of the tool call template generator is as follows: "You are a tool call planning expert. You need to break down the tool list {tool_list} into ordered steps {top_goal}: 1. Each step calls one tool, specifying fixed parameters (e.g., city=Beijing) and dynamic parameters (to be extracted from previous steps and marked with {param}); 2. Define step dependencies (serial / parallel) to ensure logical coherence (e.g., check the weather first, then recommend attractions); 3. Output the parameter template and output requirements for each step (must include fields required by subsequent steps). Please generate a tool call step specification to guide parameter mapping and execution." The input to the tool synthesis template generator is the tool requirement to be synthesized in the task node (such as "crawl the title of {url}"); the output is a prompt that instructs the code executor to generate and verify the tool.

[0105] A core Prompt template is as follows: "You are a Python expert, please write a function (tool) to accomplish {function description}. Requirements: 1. Use only the following security libraries: [requests, beautifulsoup4, json, re]; 2. The function signature is: {function_signature} (e.g., defcrawl_titles( url:str)->list [str :); 3. Exception handling (such as try-except) must be included, and an empty list [] or None must be returned on failure; 4. Type validation of input parameters must be included.

[0106] 5. Include a simple unit test case (e.g., `assertcrawl_titles('http: / / example.com')isnotNone`). Please output the complete Python code block (including functions and test cases) directly, without adding any additional comments. The code executor generates and tests function code in an isolated sandbox, and registers the function to the session-level utility library of the current task after the test passes.

[0107] Based on synthesis tools and preset tools, task processing is performed on task features to obtain execution results corresponding to multiple atomic tasks. Specifically, the tool executor receives the tool name and standardized parameters, first looks for the synthesized tool in the session-level tool library, and if not found, looks for it in the global preset tool library. The tool is called through the adapter, the parameter format is verified, and the response result is converted to a unified structured format and then output. The parameter mapper receives the output of the previous tool and the parameter requirements of the current tool, extracts and converts the dynamic parameters, and generates standardized parameters.

[0108] The tool result integrator associates the execution results of the synthesis tool and the preset tool to generate natural language. The integration result is sent to the lightweight feedback loop, and the tool result validator verifies the integration result. If the verification passes, the result is output. If there are continuous failures, such as the synthesized tool fails, the tool result validator outputs a failure report, and the policy adjuster determines it as a continuous failure and triggers manual intervention.

[0109] In the embodiments provided in this application, by dynamically identifying synthesizable tools and testing the synthesis in an isolated sandbox, it supports the dynamic generation and registration of non-preset tools, expanding the tool invocation ability of the system.

[0110] In one example, the user task can be, for example: "Crawl the latest headline titles of 3 A websites (http: / / example-news.com), and then check the weather in City A tomorrow."

[0111] The input of the routing analysis model is the user task text, and the task analyzer outputs: { "task_id": "T20251105002", "complexity": "medium", "type": "tool invocation", "tool_requirements": {"type": "synthesize", "need": "data_crawl"}, "weather_api" , "output_format": "natural language paragraph", "core_demand": "Crawl A website headlines and check the weather" } The link decision maker outputs: { "route_type": "tool collaboration link", "route_params": {"tool_list": ["synthesize:data_crawl", "weather_api"]}, "task_id": "T20251105002" } The tool scheduler takes as input the tool collaboration chain decision result and outputs (tool steps and dependency generator). { "tool_steps": [ { "step_id": "S1", "tool_name": "code_exec_api", "mode": "synthesize", "params_template": { "description": "Create a web crawler tool to crawl the headlines of http: / / example-news.com", "function_signature": "def crawl_headlines(url: str, limit: int) ->list[str]:" } }, { "step_id": "S2", "tool_name": "crawl_headlines", "params_template": {"url": "http: / / example-news.com", "limit": 3} }, { "step_id": "S3", "tool_name": "weather_api", "params_template": {"city": "A city", "date": "tomorrow"} } ], "dependency_rules": {"execution_order": ["S1", "S2", "S3"]} }

[0112] Output (parameter mapper, based on S1 result): { "standardized_params": {"city": "A city", "indoor": true}, "mapping_log": "S1 weather is 'rain', mapping indoor=true" } After receiving the steps and parameters, the task executor begins execution. Step S1 is tool composition. The code executor is invoked in composition mode, calling the tool composition template generator in PromptManager to generate composition prompt templates. The crawl_headlines function is generated and tested in the isolation sandbox, and successfully registered to the session-level tool library. Step S2 is invoking the composition tool. The tool executor searches for the crawl_headlines function, finds it in the session-level tool library, executes the function, and returns a list of headlines ["Headline 1", "Headline 2", "Headline 3"]. Step S3 is invoking the preset tool. The tool executor searches for weather_api, finds it in the global tool library, executes the API, and returns weather information as sunny with a temperature of 10-15℃.

[0113] The result integrator receives the tool's step list and the results of each step as input. The tool result integrator associates the execution results of the synthesized tool and the preset tool, and outputs natural language as follows: The latest headlines on website A are Headline 1, Headline 2, and Headline 3; the weather in city A tomorrow is sunny with a temperature of 10-15℃.

[0114] The lightweight feedback loop receives and verifies the output of the result integrator. In a successful case, the tool result verifier outputs "verification passed," indicating that all tools were successfully called, parameter mappings were correct, and the result is complete. In a failed case, for example, if website A updates its anti-scraping mechanism, causing step S2's `crawl_headlines` to return an empty list (invalid result) after three consecutive retries, the tool result verifier outputs a failure status with the reason "invalid result," target step "S2," and 4 retries. Upon receiving the persistent failure signal, the strategy adjuster triggers manual intervention, outputs a manual intervention instruction, and suspends the task, awaiting a human engineer to repair the synthesis logic.

[0115] In some embodiments of this application, if the processing link type is a fast execution link, the task characteristics are processed according to the fast execution link type.

[0116] Please refer to Figure 2The fast execution chain is suitable for single-round text generation scenarios, such as birthday wishes and short question-and-answer sessions. The demonstration optimization of the fast execution chain is that execution failure is escalated to routing failure. The execution flow of the fast execution chain is as follows: The user's task text is input into the route parser. The task analyzer in the route parser extracts task features. The extracted features are of low complexity and are of the text generation type. The link decision-maker determines the link to be executed quickly based on the task features.

[0117] The link decision-maker outputs the link results to the Prompt Manager, where the fast execution template generator generates an adapted Prompt based on task features. The Prompt output from the Prompt Manager is then sent to the Task Executor, where the LLM executor selects a lightweight model and calls the large language model to generate the text results. Finally, the text results output from the Task Executor are sent to the Result Integrator, where the fast stitcher performs fine-tuning of the text format and the validator confirms the completeness of the results.

[0118] The aggregated result from the aggregator is sent to the lightweight feedback loop, where the fast validator checks the format and core requirements. If the validation passes, the final result is output. If the validation fails, for example, due to a mismatch in core requirements, the policy adjuster determines that the execution has failed and triggers a prompt for optimization and retry. If multiple retries still fail, the fast validator determines that the routing layer has failed, and the policy adjuster triggers routing optimization.

[0119] In one example, the user task is: "Write a birthday greeting of no more than 30 words to a good friend, that is both humorous and sincere."

[0120] The route resolver receives the user's task text; the task analyzer outputs: { "task_id": "T20251030005", "complexity": "low", "type": "Text generation", "tool_requirements": [], "output_format": "Short, colloquial sentences of 30 characters or less", "core_demand": "A humorous and sincere birthday wish for a close friend." } Link decision-maker output: {"route_type":"Fast execution link","route_params":{},"task_id":"T20251030005"}.

[0121] The Prompt Manager takes as input: Quick Link Task Characteristics; and outputs (Quick Execution Template Generator): "You are a social copywriting expert and need to write a birthday greeting for a good friend: Style = Humor (making fun of age without being awkward) + Sincerity, length ≤ 30 characters, avoid formal clichés. Directly output the text." The task executor receives the prompt, and the LLM executor calls a large model such as Llama-2-7B to generate the text result: "My old partner has grown another year older, his wallet is getting fatter, happiness is overflowing, happy birthday haha."

[0122] The integrator receives the LLM results and output format requirements. After fine-tuning the format of the fast stitcher's output, the result is: "My old partner is another year older, his wallet is bulging, happiness is overflowing, happy birthday! (fine-tuning the punctuation)."

[0123] A lightweight feedback loop validates the integration result. In a successful case, the fast validator checks for humor combined with sincerity and within 30 characters, outputs "pass," and returns the final result to the user. In a failed case, the fast validator checks for non-compliance, and on the first failure, the fast validator outputs (assuming the LLM result is not humorous): {"status":"failure","error_type":"CoreNeedMissError","message":"humor not reflected","retry_count":1}. The policy adjuster (receiving execution layer failures) triggers "execution retry."

[0124] Output instructions: {"operation":"Prompt optimization","target_module":"PromptManager","params":{"Supplementary constraints":"Add humorous expressions that tease about age"}} The second execution, the quick verifier outputs (still not humorous, and retry_count > 2): {"status":"Failure","failure_type":"Route layer failure","error_type":"CoreNeedMissError","message":"No humor","retry_count":2}. The policy adjuster (receiving route layer failure): triggers "Route Optimization". Output instructions (asynchronous): {"operation":"Route Optimization","target_module":"Route resolver.Route adaptive learner","params":{"TaskFeatures":{...},"FailedLink":"Quick execution"}}. Output instructions (synchronous): Returns failure to the user, or attempts to escalate the task to "Hierarchical Planning Link" for re-execution.

[0125] Based on the above embodiments, it can be understood that the solution provided by this application can support a hierarchical planning framework for dynamic tool synthesis. In response to the rigidity of fixed links in existing systems, it constructs a three-level decomposition mode of "top-level goal - middle-level sub-task - bottom-level atomic task", supports dynamic synthesis and session-level registration of non-preset tools, adapts to cross-type (tool + text + code) fusion tasks, and realizes the refined implementation of complex tasks.

[0126] Figure 3 This is a schematic diagram of a task processing system provided in an embodiment of this application.

[0127] like Figure 3 As shown, the task processing system 300 provided in this application includes: The acquisition module 310 acquires user task text, wherein the user task text is used to describe the target task to be completed.

[0128] The extraction module 320 is used to extract multi-dimensional features from the user task text to obtain task features.

[0129] The determination module 330 is used to perform link decision on the task characteristics using a preset link decision rule base and a lightweight routing model, and determine the processing link type corresponding to the task characteristics.

[0130] The first processing module 340 is used to perform task processing on the task characteristics according to the processing link type to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units that complete the target task.

[0131] The second processing module 350 is used to fuse the execution results of multiple atomic tasks to obtain the task processing result.

[0132] In some embodiments, the extraction module 320 is further configured to: invoke a large language model based on a preset prompt template to parse the user task text and obtain the task text parsing result; and generate structured task features based on the task text parsing result, wherein the task features include task complexity, task type and tool requirement information, and the tool requirement information represents the tools required to perform the task.

[0133] In some embodiments, task types include text generation, tool invocation, and analysis / creation; task complexity includes a first complexity and a second complexity, wherein the complexity of the first complexity is lower than that of the second complexity; processing link types include fast execution link, tool collaboration link, and hierarchical planning link; the determining module 330 is further configured to: determine the processing link type as a fast execution link when the task type is text generation and the complexity is the first complexity; determine the processing link type as a tool collaboration link when the task type is tool invocation and the number of tools does not exceed a preset threshold; determine the processing link type as a hierarchical planning link when the task type is analysis / creation and / or the complexity is the second complexity; and for cases not covered by the link decision rule base, supplementary decisions are made through a lightweight routing model.

[0134] In some embodiments, if the processing link type is a hierarchical planning link, the first processing module 340 is further configured to: decompose the task features into objectives and generate a three-level task tree, wherein the three-level task tree includes a top-level objective, a middle-level subtask, and a bottom-level atomic task; perform dependency resolution on the three-level task tree to generate a directed acyclic graph of tasks; and execute each atomic task sequentially according to the directed acyclic graph of tasks to obtain the execution results corresponding to multiple atomic tasks.

[0135] In some embodiments, if the processing link type is a tool collaboration link, the first processing module 340 is further configured to: parse the tool requirement information in the task characteristics, identify synthesizable tools, wherein synthesizable tools are tools that do not exist in the preset tool library and need to be generated when executing atomic tasks, wherein the preset tool library includes a session-level tool library; generate a tool call step list based on the synthesizable tools and preset tools in the preset tool library; synthesize tool functions on the synthesizable tools according to the tool call step list to obtain synthesizable tools, test the synthesizable tools in an isolation sandbox, load the synthesizable tools that pass the test into the session-level tool library; and perform task processing on the task characteristics based on the synthesizable tools and preset tools to obtain the execution results corresponding to multiple atomic tasks.

[0136] In some embodiments, the second processing module 350 is further configured to: perform fusion processing on the execution results of the atomic tasks to obtain an initial fusion result; verify the initial fusion result to obtain a verification result; score the initial fusion result based on the verification result; when the score is not lower than a preset threshold, determine that the verification is passed and output the fusion result as the task processing result; when the score is lower than the preset threshold, determine that the verification is failed and trigger a correction strategy.

[0137] In some embodiments, the second processing module 350 is further configured to: trigger execution retry for execution layer verification failure; trigger route optimization for routing layer verification failure; generate a new three-level task tree based on the directed acyclic graph of the task and the cause of failure for planning layer defects, and re-execute the task processing steps based on the new three-level task tree; and trigger manual intervention for persistent verification failure.

[0138] In some embodiments, the task processing system 300 further includes an adjustment module, which is used to: generate a new three-level task tree by calling a large language model based on the task directed acyclic graph, failure reasons, and a preset planning reflection template; parse the new three-level task tree to generate a new task directed acyclic graph; compare the new task directed acyclic graph with the original task directed acyclic graph to determine the newly added atomic tasks and the retained atomic tasks; skip the already executed retained atomic tasks and execute the newly added atomic tasks based on the new task directed acyclic graph; and re-execute the result fusion and verification process.

[0139] In some embodiments, the task processing system 300 further includes a parsing module, which is used to: perform dependency parsing on the directed acyclic graph of tasks to generate an execution sequence; when there are mutually independent atomic tasks, package the mutually independent atomic tasks into parallel tasks; when there are atomic tasks with dependencies, serially sort the atomic tasks with dependencies into serial tasks; and select a thread pool for execution based on the parallel tasks, or select a linear queue for execution based on the serial tasks.

[0140] It is understandable that a detailed description of the task processing system 300 can be found in the description of the task processing method above.

[0141] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0142] This application provides a computer program product that includes instructions that, when executed by a processor of a computer device, enable the computer device to perform the steps of the method described in any of the above embodiments.

[0143] Figure 4 A block diagram of an electronic device provided in an embodiment of this application.

[0144] This application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method in any of the above embodiments.

[0145] like Figure 4 As shown, for ease of understanding, embodiments of this application illustrate a specific electronic device 400.

[0146] Electronic device 400 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. Electronic device 400 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.

[0147] like Figure 4 As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 402 or a computer program loaded from storage unit 408 into random access memory (RAM) 403. RAM 403 may also store various programs and data required for the operation of electronic device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0148] Multiple components in electronic device 400 are connected to I / O interface 405. These components include: input unit 406, such as a keyboard or mouse; output unit 407, such as various types of displays or speakers; storage unit 408, such as a disk or optical disk; and communication unit 409, such as a network interface card (NIC), modem, or wireless transceiver. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0149] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 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 401 performs the various methods described above. For example, in some embodiments, any one or more of the methods described above can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of any one or more of the methods described above can be performed. Alternatively, in other embodiments, the computing unit 401 can be configured to perform any one or more of the methods described above by any other suitable means (e.g., by means of firmware).

[0150] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this application, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0151] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0152] In the description of this application, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0153] In the description of this application, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential", etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0154] Furthermore, the terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance, or implicitly specifying the number of technical features indicated in this embodiment. Therefore, features defined with terms such as "first" and "second" in the embodiments of this application can explicitly or implicitly indicate that the embodiment includes at least one of those features. In the description of this application, the word "multiple" means at least two or more, such as two, three, four, etc., unless otherwise explicitly and specifically defined in the embodiments.

[0155] In this application, unless otherwise explicitly specified or limited in the embodiments, the terms "installation," "connection," "joining," and "fixing" appearing in the embodiments should be interpreted broadly. For example, a connection can be a fixed connection, a detachable connection, or an integral part; it can also be a mechanical connection, an electrical connection, etc. Of course, it can also be a direct connection, or an indirect connection through an intermediate medium, or it can be the internal communication between two components, or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific implementation.

[0156] In this application, unless otherwise expressly specified and limited, "above" or "below" the second feature can mean that the first feature is in direct contact with the second feature, or that the first feature is in indirect contact with the second feature through an intermediate medium. Furthermore, "above," "on top of," and "over" the second feature can mean that the first feature is directly above or diagonally above the second feature, or simply that the first feature is at a higher horizontal level than the second feature. "Below," "below," and "under" the second feature can mean that the first feature is directly below or diagonally below the second feature, or simply that the first feature is at a lower horizontal level than the second feature.

Claims

1. A task processing method, characterized in that, The method includes: Obtain user task text, wherein the user task text is used to describe the target task to be completed; Multi-dimensional feature extraction is performed on the user task text to obtain task features; Using a pre-defined link decision rule base and a lightweight routing model, link decisions are made on the task characteristics to determine the processing link type corresponding to the task characteristics; Based on the processing link type, the task characteristics are processed to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units that complete the target task; The execution results of multiple atomic tasks are fused to obtain the task processing result.

2. The method according to claim 1, characterized in that, The step of extracting multi-dimensional features from the user task text to obtain task features includes: Based on the preset prompt template, the large language model is invoked to parse the user task text and obtain the task text parsing result; Based on the task text parsing results, a structured task feature is generated, wherein the task feature includes task complexity, task type, and tool requirement information, and the tool requirement information represents the tools required to perform the task.

3. The method according to claim 2, characterized in that, The task types include text generation, tool invocation, and analysis-based creation; the task complexity includes a first complexity and a second complexity, wherein the first complexity is less complex than the second complexity; the processing chain types include a fast execution chain, a tool collaboration chain, and a hierarchical planning chain. The step of using a preset link decision rule base and a lightweight routing model to perform link decision-making on the task characteristics and determine the processing link type corresponding to the task characteristics includes: When the task type is the text generation type and the complexity is the first complexity, the processing link type is determined to be the fast execution link; When the task type is the tool call type and the number of tools does not exceed a preset threshold, the processing link type is determined to be the tool collaboration link; When the task type is the analysis and creation type and / or the complexity is the second complexity, the processing link type is determined to be the hierarchical planning link; For cases not covered by the link decision rule base, supplementary decisions are made through the lightweight routing model.

4. The method according to claim 3, characterized in that, If the processing link type is the hierarchical planning link, the task processing based on the processing link type to obtain the execution results corresponding to multiple atomic tasks includes: The task characteristics are decomposed to generate a three-level task tree, wherein the three-level task tree includes a top-level target, a middle-level sub-task, and a bottom-level atomic task. Dependency resolution is performed on the three-level task tree to generate a directed acyclic graph of tasks; Based on the directed acyclic graph of the task, each of the atomic tasks is executed sequentially to obtain the execution results corresponding to the multiple atomic tasks.

5. The method according to claim 3, characterized in that, If the processing link type is the tool collaboration link, the step of processing the task characteristics according to the processing link type to obtain the execution results corresponding to multiple atomic tasks includes: The tool requirement information in the task characteristics is parsed to identify synthesizable tools. The synthesizable tools are tools that do not exist in the preset tool library and need to be generated when the atomic task is executed. The preset tool library includes a session-level tool library. Based on the synthesizable tools and the preset tools in the preset tool library, generate a tool call step list; According to the tool call step list, the synthesizable tool is synthesized using tool functions to obtain a synthesized tool. The synthesized tool is then tested in an isolation sandbox, and the synthesized tool that passes the test is loaded into the session-level tool library. Based on the synthesis tool and the preset tool, the task features are processed to obtain the execution results corresponding to multiple atomic tasks.

6. The method according to claim 4, characterized in that, The process of fusing the execution results of multiple atomic tasks to obtain a task processing result includes: The execution results of the atomic tasks are fused to obtain an initial fusion result; The initial fusion result is verified to obtain the verification result; The initial fusion result is scored based on the verification result. When the score is not lower than a preset threshold, the verification is deemed successful and the fusion result is output as the task processing result. When the score is lower than the preset threshold, the verification is deemed to have failed and a correction strategy is triggered.

7. The method according to claim 6, characterized in that, The correction strategy includes at least one of the following: If the execution layer verification fails, trigger an execution retry. If the routing layer verification fails, route optimization is triggered. To address the deficiencies in the planning layer, a new three-level task tree is generated based on the directed acyclic graph of the task and the reasons for failure, and the task processing steps are re-executed based on the new three-level task tree. For persistent verification failures, manual intervention is triggered.

8. The method according to claim 7, characterized in that, The step of generating a new three-level task tree based on the directed acyclic graph of the task and the reasons for failure, and re-executing the task processing steps based on the new three-level task tree, includes: Based on the directed acyclic graph of the task, the reasons for failure, and the preset planning reflection template, the new three-level task tree is generated by calling the large language model; The new three-level task tree is parsed to generate a new directed acyclic graph of tasks; Compare the new task directed acyclic graph with the original task directed acyclic graph to determine the newly added atomic tasks and the retained atomic tasks; Skip the already executed reserved atomic tasks and execute the newly added atomic tasks based on the new task directed acyclic graph; Re-execute the result fusion and verification process.

9. The method according to claim 4, characterized in that, The step of sequentially executing each atomic task according to the directed acyclic graph of the task includes: Dependency resolution is performed on the directed acyclic graph of the task to generate an execution sequence; When there are independent atomic tasks, these independent atomic tasks are packaged into parallel tasks. When there are atomic tasks with dependencies, the atomic tasks with dependencies are sequentially ordered into serial tasks. The parallel task is executed by selecting a thread pool, or the serial task is executed by selecting a linear queue.

10. A task processing system, characterized in that, The system includes: The acquisition module acquires user task text, wherein the user task text is used to describe the target task to be completed; The extraction module is used to extract multi-dimensional features from the user task text to obtain task features; The determination module is used to perform link decision on the task characteristics using a preset link decision rule base and a lightweight routing model, and determine the processing link type corresponding to the task characteristics; The first processing module is used to process the task characteristics according to the processing link type to obtain the execution results of multiple atomic tasks, wherein the multiple atomic tasks are execution units that complete the target task; The second processing module is used to fuse the execution results of multiple atomic tasks to obtain the task processing result.

Images