Task processing method and device, electronic equipment and storage medium

Abstract

The present disclosure relates to a task processing method and device, electronic equipment and storage medium. The method comprises: analyzing a task execution request input for a target task, determining a task execution template of the target task; generating a task execution plan of the target task according to the task execution template of the target task; selecting a primary model and at least one backup model from a candidate model set according to a task scene type indicated by the task execution template, obtaining a model call set of the target task, and creating an isolated execution environment according to a task running configuration indicated by the task execution template, and injecting a task context of the target task into the isolated execution environment; scheduling the target model in the model call set to execute the target task based on the isolated execution environment according to the task execution plan; and obtaining target delivery information responding to the task execution request according to the task execution result of the target task. The present disclosure can improve the task processing efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of artificial intelligence technology, and in particular to a task processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the development of large language models, tool invocation frameworks, and cloud-native runtime technologies, intelligent agent systems are beginning to be applied to office automation scenarios such as code generation, data research, report generation, and PPT generation. These scenarios are usually not single-round question-and-answer sessions, but require the model to combine external tools, execution environment, and intermediate states to continuously complete task decomposition, inference decision-making, program execution, result correction, and final delivery. This places high demands on the task execution efficiency of intelligent agent systems.

[0003] Traditional technologies typically employ a general agent framework layered with external tools to automate tasks. These solutions often rely on manually composing prompts and code logic to adapt to different task scenarios. This adaptation often depends on manual customization, resulting in relatively poor reusability. Consequently, the task execution results output by the intelligent agent system are not of stable quality, which is detrimental to improving the task execution efficiency of the intelligent agent system.

[0004] Therefore, traditional intelligent agent systems suffer from low task execution efficiency. Summary of the Invention

[0005] This disclosure provides a task processing method, apparatus, electronic device, and storage medium to at least address the problem of low task execution efficiency in related technologies' intelligent agent systems. The technical solution of this disclosure is as follows:

[0006] According to a first aspect of the present disclosure, a task processing method is provided, comprising:

[0007] Analyze the task execution request input for the target task to determine the task execution template for the target task;

[0008] Based on the task execution template of the target task, a task execution plan for the target task is generated; the task execution plan is used to indicate multiple sub-tasks for implementing the target task, and the dependencies between each sub-task; the sub-tasks include at least one of model inference tasks or tool invocation tasks;

[0009] Based on the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from the candidate model set to obtain the model call set of the target task. In addition, based on the task running configuration indicated by the task execution template, an isolated execution environment is created, and the task context of the target task is injected into the isolated execution environment.

[0010] According to the task execution plan, the target model in the model invocation set is scheduled to execute the model inference task in the subtask, and the target tool in the isolated execution environment is driven to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task.

[0011] Based on the task execution results of the multiple sub-tasks, the target delivery information in response to the task execution request is obtained.

[0012] In one possible implementation, parsing the task execution request input for the target task and determining the task execution template for the target task includes:

[0013] Analyze the task execution request to determine the task semantic features of the task execution request;

[0014] Based on the semantic features of the task, determine the task scenario type to which the target task belongs;

[0015] Among multiple candidate scene templates in the preset scene template library, a target scene template that matches the task scene type is determined and used as the task execution template for the target task.

[0016] In one possible implementation, the step of selecting a primary model and at least one backup model from a set of candidate models based on the task scenario type indicated by the task execution template, to obtain the model invocation set for the target task, includes:

[0017] Obtain the model capability requirements that match the task scenario type, and determine the quantitative indicators of the model capability of each candidate model in the candidate model set in response to the model capability requirements;

[0018] Obtain the real-time resource status of each candidate model, and select the primary model and at least one backup model from among the candidate models based on the real-time resource status and the model capability quantification index, thereby obtaining the model call set.

[0019] In one possible implementation, scheduling the target model in the model invocation set to execute the model inference task in the subtask according to the task execution plan includes:

[0020] When the target model is the primary model, obtain the task processing status of the primary model when performing the model inference task;

[0021] In response to the primary model's task processing state being a preset switching state, the backup model is switched to continue executing the model inference task.

[0022] The preset switching states include: inference request response timeout, inference task execution failure, or model inference result not meeting preset constraints.

[0023] In one possible implementation, switching the backup model to continue performing the model inference task includes:

[0024] Obtain the task context of the target task before switching to the backup model;

[0025] The task context is trimmed to obtain a trimmed task context; the trimmed task context includes at least the execution output of the completed subtasks.

[0026] The truncated task context is input into the backup model to trigger the backup model to continue executing the model inference task.

[0027] In one possible implementation, where the target task includes a front-end page generation task or a web application generation task, the method further includes:

[0028] Scan the process listening status within the isolated execution environment to identify at least two service ports that are in a listening state;

[0029] For each of the service ports, a proxy access entry is established for the service port; the proxy access entry is used to establish an access route from outside the isolated execution environment to the service port.

[0030] In one possible implementation, the method further includes:

[0031] During the execution of the plurality of sub-tasks, the task execution description information corresponding to the plurality of sub-tasks is recorded;

[0032] Based on the task execution description information, a task status view of the target task is generated.

[0033] In one possible implementation, the method further includes:

[0034] After the execution of the plurality of subtasks is completed, at least one of the following operations is performed on the isolated execution environment: resource reclamation or instance destruction.

[0035] According to a second aspect of the present disclosure, a task processing apparatus is provided, comprising:

[0036] The parsing unit is configured to parse the task execution request input for the target task and determine the task execution template of the target task;

[0037] The generation unit is configured to generate a task execution plan for the target task based on a task execution template for the target task; the task execution plan is used to indicate multiple sub-tasks for implementing the target task, and the dependencies between the sub-tasks; the sub-tasks include at least one of model inference tasks or tool invocation tasks;

[0038] The selection unit is configured to perform the following actions according to the task scenario type indicated by the task execution template: select a primary model and at least one backup model from a set of candidate models, obtain a set of model calls for the target task, and create an isolated execution environment according to the task execution configuration indicated by the task execution template, and inject the task context of the target task into the isolated execution environment.

[0039] The execution unit is configured to execute, according to the task execution plan, schedule the target model in the model invocation set to execute the model inference task in the subtask, and drive the target tool in the isolated execution environment to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task;

[0040] The delivery unit is configured to obtain target delivery information in response to the task execution request based on the task execution results of the plurality of subtasks.

[0041] According to a third aspect of the present disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the task processing method as described in the first aspect or any possible implementation thereof.

[0042] According to a fourth aspect of the present disclosure, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the task processing method as described in the first aspect or any possible implementation thereof.

[0043] According to a fifth aspect of the present disclosure, a computer program product is provided, the program product comprising a computer program stored in a readable storage medium, wherein at least one processor of a device reads from the readable storage medium and executes the computer program, causing the device to perform the task processing method described in the first aspect or any possible implementation thereof.

[0044] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: by parsing the task execution request input for the target task, the task execution template of the target task is determined, and a task execution plan for the target task is generated according to the task execution template; wherein, the task execution plan is used to indicate multiple sub-tasks for implementing the target task, and the dependencies between each sub-task; the sub-tasks include at least one of model inference tasks or tool invocation tasks; then, by selecting a primary model and at least one backup model from the candidate model set according to the task scenario type indicated by the task execution template, the model invocation set of the target task is obtained; and, according to the task running configuration indicated by the task execution template, an isolated execution environment is created, and the task context of the target task is injected into the isolated execution environment; and then, the model invocation set is scheduled according to the task execution plan. The target model executes the model inference task in the subtask, and drives the target tool in the isolated execution environment to execute the corresponding tool invocation task based on the model inference result of the model inference task. Thus, based on the task execution results of multiple subtasks, the target delivery information responding to the task execution request is obtained. This allows the intelligent agent system to selectively switch the task execution template that matches the task scenario type of the target task based on different task types of the task execution request without customizing it case by case. This improves the adaptation efficiency and output stability of multi-scenario tasks. At the same time, by configuring at least one backup model for the primary model, redundancy is provided for the stable execution of long-link tasks. The tool invocation task is executed in the isolated execution environment, effectively ensuring both security isolation and execution efficiency, thereby effectively improving the task execution efficiency of the intelligent agent system.

[0045] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0047] Figure 1 This is an application environment diagram illustrating a task processing method according to an exemplary embodiment.

[0048] Figure 2 This is a flowchart illustrating a task processing method according to an exemplary embodiment.

[0049] Figure 3 This is a flowchart illustrating another task processing method according to an exemplary embodiment.

[0050] Figure 4This is an architecture diagram of a task processing system according to an exemplary embodiment.

[0051] Figure 5 This is a flowchart illustrating a scenario template assembly and agent orchestration process according to an exemplary embodiment.

[0052] Figure 6 This is a schematic diagram illustrating multi-model switching and fault-tolerant recovery according to an exemplary embodiment.

[0053] Figure 7 This is a diagram illustrating an integrated sandbox and Web IDE architecture according to an exemplary embodiment.

[0054] Figure 8 This is a schematic diagram illustrating a multi-port preview proxy and path adaptation according to an exemplary embodiment.

[0055] Figure 9 This is a schematic diagram illustrating link observability and problem backtracking according to an exemplary embodiment.

[0056] Figure 10 This is a block diagram illustrating a task processing apparatus according to an exemplary embodiment.

[0057] Figure 11 This is a structural block diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

[0058] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0059] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure.

[0060] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0061] The task processing method provided in this disclosure can be applied to, for example, Figure 1In the application environment shown, the task processing system 102 communicates with the cloud 104 via a network. The data storage system can store the data that the cloud 104 needs to process. The data storage system can be integrated into the cloud 104, or it can be placed on the cloud or other network servers.

[0062] The task processing system 102 can parse the task execution request input for the target task and determine the task execution template of the target task. Based on the task execution template, the task processing system 102 can generate a task execution plan for the target task. The task execution plan indicates multiple sub-tasks for implementing the target task and the dependencies between each sub-task. The sub-tasks include at least one of model inference tasks or tool invocation tasks. Based on the task scenario type indicated by the task execution template, the task processing system 102 selects a primary model and at least one backup model from a set of candidate models to obtain a model invocation set for the target task. Based on the task execution configuration indicated by the task execution template, it creates an isolated execution environment and injects the task context of the target task into the isolated execution environment. The task processing system 102 can schedule the target model in the model invocation set to execute the model inference task in the sub-task according to the task execution plan, and drive the target tool in the isolated execution environment to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task. Based on the task execution results of the multiple sub-tasks, the task processing system 102 can obtain target delivery information responding to the task execution request.

[0063] Among them, cloud 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0064] Figure 2 This is a flowchart illustrating a task processing method according to an exemplary embodiment, such as... Figure 2 As shown, this method is used Figure 1 The intelligent agent system or task processing system includes the following steps.

[0065] In step S210, the task execution request input for the target task is parsed to determine the task execution template for the target task.

[0066] Specifically, the task processing system can receive task execution requests submitted by users through its task access module. These requests can be task descriptions expressed in natural language by the user via a terminal device, structured task information submitted through a preset form format, or standardized task parameters submitted through an application programming interface (API). The task execution request can carry information such as a description of the target task, input materials (e.g., reference documents, source data, constraints), output format constraints, and timeliness requirements.

[0067] After receiving a task execution request, the task processing system can parse and process the request to determine the corresponding task execution template. In practice, the task execution template can be one of several candidate scenario templates pre-installed in a scenario template library. Each candidate scenario template can be associated with a corresponding task scenario type identifier. Specifically, the task processing system can analyze information such as the task objective description, input data type, and output format constraints carried in the task execution request to determine the task scenario type of the target task, and then select a candidate scenario template from the scenario template library that matches that task scenario type as the task execution template for the target task.

[0068] Optionally, the task processing system can also determine the task execution template by extracting the semantic features of the task execution request and performing similarity matching between the semantic features and the template descriptions of each candidate scenario template.

[0069] Optionally, the task processing system can also directly select the corresponding task execution template based on the task scenario tag explicitly specified by the user in the task execution request.

[0070] The candidate scenario templates can be pre-configured, and may include templates for code generation, data research, report generation, and presentation generation. In practical applications, task execution templates can pre-configure at least one of the following: prompt skeleton, tool call order, output structure constraints, fault tolerance strategies, and validation rules. Optionally, the task scenario types are not limited to those listed above and can be expanded according to actual business needs, for example, including templates for data visualization generation and API documentation generation.

[0071] In step S220, a task execution plan for the target task is generated based on the task execution template of the target task.

[0072] The task execution plan is used to indicate the multiple subtasks for achieving the target task, as well as the dependencies between the subtasks.

[0073] The subtasks include at least one of the following: model inference task or tool invocation task.

[0074] Specifically, after determining the task execution template for the target task, the task processing system can generate a task execution plan for the target task based on the pre-defined prompt skeleton, toolchain configuration, and execution logic within the task execution template. In other words, the task execution template provides a structured skeleton and constraints for the generation of the task execution plan, such as the list of subtask types defined in the task execution template, the recommended order of subtask orchestration, and tool call dependencies.

[0075] A task processing system can break down a target task into multiple subtasks based on a task execution template and specific parameters, and determine the dependencies between these subtasks. In practice, subtasks can be categorized into two types: model inference tasks and tool invocation tasks. Model inference tasks are subtasks involving understanding, generation, or decision-making that require execution by a language model or inference model, such as analyzing user requirements, generating code snippets, or determining the correctness of execution results. Tool invocation tasks are subtasks involving operations performed by external tools or programs, such as file reading / writing, command-line execution, network requests, and document format conversion. Dependencies indicate the execution order and data flow between subtasks; for example, subtask B may need to wait for the output of subtask A as input, or subtasks C and D may be executed in parallel.

[0076] In practical applications, the granularity of subtask decomposition can be dynamically adjusted according to the task complexity: for simple tasks, multiple similar operations can be merged into one subtask; for complex tasks, a logical step can be subdivided into multiple serial or parallel subtasks.

[0077] In step S230, based on the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from the candidate model set to obtain the model call set of the target task. Also, based on the task execution configuration indicated by the task execution template, an isolated execution environment is created, and the task context of the target task is injected into the isolated execution environment.

[0078] The candidate model set is a collection of available models that are pre-connected and maintained by the task processing system. Each candidate model in the candidate model set may have corresponding capability tags (such as proficient in code generation, proficient in multilingual translation, proficient in logical reasoning, etc.), cost indicators, context window size, and resource consumption characteristics.

[0079] In practice, the task processing system can determine the corresponding model capability requirement profile based on the task scenario type, then select candidate models that meet the model capability requirement profile from the candidate model set, and select one candidate model as the primary model and another candidate model as the backup model.

[0080] Optionally, the selection of the primary and backup models can also take into account factors such as the model's current load status, historical execution success rate, inference latency, and invocation cost. In practical applications, there can be one or more backup models, and priority can be set among them. The selected primary and backup models constitute the model invocation set for the target task, which is used for model scheduling during the execution of subsequent subtasks.

[0081] In terms of creating an isolated execution environment, the task execution template also indicates the task runtime configuration, which may include information such as runtime dependency list, working directory structure, environment variable configuration, resource quota and access permission configuration.

[0082] The task processing system creates an isolated execution environment based on the task's runtime configuration. In practice, this isolated execution environment can be an independent cloud sandbox instance. The task processing system can quickly create a sandbox instance based on a lightweight container image by calling the sandbox management module, and inject the target task's task context, including task objectives, input data, working directory, runtime dependencies, and access permissions, into the sandbox instance.

[0083] Optionally, sandbox instances can be created by directly allocating an idle instance from a preheated instance pool to shorten startup waiting time; or by using an image tiered caching mechanism to preload the base image layer and only pull the task-specific incremental layer as needed.

[0084] In step S240, according to the task execution plan, the target model in the model invocation set is scheduled to execute the model inference task in the subtask, and the target tool in the isolated execution environment is driven to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task.

[0085] Specifically, the task processing system can begin executing each subtask according to the task execution plan. The task execution plan provides the execution order and dependencies of the subtasks, the model call set provides the available model resources, and the isolated execution environment provides the execution site for tool calls.

[0086] For model inference tasks, the task processing system selects a target model from the model call set (usually prioritizing the primary model), sends the task context and prompts for the current subtask to the target model for inference, and obtains the model inference result.

[0087] For tool invocation tasks, the task processing system determines the target tool and its invocation parameters based on the inference results output by the preceding model inference task. It then executes the target tool in an isolated execution environment (e.g., executing file write commands, running compilation scripts, initiating network requests, etc.) and obtains the tool execution results. These results can be fed back to subsequent model inference tasks as context input.

[0088] In practical applications, for tool invocation tasks, the task processing system can start an agent process inside the isolated execution environment. This agent process receives the tool invocation instructions and executes them in the sandbox. After execution, it returns the results to the task processing system.

[0089] In step S250, target delivery information in response to the task execution request is obtained based on the task execution results of multiple subtasks.

[0090] Specifically, after all subtasks in the task execution plan have been completed, the task processing system summarizes the task execution results of each subtask. The task execution results may include the text content output by the model inference task, the file artifacts generated by the tool invocation task, the execution logs and status information of each subtask, etc.

[0091] The task processing system generates target delivery information in response to the task execution request based on the execution results of each subtask. In specific implementations, target delivery information may include target artifact files, such as generated source code files, compiled executable files, rendered report documents, or presentation files. The task processing system can also organize and format intermediate artifacts, generating additional information such as execution process summaries (e.g., subtask execution overview, key decision records), key evidence chains, and execution metadata (e.g., execution time, model call count, tool call records). Optionally, the format of the target delivery information can be determined based on the output format constraints specified in the user's task execution request. For example, if the user requests a PDF report, the task processing system can invoke a document conversion tool in the tool call task to convert the intermediate artifacts to PDF format.

[0092] In the above task processing method, the task execution template of the target task is determined by parsing the task execution request input for the target task, and a task execution plan for the target task is generated based on the task execution template. The task execution plan indicates multiple subtasks for implementing the target task, as well as the dependencies between each subtask. Subtasks include at least one of model inference tasks or tool invocation tasks. Then, based on the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from a set of candidate models to obtain the model invocation set for the target task. Furthermore, based on the task execution configuration indicated by the task execution template, an isolated execution environment is created, and the task context of the target task is injected into the isolated execution environment. Finally, the target model in the model invocation set is scheduled to execute according to the task execution plan. The system performs model inference tasks within subtasks and, based on the model inference results, drives the target tool in the isolated execution environment to execute corresponding tool invocation tasks. This allows the system to obtain target delivery information for response task execution requests based on the execution results of multiple subtasks. This enables the intelligent agent system to selectively switch task execution templates to match the task scenario type of the target task based on different task types of the task execution request, without requiring customized templates for each case. This improves the adaptability and output stability of multi-scenario tasks. Furthermore, by configuring at least one backup model for the primary model, redundancy is provided for the stable execution of long-chain tasks. Executing tool invocation tasks in the isolated execution environment effectively balances security isolation with execution efficiency, thereby significantly improving the task execution efficiency of the intelligent agent system.

[0093] In an exemplary embodiment, parsing the task execution request input for the target task and determining the task execution template for the target task includes: parsing the task execution request and determining the task semantic features of the task execution request; determining the task scenario type to which the target task belongs based on the task semantic features; and determining the target scenario template that matches the task scenario type from multiple candidate scenario templates in a preset scenario template library, and using it as the task execution template for the target task.

[0094] In practical implementation, after receiving a task execution request, the task processing system can perform semantic parsing on the request to extract its semantic features. These semantic features can characterize the core intent of the target task, the types of operations involved, the expected output format, and constraints. Optionally, the semantic features can be vectorized, for example, by mapping the task description to semantic feature vectors using a pre-trained semantic encoding model.

[0095] Then, the task processing system can match the semantic features of the task with the feature descriptions of preset task scenario types to determine the task scenario type to which the target task belongs. In specific implementations, the preset task scenario types can include code generation scenarios, data research scenarios, report generation scenarios, presentation generation scenarios, etc. Each task scenario type can have corresponding feature description rules or classification models. For example, when the semantic features of the task contain keywords such as "code" or "interface" and the target output type is an executable program or source code, the task scenario type to which the target task belongs can be determined to be a code generation scenario.

[0096] After determining the task scenario type of the target task, the task processing system can search for candidate scenario templates that match the target task's scenario type in the scenario template library, and then identify the candidate scenario template as the target scenario template for execution. In the specific implementation, each candidate scenario template in the scenario template library can have a scenario type tag, and the task processing system can locate candidate scenario templates by tag matching.

[0097] For example, when the target task belongs to the code generation scenario, a code generation template is matched. This template can pre-define code writing prompts (including programming language selection prompts, code style constraints, commenting standards, etc.), toolchain configuration (including code formatting tools, syntax checking tools, compilation and building tools, etc.), output structure constraints (including file directory structure, entry file definition, etc.), and fault tolerance strategies for the code generation scenario (such as retry logic when compilation fails, alternative solutions when dependency conflicts occur, etc.).

[0098] Optionally, multiple candidate scenario templates with different focuses can exist under the same task scenario type. For example, the code generation scenario can include sub-templates for generating front-end pages, generating back-end interfaces, generating full-stack projects, etc.

[0099] The technical solution of this embodiment parses the task execution request, determines the task semantic features of the task execution request, and determines the task scenario type to which the target task belongs based on the task semantic features; among multiple candidate scenario templates in the preset scenario template library, the target scenario template that matches the task scenario type is determined as the task execution template of the target task, thereby enabling the mapping of unstructured user requests to structured task execution templates and improving the automation level of task processing.

[0100] In an exemplary embodiment, according to the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from a set of candidate models to obtain a model invocation set for the target task. This includes: obtaining model capability requirements that match the task scenario type; determining the model capability quantification index of each candidate model in the set for the model capability requirements; obtaining the real-time resource status of each candidate model; and selecting a primary model and at least one backup model from among the candidate models based on the real-time resource status and model capability quantification index of each candidate model to obtain a model invocation set.

[0101] In the specific implementation, during the process of the task processing system selecting the primary model and at least one backup model from the candidate model set according to the task scenario type indicated by the task execution template, and obtaining the model call set for the target task, the task processing system determines the corresponding model capability requirements based on the task scenario type.

[0102] Among them, the model capability requirements can be pre-configured and stored in association with the task scenario type. For example, the model capability requirements for the code generation scenario can include dimensions such as code generation accuracy, multi-language support, and structured output capability; the model capability requirements for the report generation scenario can include dimensions such as long text understanding capability, information extraction accuracy, and text generation fluency.

[0103] For each candidate model in the candidate model set, the task processing system can evaluate the performance of each candidate model in terms of model capability requirements, and obtain a quantitative indicator of model capability. In specific implementations, the quantitative indicator of model capability can be obtained based on historical execution data statistics, such as the code compilation pass rate and syntax accuracy of the model in historical code generation tasks; or it can be obtained based on standard evaluation benchmarks, such as the model's score on publicly available evaluation datasets.

[0104] Meanwhile, the task processing system can also obtain the real-time resource status of each candidate model. The real-time resource status can include information such as the current concurrent call volume, available quota, average response latency, and service health status.

[0105] Then, based on the real-time resource status and model capability quantification indicators corresponding to each candidate model, the task processing system selects a primary model and at least one backup model from among the candidate models to obtain a model invocation set. Specifically, the task processing system can adopt a weighted scoring method: for each candidate model, a capability score can be calculated based on its model capability quantification indicators for the target task scenario type, and an availability score can be calculated based on the real-time resource status; then, the capability score and availability score are weighted and summed according to preset weights to obtain a comprehensive score; then, the candidate model with the highest comprehensive score is selected as the primary model, and one or more candidate models with the second highest comprehensive score are selected as backup models to obtain a model invocation set.

[0106] The technical solution of this embodiment selects the primary model and the backup model by combining the quantitative indicators of model capability with the real-time resource status. This allows the primary model and the backup model to perform the target task to both match the scenario capability requirements of the target task and adapt to the current resource availability, thus achieving a balance between model capability and resource efficiency.

[0107] In an exemplary embodiment, scheduling a target model in the model invocation set to execute a model inference task in a subtask according to a task execution plan includes: when the target model is the primary model, obtaining the task processing status of the primary model when executing the model inference task; and switching to a backup model to continue executing the model inference task in response to the primary model's task processing status being a preset switching status.

[0108] The preset switching states include: inference request response timeout, inference task execution failure, or model inference result not meeting preset constraints.

[0109] In its implementation, the task processing system, while scheduling target models from the model call set to execute model inference tasks according to the task execution plan, monitors the task processing status of the primary model in real time when scheduling the primary model to execute the model inference task. The task processing status can be obtained by monitoring the application programming interface (API) call responses of the primary model, including the response time of the inference request, the return status code, error messages, and the content of the inference result.

[0110] Then, the task processing system can determine whether the current task processing status of the primary model is normal based on the monitoring results of the primary model's task processing status. In specific implementations, the task processing status can include a normal state and a preset switching state. The preset switching state refers to an abnormal state that meets preset model switching conditions, which can include at least one of the following: inference request response timeout (i.e., the time from sending the inference request to receiving the response exceeds the preset timeout threshold), inference task execution failure (i.e., the model returns an error code or exception information, indicating that this inference cannot be completed normally), or the model inference result does not meet the preset constraints (i.e., the inference result returned by the model does not meet the preset qualified standards in terms of format, content completeness, or quality).

[0111] Then, when the task processing system detects that the task processing status of the primary model meets the preset switching status conditions, the task processing system switches the current model inference task from the primary model to the standby model for continued execution. In a specific implementation, the switching process may include: pausing the sending of new inference requests to the primary model; selecting a target standby model from the model call set according to the priority order of standby models; forwarding the context and parameters of the current model inference task to the target standby model; and initiating the inference call of the target standby model.

[0112] The technical solution of this embodiment monitors the task processing status of the primary model and automatically switches to the backup model to continue executing the model inference task when the task processing status of the primary model meets the preset switching status. This effectively avoids task interruption caused by a single model failure and significantly improves the execution continuity of long-chain tasks.

[0113] In one exemplary embodiment, switching to a standby model to continue executing the model inference task includes: obtaining the task context of the target task before switching to the standby model; pruning the task context to obtain a pruned task context; the pruned task context includes at least the execution output of completed subtasks; and inputting the pruned task context into the standby model to trigger the standby model to continue executing the model inference task.

[0114] In practice, during the process of switching to a backup model to continue executing the model inference task, the task processing system can obtain the task context of the target task before switching to the backup model, so that the backup model can continue execution instead of starting from scratch.

[0115] In practical applications, the task context can include the input parameters, output results, and execution status information of each subtask that has been executed from the start of the target task to the switching time.

[0116] The task processing system can retrieve the task context of the target task, including: task objectives and initial input data, prompts and inference results of completed model inference tasks, call parameters and execution output of completed tool call tasks, prompts and sent message sequences of the currently executing model inference task, and the current state of the isolated execution environment.

[0117] Then, the task processing system, following a preset pruning strategy, retains key information from the complete task context while removing redundant or unnecessary information, resulting in a pruned task context. In specific implementations, the pruned task context includes at least the execution outputs of completed subtasks, as these outputs contain the information needed for subsequent steps. Optionally, pruning can employ various strategies: importance-based pruning (retaining context information directly impacting subsequent steps), timeliness-based pruning (prioritizing the retention of the most recent context information), and length-based pruning (truncating or compressing the context according to preset rules when the total context length exceeds the standby model's context window limit). The task processing system inputs the pruned task context into the standby model as the context input for the standby model to continue executing the model inference task, thus triggering the standby model to continue executing the model inference task.

[0118] The technical solution of this embodiment, by pruning the task context during switching, retains key information such as the execution output of completed subtasks and removes unnecessary redundant context, so that the backup model can continue to execute within a limited context window without re-executing completed subtasks, thus balancing switching efficiency and the integrity of context information.

[0119] In an exemplary embodiment, when the target task includes a front-end page generation task or a web application generation task, the method further includes: scanning the process listening state within the isolated execution environment to determine at least two service ports that are in the listening state; and establishing a proxy access entry for each service port.

[0120] The proxy access entry point is used to establish access routes from outside the isolated execution environment to the service port.

[0121] In practice, when the target task involves front-end page generation or web application generation, one or more service processes are typically started within the isolated execution environment. These service processes listen on specific ports within the isolated execution environment to provide external services. The task processing system scans the process listening status within the isolated execution environment during or after the execution of a subtask. The process listening status can be determined by executing port scanning commands within the isolated execution environment.

[0122] Then, since the external network cannot directly access the service ports inside the isolated execution environment, the task processing system needs to establish a proxy access point for each scanned service port. In a specific implementation, the proxy access point can be a Uniform Resource Locator (URL) that points to the reverse proxy address of the task processing system's preview proxy module. When an external user accesses this URL through a browser, the preview proxy module forwards the request to the corresponding service port inside the isolated execution environment and returns the service port's response to the external user. In this way, external users can view and interact with the services inside the isolated execution environment through the proxy access point without directly accessing the internal network of the isolated execution environment.

[0123] The technical solution of this embodiment scans the process monitoring status inside the isolated execution environment to identify at least two service ports that are in the monitoring state, and establishes a proxy access entry for each service port. This allows users to preview the complete effect of the front-end page, back-end interface and real-time communication link based on the proxy access entry, which significantly improves the verifiability of front-end development tasks.

[0124] In one exemplary embodiment, the method further includes: recording task execution description information corresponding to the multiple subtasks during the execution of the multiple subtasks; and generating a task status view of the target task based on the task execution description information.

[0125] Specifically, the task processing system continuously records the execution status of each subtask during its execution. The recorded data comes from various runtime information generated during the execution of the subtasks, including prompts and inference results for model inference tasks, call parameters and execution output for tool invocation tasks, start and end times of subtasks, and execution status of subtasks (e.g., waiting, executing, successful, failed, timed out).

[0126] In practical applications, task processing systems can process various runtime information generated during the execution of subtasks (such as logs, metrics, error codes, model call latency, tool call results, sandbox running status, agent access records, and critical state transition information in the task execution chain) into structured task execution description information and persist it for storage.

[0127] Then, the task processing system organizes the task execution description information according to a timeline or execution chain, generating a task status view for the target task to facilitate user viewing and understanding. In specific implementations, the task status view can include at least one of a timeline view, a tracing view, and an exception / alarm view. Optionally, the task status view can be presented to the user as a webpage, accessible through a browser, allowing the user to view the task execution progress in real time or review historical execution records later.

[0128] The technical solution of this embodiment achieves full observability of the task execution process by continuously recording task execution description information and generating a task status view during the subtask execution process. This allows users to keep track of the task execution progress in real time, quickly locate abnormal subtasks, and perform backtracking analysis based on the link records when problems occur.

[0129] In one exemplary embodiment, the method further includes performing at least one of a resource reclamation operation or an instance destruction operation on the isolated execution environment after the execution of multiple subtasks is completed.

[0130] In practice, after all subtasks of the target task have been completed (regardless of success or failure), the task processing system cleans up the isolated execution environment. The cleanup operation targets the isolated execution environment instance used by the target task.

[0131] In practical applications, task processing systems can perform resource reclamation or instance destruction operations on isolated execution environments according to preset cleanup strategies. Specifically, resource reclamation operations can include: cleaning up temporary task files within the isolated execution environment, releasing occupied storage space, and disconnecting network connections; instance destruction operations can include: stopping container or virtual machine processes in the isolated execution environment, deleting container image layers or virtual machine snapshots, and reclaiming computing and memory resources.

[0132] The technical solution of this embodiment releases unused computing and storage resources in a timely manner by performing resource reclamation or instance destruction operations on the isolated execution environment after the task is completed, thereby avoiding the waste of idle instance resources and improving the overall resource utilization efficiency of the system.

[0133] Figure 3 This is a flowchart illustrating another task processing method according to an exemplary embodiment, such as... Figure 3 As shown, this method is used Figure 1 The task processing system includes the following steps.

[0134] In step S310, the task execution request is parsed to determine the task semantic features of the task execution request.

[0135] In step S320, the task scenario type to which the target task belongs is determined based on the task semantic features.

[0136] In step S330, among multiple candidate scene templates in the preset scene template library, a target scene template that matches the task scene type is determined and used as the task execution template for the target task.

[0137] In step S340, a task execution plan for the target task is generated based on the task execution template of the target task. The task execution plan is used to indicate multiple sub-tasks for implementing the target task, as well as the dependencies between each sub-task. The sub-tasks include at least one of model inference tasks or tool invocation tasks.

[0138] In step S350, based on the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from the candidate model set to obtain the model call set for the target task.

[0139] In step S360, an isolated execution environment is created according to the task execution configuration indicated by the task execution template, and the task context of the target task is injected into the isolated execution environment.

[0140] In step S370, according to the task execution plan, the target model in the model invocation set is scheduled to execute the model inference task in the subtask, and the target tool in the isolated execution environment is driven to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task.

[0141] In step S380, target delivery information in response to the task execution request is obtained based on the task execution results of multiple subtasks.

[0142] It should be noted that the specific limitations of the above steps can be found in the specific limitations of a task processing method described above, and will not be repeated here.

[0143] For the convenience of those skilled in the art, Figure 4An architecture diagram of a cloud-based sandbox-based task processing system (i.e., an intelligent agent system) is also provided. This task processing system includes at least a task access module, a scene recognition and template assembly module, a model scheduling module, a tool orchestration module, a sandbox management module, a preview agent module, an observability module, and a result delivery module. In practical applications, this task processing system can be deployed in the same service or in a distributed manner using microservices.

[0144] The task access module is used to receive task requests submitted by users in natural language, forms, or APIs, and to extract task objectives, input data, output format constraints, and timeliness requirements.

[0145] like Figure 5 As shown, the scene recognition and template assembly module is used to map the task execution request to a preset scene template according to the task characteristics of the target task, so as to obtain the task execution template of the target task. The preset scene template includes at least a code generation template, a data research template, a PPT generation template, and a report generation template. Each template has a preset prompt word skeleton, tool call order, output structure constraints, fault tolerance strategy, and verification rules.

[0146] like Figure 6 As shown, the model scheduling module is used to allocate a primary model and at least one backup model to the target task, and record the model capability labels, cost indicators, context window, success rate statistics and historical performance. When the primary model call times out, fails or the output does not meet the constraints, the model scheduling module seamlessly switches the current task to the backup model to continue execution according to the preset switching strategy, so as to maintain the continuity of the task.

[0147] The tool orchestration module is used to schedule tools such as retrieval, file processing, code execution, network access, and document generation based on the plan generated by the model, and to maintain tool inputs and outputs, state contexts, and execution dependencies.

[0148] like Figure 7 As shown, the sandbox management module is used to quickly create cloud sandbox instances based on lightweight container images and provide an isolated execution environment to the Agent. Sandbox instances come pre-installed with runtime dependencies, commonly used development tools, and a browser-side Web IDE service. The sandbox management module also maintains the instance pool, controls resource quotas, implements security isolation, reclaims instances after tasks are completed, and allows users to temporarily enter the sandbox for code viewing, debugging, or repair when needed.

[0149] like Figure 8 As shown, the preview proxy module is used to identify multiple business service ports in a single sandbox instance and generate a unified access entry for each port. The preview proxy module can perform path rewriting, request forwarding, and protocol adaptation to ensure stable preview of multiple service items in the browser.

[0150] like Figure 9 As shown, the observable module is used to collect logs, metrics, error codes, model call latency, tool call results, sandbox running status, agent access records, and key state transition information in the task execution chain of the target task, and generate a link tracing view, anomaly alarm view, and historical replay view for the target task.

[0151] The results delivery module is used to summarize the final product, intermediate process summary, key evidence chain and execution metadata, write them to persistent storage and return them to the user.

[0152] It should be understood that, although Figure 2 and Figure 3 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 and Figure 3 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0153] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0154] Figure 10 This is a block diagram of a task processing apparatus according to an exemplary embodiment. (Refer to...) Figure 10 The device includes:

[0155] The parsing unit 1010 is configured to parse the task execution request input for the target task and determine the task execution template of the target task;

[0156] The generation unit 1020 is configured to execute a task execution template based on the target task to generate a task execution plan for the target task; the task execution plan is used to indicate multiple sub-tasks for implementing the target task, and the dependencies between the sub-tasks; the sub-tasks include at least one of model inference tasks or tool invocation tasks;

[0157] Selection unit 1030 is configured to perform the following actions according to the task scenario type indicated by the task execution template: select a primary model and at least one backup model from a set of candidate models to obtain a set of model calls for the target task; and create an isolated execution environment according to the task execution configuration indicated by the task execution template, and inject the task context of the target task into the isolated execution environment.

[0158] The execution unit 1040 is configured to execute, according to the task execution plan, schedule the target model in the model invocation set to execute the model inference task in the subtask, and drive the target tool in the isolated execution environment to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task;

[0159] Delivery unit 1050 is configured to obtain target delivery information in response to the task execution request based on the task execution results of the plurality of subtasks.

[0160] In an exemplary embodiment, the parsing unit 1010 is specifically configured to parse the task execution request, determine the task semantic features of the task execution request, determine the task scenario type to which the target task belongs based on the task semantic features, and determine a target scenario template that matches the task scenario type from multiple candidate scenario templates in a preset scenario template library, and use it as the task execution template for the target task.

[0161] In an exemplary embodiment, the selection unit 1030 is specifically configured to perform the following: obtain the model capability requirements matching the task scenario type; determine the model capability quantification index of each candidate model in the candidate model set for the model capability requirements; obtain the real-time resource status of each candidate model; and select the primary model and the at least one backup model from among the candidate models based on the real-time resource status and the model capability quantification index corresponding to each candidate model, thereby obtaining the model call set.

[0162] In an exemplary embodiment, the execution unit 1040 is specifically configured to, when the target model is the primary model, obtain the task processing state of the primary model when executing the model inference task; and, in response to the task processing state of the primary model being a preset switching state, switch the backup model to continue executing the model inference task; wherein the preset switching state includes: inference request response timeout, inference task execution failure, or model inference result not meeting preset constraints.

[0163] In an exemplary embodiment, the execution unit 1040 is specifically configured to: acquire the task context of the target task before switching the backup model; perform pruning processing on the task context to obtain a pruned task context; the pruned task context includes at least the execution output of the completed sub-task; and input the pruned task context into the backup model to trigger the backup model to continue executing the model inference task.

[0164] In an exemplary embodiment, when the target task includes a front-end page generation task or a web application generation task, the apparatus is further configured to perform a scan of the process listening state within the isolated execution environment to determine at least two service ports that are in the listening state; for each service port, establish a proxy access entry for the service port; the proxy access entry is used to establish an access route from outside the isolated execution environment to the service port.

[0165] In an exemplary embodiment, the device is further configured to, during the execution of the plurality of sub-tasks, record task execution description information corresponding to the plurality of sub-tasks; and generate a task status view of the target task based on the task execution description information.

[0166] In one exemplary embodiment, the apparatus is further configured to perform at least one of a resource reclamation operation or an instance destruction operation on the isolated execution environment after the plurality of subtasks have been executed.

[0167] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0168] Figure 11 This is a block diagram illustrating an electronic device 1100 for performing the above-described task processing method according to an exemplary embodiment. For example, the electronic device 1100 may be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness equipment, personal digital assistant, etc.

[0169] Reference Figure 11 The electronic device 1100 may include one or more of the following components: processing component 1102, memory 1104, power supply component 1106, multimedia component 1108, audio component 1110, input / output (I / O) interface 1112, sensor component 1114, and communication component 1116.

[0170] Processing component 1102 typically controls the overall operation of electronic device 1100, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 1102 may include one or more processors 1120 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 1102 may include one or more modules to facilitate interaction between processing component 1102 and other components. For example, processing component 1102 may include a multimedia module to facilitate interaction between multimedia component 1108 and processing component 1102.

[0171] Memory 1104 is configured to store various types of data to support the operation of electronic device 1100. Examples of such data include instructions for any application or method operating on electronic device 1100, contact data, phonebook data, messages, pictures, videos, etc. Memory 1104 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, optical disk, or graphene storage.

[0172] Power supply component 1106 provides power to various components of electronic device 1100. Power supply component 1106 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 1100.

[0173] Multimedia component 1108 includes a screen that provides an output interface between the electronic device 1100 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 1108 includes a front-facing camera and / or a rear-facing camera. When the electronic device 1100 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0174] Audio component 1110 is configured to output and / or input audio signals. For example, audio component 1110 includes a microphone (MIC) configured to receive external audio signals when electronic device 1100 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 1104 or transmitted via communication component 1116. In some embodiments, audio component 1110 also includes a speaker for outputting audio signals.

[0175] I / O interface 1112 provides an interface between processing component 1102 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0176] Sensor assembly 1114 includes one or more sensors for providing state assessments of various aspects of electronic device 1100. For example, sensor assembly 1114 may detect the on / off state of electronic device 1100, the relative positioning of components such as the display and keypad of electronic device 1100, changes in position of electronic device 1100 or its components, the presence or absence of user contact with electronic device 1100, orientation or acceleration / deceleration of device 1100, and temperature changes of electronic device 1100. Sensor assembly 1114 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 1114 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 1114 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0177] Communication component 1116 is configured to facilitate wired or wireless communication between electronic device 1100 and other devices. Electronic device 1100 can access wireless networks based on communication standards, such as WiFi, carrier networks (such as 2G, 3G, 4G, or 5G), or combinations thereof. In one exemplary embodiment, communication component 1116 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 1116 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0178] In an exemplary embodiment, the electronic device 1100 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0179] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1104 including instructions, which can be executed by a processor 1120 of an electronic device 1100 to perform the above-described method. For example, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0180] In an exemplary embodiment, a computer program product is also provided, which includes instructions that can be executed by a processor 1120 of an electronic device 1100 to perform the above-described method.

[0181] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0182] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0183] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A task processing method, characterized in that, include: Analyze the task execution request input for the target task to determine the task execution template for the target task; Based on the task execution template of the target task, a task execution plan for the target task is generated; the task execution plan is used to indicate multiple sub-tasks for implementing the target task, and the dependencies between each sub-task; the sub-tasks include at least one of model inference tasks or tool invocation tasks; Based on the task scenario type indicated by the task execution template, a primary model and at least one backup model are selected from the candidate model set to obtain the model call set of the target task. In addition, based on the task running configuration indicated by the task execution template, an isolated execution environment is created, and the task context of the target task is injected into the isolated execution environment. According to the task execution plan, the target model in the model invocation set is scheduled to execute the model inference task in the subtask, and the target tool in the isolated execution environment is driven to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task. Based on the task execution results of the multiple sub-tasks, the target delivery information in response to the task execution request is obtained.

2. The task processing method according to claim 1, characterized in that, The parsing of the task execution request input for the target task, and the determination of the task execution template for the target task, includes: Analyze the task execution request to determine the task semantic features of the task execution request; Based on the semantic features of the task, determine the task scenario type to which the target task belongs; Among multiple candidate scene templates in the preset scene template library, a target scene template that matches the task scene type is determined and used as the task execution template for the target task.

3. The task processing method according to claim 1, characterized in that, The step of selecting a primary model and at least one backup model from a set of candidate models based on the task scenario type indicated by the task execution template, and obtaining the model call set for the target task, includes: Obtain the model capability requirements that match the task scenario type, and determine the quantitative indicators of the model capability of each candidate model in the candidate model set in response to the model capability requirements; Obtain the real-time resource status of each candidate model, and select the primary model and at least one backup model from among the candidate models based on the real-time resource status and the model capability quantification index, thereby obtaining the model call set.

4. The task processing method according to claim 1, characterized in that, The step of scheduling the target model in the model invocation set to execute the model inference task in the subtask according to the task execution plan includes: When the target model is the primary model, obtain the task processing status of the primary model when performing the model inference task; In response to the primary model's task processing state being a preset switching state, the backup model is switched to continue executing the model inference task. The preset switching states include: inference request response timeout, inference task execution failure, or model inference result not meeting preset constraints.

5. The task processing method according to claim 4, characterized in that, The step of switching the backup model to continue executing the model inference task includes: Obtain the task context of the target task before switching to the backup model; The task context is trimmed to obtain a trimmed task context; the trimmed task context includes at least the execution output of the completed subtasks. The truncated task context is input into the backup model to trigger the backup model to continue executing the model inference task.

6. The task processing method according to claim 1, characterized in that, When the target task includes a front-end page generation task or a web application generation task, the method further includes: Scan the process listening status within the isolated execution environment to identify at least two service ports that are in a listening state; For each of the service ports, a proxy access entry is established for that service port; the proxy access entry is used to establish an access route from outside the isolated execution environment to the service port.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: During the execution of the plurality of sub-tasks, the task execution description information corresponding to the plurality of sub-tasks is recorded; Based on the task execution description information, a task status view of the target task is generated.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: After the execution of the plurality of subtasks is completed, at least one of the following operations is performed on the isolated execution environment: resource reclamation or instance destruction.

9. A task processing device, characterized in that, include: The parsing unit is configured to parse the task execution request input for the target task and determine the task execution template of the target task; The generation unit is configured to execute a task execution plan for the target task based on a task execution template for the target task. The task execution plan is used to indicate multiple subtasks for achieving the target task, as well as the dependencies between the subtasks; the subtasks include at least one of model inference tasks or tool invocation tasks; The selection unit is configured to perform the following actions according to the task scenario type indicated by the task execution template: select a primary model and at least one backup model from a set of candidate models, obtain a set of model calls for the target task, and create an isolated execution environment according to the task execution configuration indicated by the task execution template, and inject the task context of the target task into the isolated execution environment. The execution unit is configured to execute, according to the task execution plan, schedule the target model in the model invocation set to execute the model inference task in the subtask, and drive the target tool in the isolated execution environment to execute the corresponding tool invocation task based on the model inference result corresponding to the model inference task; The delivery unit is configured to obtain target delivery information in response to the task execution request based on the task execution results of the plurality of subtasks.

10. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the task processing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the task processing method as described in any one of claims 1 to 8.

12. A computer program product, the computer program product comprising instructions, characterized in that, When the instructions are executed by the processor of the electronic device, the electronic device is able to perform the task processing method as described in any one of claims 1 to 8.

Images