Task execution method, device, equipment, readable storage medium and program product

Abstract

Embodiments of the present application provide a task execution method, device, equipment, readable storage medium and program product. The method comprises: receiving a task request of a user; determining a candidate tool set related to the task request according to the task request and / or user data; determining a target tool or a target workflow with the highest running performance index value in the candidate tool set; the running performance index value is determined according to at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow; and executing the task request through the target tool or the target workflow. The technical problems of insufficient precision and individualization of decision generation and inability to make a globally optimal scheduling decision among multiple selectable tools in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, specifically to a task execution method, apparatus, device, readable storage medium, and program product. Background Technology

[0002] Existing intelligent agent technologies, driven by large language models (LLMs), can understand user intent, decompose complex tasks, and interact with the real world by calling external tools (such as application programming interfaces (APIs) and databases). Most mainstream agent frameworks operate within a service-oriented ecosystem, resulting in a single dimension of decision-making context, leading to insufficient accuracy and personalization in decision-making. Furthermore, they primarily select tools based on semantic matching of functions, failing to make globally optimal scheduling decisions among multiple available tools. Summary of the Invention

[0003] At least one embodiment of this application provides a task execution method, apparatus, device, readable storage medium, and program product to address the technical problems in the prior art of insufficient accuracy and personalization in decision generation and the inability to make globally optimal scheduling decisions among multiple optional tools.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows:

[0005] In a first aspect, embodiments of this application provide a task execution method, including:

[0006] Receive task requests from users;

[0007] Based on the task request and / or user data, determine a candidate toolset related to the task request; the user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; the candidate toolset includes: tools or historical workflows.

[0008] Identify the target tool or target workflow with the highest runtime performance index value in the candidate toolset; the runtime performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow;

[0009] The task request is executed through the target tool or the target workflow.

[0010] Optionally, the user data is determined according to at least one of the following:

[0011] The user identifier is determined based on the task request, and the user profile and historical interaction data are obtained through synchronous or asynchronous queries; the user identifier is determined based on the task request.

[0012] Based on the user identifier, subscribe to the change data capture stream via direct database connection or message queue;

[0013] Based on the task request, the environmental data, device status data, and network status data are obtained through the monitoring interface.

[0014] Optionally, before determining the candidate toolset related to the task request based on the task request and / or user data, the method further includes:

[0015] The user data is integrated and standardized to obtain structured user data;

[0016] The structured user data is filtered using a language model to obtain user data related to the task request.

[0017] Optionally, the structured user data is filtered using a language model, including:

[0018] The structured user data is filtered using the language model based on a preset threshold.

[0019] The preset threshold is determined based on at least one of the following: the context window size of the language model, the task completion rate, the token consumption, the user satisfaction, the real-time load, and the urgency of the task request.

[0020] Optionally, based on the task request and / or user data, a candidate toolset related to the task request is determined, including at least one of the following:

[0021] Perform semantic analysis on the task request and map the task request to user intent nodes in the knowledge graph to determine the candidate tool or the historical workflow;

[0022] The user's preferences are determined based on the user data, and the candidate tool or the historical workflow is determined based on the preferences.

[0023] The nodes and relationships of the knowledge graph are mapped to a vector space, and the candidate tools or historical workflows that are similar to the vectors corresponding to the task request and the user data are queried in the vector space.

[0024] Optionally, the knowledge graph includes: nodes and the relationships between nodes;

[0025] The node includes at least one of the following: user intent, workflow, tool call, smart agent, and contextual features;

[0026] The node is accompanied by at least one of the following node attributes: success rate, average latency, average token cost, last execution time, application interface endpoint, input parameters, output results, and average error rate;

[0027] The relationships include: triggering, using, associating, and executing.

[0028] Optionally, executing the task request through the target tool or the target workflow includes:

[0029] Based on the target model, the task request is executed through the target tool or the target workflow;

[0030] Obtain the execution time, token consumption, and execution result of the task request; the execution result includes the decision information corresponding to the task request.

[0031] The target model and the knowledge graph are optimized and updated based on the task request, the user data, the execution time, the token consumption, and the execution result.

[0032] Optionally, the user profile includes at least one of the following: the user's role, preferences, and historical purchase records;

[0033] The device status data includes at least one of the following: device type, load status, CPU / GPU utilization, memory usage, and network status;

[0034] The environmental data includes at least one of the following: network latency and application interface health status data.

[0035] Secondly, embodiments of this application provide a task execution apparatus, including:

[0036] The receiving module is used to receive user task requests;

[0037] The first determining module is configured to determine a candidate toolset related to the task request based on the task request and / or user data; the user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; the candidate toolset includes: tools or historical workflows.

[0038] The second determining module is used to determine the target tool or target workflow with the highest runtime performance index value in the candidate toolset; the runtime performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow;

[0039] An execution module is used to execute the task request through the target tool or the target workflow.

[0040] Thirdly, embodiments of this application provide a task execution device, including: a processor, a memory, and a program stored in the memory and executable on the processor, wherein the program, when executed by the processor, implements the steps of the method described above.

[0041] Fourthly, embodiments of this application provide a computer-readable storage medium storing a program that, when executed by a processor, implements the steps of the method described above.

[0042] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which, when executed by a processor, implement the steps of the method described above.

[0043] Compared with existing technologies, the task execution method, apparatus, device, readable storage medium, and program product provided in this application can determine the user's identifier and user data upon receiving a task request, and then filter a candidate toolset related to the user based on the task request and / or user data. Furthermore, by calculating the performance index values ​​of tools or historical workflows within the candidate toolset, the target tool or target workflow with the highest performance index value is selected to process the task request, ensuring the accuracy and real-time performance of task processing. This solves the technical problems of insufficient precision and personalization in decision generation in existing technologies, and the inability to make globally optimal scheduling decisions among multiple selectable tools. Attached Figure Description

[0044] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application.

[0045] Figure 1 This is a schematic diagram illustrating the steps of the task execution method according to an embodiment of this application;

[0046] Figure 2 This is a schematic diagram of a task execution system according to an embodiment of this application;

[0047] Figure 3 This is a schematic diagram of the context service subsystem according to an embodiment of this application;

[0048] Figure 4 This is a schematic diagram of the scheduling service subsystem according to an embodiment of this application;

[0049] Figure 5 This is a schematic diagram of the learning and memory service subsystem according to an embodiment of this application;

[0050] Figure 6 This is a logical schematic diagram of the task execution method according to an embodiment of this application;

[0051] Figure 7 This is a schematic diagram of the knowledge graph in an embodiment of this application;

[0052] Figure 8 A schematic diagram of the module for the task execution device provided in this application;

[0053] Figure 9 This is a schematic diagram of the structure of the task execution device according to an embodiment of this application. Detailed Implementation

[0054] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, without limiting the number of objects; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, "A or B" covers three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0055] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc.; an indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0056] The term "instruction" in this application can be either a direct instruction (or explicit instruction) or an indirect instruction (or implicit instruction). A direct instruction can be understood as one in which the sender explicitly informs the receiver of specific information, the operation to be performed, or the requested result, etc.; an indirect instruction can be understood as one in which the receiver determines the corresponding information based on the instruction sent by the sender, or makes a judgment and determines the operation to be performed or the requested result, etc., based on the judgment result.

[0057] It is worth noting that the technologies described in this application are not limited to Long Term Evolution (LTE) / LTE-Advanced (LTE-A) systems, but can also be used in other wireless communication systems, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-carrier Frequency-Division Multiple Access (SC-FDMA), or other systems. The terms "system" and "network" in this application are often used interchangeably, and the described technologies can be used in the systems and radio technologies mentioned above, as well as in other systems and radio technologies. The following description describes New Radio (NR) systems for illustrative purposes, and the term NR is used in most of the following description; however, these technologies can also be applied to systems other than NR systems, such as 6th Generation (6G) communication systems.

[0058] To enable those skilled in the art to better understand the embodiments of this application, the following description is provided first:

[0059] Most mainstream agent frameworks (such as LangChain, LlamaIndex, etc.) operate within a service-oriented ecosystem, and their core working mode is as follows:

[0060] 1. Service Discovery and Configuration: The Agent discovers and identifies available external services or tools in the current environment through the Model Context Protocol (MCP). As a specification, the MCP enables the Agent to understand the functionality, input / output formats, and other metadata of each tool.

[0061] 2. Built-in Decision Logic: The core decision-making logic of the Agent, that is, deciding "what to do next," is usually embedded in its own implementation. A mainstream implementation approach is to use a "reasoning-action" (ReAct) process, which is driven by the LLM's built-in chain of thoughts. This logic is usually solidified in the Agent's code, or more commonly, it guides the LLM's behavior through carefully designed system prompts.

[0062] 3. Execution and Iteration: The agent makes decisions based on its built-in logic (e.g., choosing to invoke a certain tool), then executes the tool, obtains "observation" results, and uses these results as input for the next round of inference. This process is repeated until the task is completed. In summary, the characteristics of existing technical solutions are: the decision-making logic (brain) is strongly coupled with the agent, while external tools (hands and feet) are decoupled and dynamically discovered through the MCP protocol.

[0063] The Model Context Protocol (MCP) is a standardized specification for interaction between the various subsystems, intelligent agents, and external tools in this application. It defines key metadata such as service discovery, functional descriptions, and input / output formats, enabling agents to dynamically discover and invoke various services. The MCP protocol typically includes the following:

[0064] Service registration and discovery: Defines how services register their functions, interfaces, availability, and other information with the MCP service center, and how agents query and discover the services they need.

[0065] Metadata format: Specifies the format for describing the metadata of a tool or service, for example:

[0066] Description: A natural language description of the service, used for semantic matching;

[0067] • Input Schema: The name, type, required status, and description of the service's input parameters, usually defined using JSON Schema;

[0068] • Output Schema: The structure and type of the service's output;

[0069] • Performance Metrics: Performance metrics that service providers can report, such as average latency, success rate, and cost;

[0070] • Interface Specification: Defines the interface standard for service calls, such as RESTful API, gRPC, etc., as well as the data structure for requests and responses;

[0071] • Error handling mechanism: Specifies the error codes and error messages when a service call fails.

[0072] Through the MCP protocol, each subsystem of this application (context service, scheduling service, learning and memory service) can provide capabilities to the outside world in a standardized manner and be seamlessly integrated and invoked by the intelligent agent.

[0073] As described in the background section, the prior art suffers from technical problems such as insufficient accuracy and personalization in decision generation and the inability to make globally optimal scheduling decisions among multiple optional tools. To solve at least one of the above problems, this application provides a task execution method that can reduce or avoid the occurrence of the above situations, improve communication efficiency, and enhance user experience.

[0074] This application provides a task execution method and apparatus. The method and apparatus are based on the same concept, and since the principles by which they solve problems are similar, their implementations can be mutually referenced; repeated details will not be repeated.

[0075] like Figure 1 As shown in the figure, an embodiment of this application provides a task execution method, which includes the following steps:

[0076] Receive task requests from users;

[0077] Based on the task request and / or user data, determine a candidate toolset related to the task request; the user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; the candidate toolset includes: tools or historical workflows.

[0078] Identify the target tool or target workflow with the highest runtime performance index value in the candidate toolset; the runtime performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow;

[0079] The task request is executed through the target tool or the target workflow.

[0080] The task execution method of this application embodiment, upon receiving a task request, can determine the user's user identifier and user data, and then filter a candidate toolset related to the user based on the task request and / or user data; and by calculating the performance index values ​​of tools or historical workflows in the candidate toolset, select the target tool or target workflow with the highest performance index value to process the task request, ensuring the accuracy and real-time performance of task processing. This solves the technical problems of insufficient accuracy and personalization in decision generation in existing technologies, and the inability to make globally optimal scheduling decisions among multiple selectable tools.

[0081] Optionally, after receiving a user's task request (or user query), the intelligent agent determines the user data based on the user's task request.

[0082] The task execution method in this application embodiment, through, as... Figure 2 The system execution shown is as follows:

[0083] The scheduling service subsystem performs the retrieval of the candidate toolset internally based on the input (the task request and / or the user data);

[0084] The scheduling service subsystem determines the runtime performance index values ​​of the tools in the candidate toolset and the historical workflows by learning to rank (LTR) model.

[0085] Select the target tool or the target workflow to execute the task request.

[0086] Optionally, the ranking model may employ models such as LambdaMART, RankNet, or deep neural networks that are capable of handling complex nonlinear relationships and learning the optimal ranking strategy from multi-dimensional features.

[0087] It should be noted that the performance index value is related to the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow.

[0088] In this embodiment, in addition to the previously mentioned semantic relevance (cosine similarity between user intent and tool / workflow description), historical success rate, average latency, average token cost, and contextual features (system status, user profile), more features can be introduced to determine the runtime performance index values, such as:

[0089] The complexity of tools / workflows: for example, the number of API calls involved, the number of data processing steps, etc.;

[0090] Resource consumption prediction: In addition to token cost, it can also predict the consumption of computing resources such as CPU and memory;

[0091] User feedback: Historical user satisfaction ratings for the tool or workflow execution results;

[0092] Timeliness characteristics: the latest update time of the tool or workflow, the time of the most recent successful execution, etc.;

[0093] Training data sources and annotations: The training data for the LTR model mainly comes from the historical execution records accumulated by the learning and memory service subsystem;

[0094] Candidate tool / workflow characteristics: semantic description, historical performance metrics;

[0095] Tags: whether the final task is successful or not, actual performance metrics (such as latency, cost); (During training, historical successful and high-performing execution records can be used as positive samples, and failed or poor-performing records can be used as negative samples, or more refined level labeling (such as ranking levels based on actual performance metrics) can be used.

[0096] Each historical execution record includes: contextual features: user profile and system status at the time the task occurred.

[0097] In this embodiment of the application, the following strategies can be used to solve the cold start problem for newly launched tools / workflows or those with insufficient historical data:

[0098] Initial assessment based on metadata: prioritize semantic matching using metadata such as feature descriptions and tags, and assign a moderate or conservative initial performance score.

[0099] Explore-Exploit Mechanism: In the early stages, appropriately increase exploratory calls to new tools / workflows, even if their predictive scores are not high, to quickly accumulate real performance data;

[0100] Transfer learning: Transferring knowledge from historical data of similar tools or workflows to provide better initial predictions for new tools.

[0101] Optionally, the user data is determined according to at least one of the following:

[0102] The user identifier is determined based on the task request, and the user profile and historical interaction data are obtained through synchronous or asynchronous queries; the user identifier is determined based on the task request.

[0103] Based on the user identifier, subscribe to the change data capture stream via direct database connection or message queue;

[0104] Based on the task request, the environmental data, device status data, and network status data are obtained through the monitoring interface.

[0105] In this embodiment, information data is collected in real time from multiple heterogeneous data sources through a context service subsystem; to ensure efficient and reliable data acquisition, this embodiment supports multiple interface protocols and data formats;

[0106] For example, user profiles (such as roles, preferences, and historical purchase records) and historical interaction records can be obtained through synchronous or asynchronous queries via standard RESTful APIs (e.g., HTTP / HTTPS protocols, JSON / XML data formats); or change data capture (CDC) streams can be subscribed to via direct database connections (such as Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC)) or message queues (such as Kafka).

[0107] Optionally, based on the task request, the environmental data, device status data, and network status data are obtained through a monitoring interface, including:

[0108] The monitoring interface can be used to obtain real-time information on device type, network status, API health status, system load, CPU / GPU utilization, memory usage, and network latency.

[0109] Query monitoring metric data via Prometheus's HTTP API;

[0110] Real-time parsing of system logs from centralized logging systems (such as ELK Stack, Splunk) to extract key events and metrics;

[0111] Deploy a lightweight monitoring agent in the agent runtime environment to directly collect local device and network status data.

[0112] The task execution method of this application embodiment can improve the real-time performance and reliability of the data by obtaining the data through different interfaces and protocols.

[0113] Optionally, before determining the candidate toolset related to the task request based on the task request and / or user data, the method further includes:

[0114] The user data is integrated and standardized to obtain structured user data;

[0115] The structured user data is filtered using a language model to obtain the structured user data related to the task request.

[0116] In this embodiment, based on the characteristics of different data sources, corresponding adapters are used to pull or push data, and preliminary format conversion is performed to ensure that the data can be integrated and processed.

[0117] Specifically, the collected heterogeneous and multimodal data (such as text, JSON, and system logs) are integrated and standardized to generate a unified and structured context data object (such as a JSON object) to ensure that all key information can be processed consistently by downstream systems.

[0118] The task execution method of this application embodiment filters the user data through the language model, which can reduce the amount of data that needs to be processed, thereby improving the overall execution time of the task request.

[0119] Optionally, the structured user data is filtered using a language model, including:

[0120] The structured user data is filtered using the language model based on a preset threshold.

[0121] The preset threshold is determined based on at least one of the following: the context window size of the language model, the task completion rate, the token consumption, the user satisfaction, the real-time load, and the urgency of the task request.

[0122] It should be noted that the language model can be a finely tuned pre-trained language model (such as a lightweight version of BERT or RoBERTa), or a model based on embedding similarity calculation.

[0123] The language model's training data comes from the matching relationships between user queries and different context fragments in historical tasks. Through manual annotation or heuristic rules, context fragments highly relevant to the user query (the task request) are labeled as positive samples, and irrelevant ones are labeled as negative samples for training the model. The model's goal is to learn a classifier or regressor capable of predicting the relevance score between context fragments and the query.

[0124] In this embodiment of the application, the determination of the preset threshold is a trade-off process that needs to balance the limitations of the LLM context window and the completeness of the information required for decision-making.

[0125] Specifically, an initial threshold is set based on the context window size of the Large Language Model (LLM) and practical application experience;

[0126] Then, in actual operation, A / B testing is conducted to assess the impact of different thresholds on task completion rate, LLM token consumption, and user satisfaction, and the optimal threshold is selected; or,

[0127] The settings are dynamically adjusted based on factors such as the real-time load of the LLM and the urgency of the tasks.

[0128] The task execution method of this application embodiment filters out the user data related to the task request through the language model to avoid overloading the LLM context window and ensures that only the most critical and relevant information for the current decision is sent to the subsequent scheduling service subsystem, thereby improving decision-making efficiency and accuracy.

[0129] Optionally, based on the task request and / or user data, a candidate toolset related to the task request is determined, including at least one of the following:

[0130] Perform semantic analysis on the task request and map the task request to user intent nodes in the knowledge graph to determine the candidate tool or the historical workflow;

[0131] The user's preferences are determined based on the user data, and the candidate tool or the historical workflow is determined based on the preferences.

[0132] The nodes and relationships of the knowledge graph are mapped to a vector space, and the candidate tools or historical workflows that are similar to the vectors corresponding to the task request and the user data are queried in the vector space.

[0133] Optionally, the knowledge graph includes: nodes and the relationships between nodes;

[0134] The node includes at least one of the following: user intent, workflow, tool call, smart agent, and contextual features;

[0135] The node is accompanied by at least one of the following node attributes: success rate, average latency, average token cost, last execution time, application interface endpoint, input parameters, output results, and average error rate;

[0136] The relationships include: triggering, using, associating, and executing.

[0137] Optionally, each node includes unique identification information and description information.

[0138] The user profile includes at least one of the following: the user's role, preferences, and historical purchase records;

[0139] The device status data includes at least one of the following: device type, load status, CPU / GPU utilization, memory usage, and network status;

[0140] The environmental data includes at least one of the following: network latency and application interface health status data.

[0141] In this embodiment of the application, after receiving the task request, the task request is first semantically analyzed and mapped to the user intent node of the knowledge graph; then, using a graph traversal algorithm (such as BFS, DFS) or a graph query language (such as Cypher), starting from the workflow node connected to the user intent node through a trigger relationship, all related workflow and tool call nodes are further retrieved; or,

[0142] After receiving the task request and determining the user data, the candidate tools are filtered based on the contextual features of the user profile within the user data; for example, if the context indicates a user preference for "chart visualization," then tools or workflows whose Workflow node attributes include the ability to "generate charts" are prioritized for retrieval; or,

[0143] Graph embedding techniques (such as Node2Vec and GraphSAGE) can be used to map nodes and relationships in a knowledge graph to a low-dimensional vector space. During retrieval, the task request and user data are also converted into vectors, and the most relevant candidate toolset is quickly found by matching vector similarity, thereby improving retrieval efficiency and accuracy.

[0144] In this embodiment of the application, the structure of the knowledge graph includes:

[0145] Nodes: Represent entities such as UserIntent, Workflow, ToolCall, Agent, and ContextFeature;

[0146] Relationships between nodes: These represent the connections between nodes, for example:

[0147] Triggers: User intent triggers a workflow;

[0148] Utilities (USES_TOOL): Workflow uses tools for invocation;

[0149] Context detection (HAS_CONTEXT): Workflow-related context features;

[0150] Executor (EXECUTED_BY): The workflow is executed by the Agent;

[0151] Step tracking (PREVIOUS_STEP / NEXT_STEP): Indicates the order in which tools are invoked in the workflow.

[0152] Properties: The key is that the system attaches performance metrics for workflows and tool calls as properties to the corresponding nodes, for example:

[0153] Workflow node attributes: success rate, average latency, average token cost, and last executed time.

[0154] The node attributes for tool calls are: application interface endpoint (api_endpoint), input parameters (input_schema), output results (output_schema), average latency (avg_latency), and average error rate (avg_error_rate).

[0155] Optionally, executing the task request through the target tool or the target workflow includes:

[0156] Based on the target model, the task request is executed through the target tool or the target workflow;

[0157] Obtain the execution time, token consumption, and execution result of the task request; the execution result includes the decision information corresponding to the task request.

[0158] The target model and the knowledge graph are optimized and updated based on the task request, the user data, the execution time, the token consumption, and the execution result.

[0159] In this embodiment of the application, after each task is executed, the system automatically collects and records data such as the actual execution result (success / failure), the real-time latency of the tool call, and resource consumption; this feedback data is used to continuously update the performance attributes of the corresponding workflow or tool call nodes in the knowledge graph;

[0160] The target model can be an LTR model;

[0161] Specifically, the LTR model can be viewed as an agent, with its decision to choose tools / workflows considered as "actions," and the success rate and execution efficiency (low latency, low cost) of tasks considered as "rewards." Through algorithms such as Policy Gradient or Q-learning, the agent can learn from its interactions with the environment and adjust its ranking strategy to maximize long-term rewards.

[0162] For example, if a workflow has a delay of 10 seconds during this execution, the system will update its "average delay" attribute, typically using a moving average or exponentially weighted average to reflect the latest performance.

[0163] These execution records with real performance feedback were used as new training samples to fine-tune and optimize the LTR model in the scheduling service subsystem using the following paradigm:

[0164] In this embodiment, the system can learn to quickly adapt to new ranking strategies for different types of tasks or different users. For example, through algorithms such as MAML (Model-Agnostic Meta-Learning), the LTR model can quickly learn and adjust its parameters from a small number of new samples to adapt to constantly changing business needs and environments.

[0165] It should be noted that in multi-user, high-concurrency scenarios, updating the knowledge graph and online inference of the LTR model may face challenges in data consistency and real-time performance. This application adopts the following strategy:

[0166] Asynchronous updates: Knowledge graph updates and model training are typically performed asynchronously to avoid blocking real-time decisions; for example, execution records are first written to a message queue (such as Kafka), and then consumed asynchronously by a background service to update the knowledge graph and model.

[0167] Eventual consistency: Knowledge graph data updates strive for eventual consistency, meaning that all copies of the data will remain consistent after a period of time; for real-time decision-making, the LTR model can use the most recently trained version of the model to ensure the stability and predictability of the decision.

[0168] Distributed transactions: For critical operations that require strong consistency, consider introducing a distributed transaction mechanism (such as Two-Phase Commit or Saga mode) to ensure the atomicity of data operations.

[0169] In this embodiment of the application, to ensure the stability and reliability of the decision enhancement platform, the following fault recovery and fault tolerance mechanisms are considered:

[0170] Service circuit breaking and degradation: When a subsystem (such as a context service) fails or times out, a circuit breaking mechanism can be triggered to temporarily stop calls to it and enable degradation strategies (e.g., using the default context or relying only on historical data for decision-making) to prevent the failure from spreading.

[0171] Retry mechanism: For momentary network fluctuations or temporary service unavailability, a retry mechanism can be introduced to attempt to call the failed subsystem again within a certain number of times;

[0172] Health checks and automatic recovery: Each subsystem, deployed as a microservice, should have a health check interface and be automatically monitored and recovered from failures through a container orchestration platform (such as Kubernetes), for example, automatically restarting failed instances or replacing unhealthy nodes;

[0173] Data backup and recovery: Critical data such as knowledge graphs should be backed up regularly and have a rapid recovery mechanism to deal with the risk of data loss or damage.

[0174] like Figure 2 As shown, the task execution system of this application embodiment includes:

[0175] The system comprises a Context Service, a Dispatch Service, and a Learning & Memory Service. These three subsystems are encapsulated as independent microservices conforming to the MCP specification and registered with the MCP service center.

[0176] In this embodiment of the application, the context service subsystem includes: a data acquisition module, a data fusion module, and a quality screening module; such as Figure 3 As shown:

[0177] The data acquisition module obtains heterogeneous and multimodal user data according to the received task request;

[0178] The data fusion module standardizes and fuses the heterogeneous and multimodal user data.

[0179] The quality screening module filters out data (enhanced context) from the user data that is related to the current task request based on the fused user data.

[0180] In this embodiment of the application, the scheduling service subsystem includes: a candidate set retrieval module, a learning-based ranking module, and a decision generation module; as follows: Figure 4 As shown:

[0181] The candidate set retrieval module determines a candidate toolset related to the task request based on the task request and / or user data.

[0182] The learning-based ranking module ranks the performance metrics of each tool and historical workflow in the candidate toolset.

[0183] The decision generation module selects the target tool, target agent, or target historical workflow based on the sorting results; generates a data object including specific tool call instructions or workflow execution plans, and returns it to the intelligent agent.

[0184] In this embodiment of the application, the learning and memory service subsystem includes: a data storage module, a data processing module, and a model update module; as follows: Figure 5 As shown:

[0185] The knowledge graph is stored in the data storage module;

[0186] The data processing module retrieves the candidate set of tools based on the knowledge graph;

[0187] The model update module updates and optimizes the knowledge graph and the target model.

[0188] like Figure 6 As shown, the task execution method of this application embodiment includes:

[0189] Step 1: Context Acquisition: After receiving the user's task request, the intelligent agent, in the first step of its ReAct process, actively calls the context service subsystem based on the system prompts and passes in the query and user ID corresponding to the task request. After the context service subsystem executes its internal data collection, fusion, and filtering process, it obtains the user data and returns the enhanced context data to the intelligent agent.

[0190] Step 2: Optimal Decision Scheduling: In the second step of its thought chain, the intelligent agent, guided by instructions, proactively invokes the scheduling service subsystem, passing in the user query and the enhanced context obtained in the previous step as parameters. After executing its internal tool candidate set retrieval, LTR sorting, and decision generation process, the scheduling service subsystem returns the optimal tool invocation instruction or workflow plan.

[0191] Step 3: Execution and Observation: In the third step of its thought process, the intelligent agent parses and executes the tool call instructions or workflow plans returned by the scheduling service, calls the corresponding external tool services (standard MCP tools), and obtains the execution results (observation).

[0192] Step 4: Recording and Learning: In the fourth step of its thought process, the intelligent agent, guided by instructions, proactively invokes the learning and memory service subsystem to report the decisions made in the second step, the execution results of the third step, and performance indicators such as execution time and token consumption. The learning and memory service subsystem completes data recording and model updates, providing experience for future decisions.

[0193] Step 5: Complete the task: After completing the above steps, the intelligent agent provides the user with the final answer based on the execution results, completing a full task loop enhanced by decision-making.

[0194] The task execution method of this application decomposes a complex decision-making process into standardized steps handled by specialized subsystems, and empowers existing intelligent agents in a non-intrusive manner.

[0195] In this embodiment of the application, the task execution method includes:

[0196] 1. Multi-source data acquisition and preprocessing:

[0197] Initial user input: Receive the user's original query or task request, such as the text "Help me analyze the sales data of last quarter and generate a report";

[0198] User profiles and historical data: Based on user ID or session information, retrieve user profiles (such as role: sales director, preferences: likes reports with pictures and text, professional field: finance) and historical interaction records from the long-term memory module (i.e., the workflow knowledge graph of subsystem three);

[0199] Real-time environmental data: External environmental data is sensed and processed in real time through sensors or system monitoring interfaces. Examples include: • User device type: Mobile / PC, affecting report format; • User sentiment: Voice or text analysis determines whether the user is "anxious" or "calm," which can be used to adjust response tone or task priority; • System status indicators: Such as CPU / GPU utilization, network latency, and the health status of third-party APIs.

[0200] 2. Context fusion and standardization:

[0201] This subsystem integrates and standardizes the aforementioned heterogeneous and multimodal data streams (such as text, JSON, and system logs) into a unified data structure (context template). This data structure can be a JSON object containing multiple fields.

[0202] 3. Contextual quality filtering:

[0203] To avoid overloading the context window of the LLM, the system uses a lightweight model (such as a fine-tuned BERT model or simple embedding similarity calculation) to filter the fused context information in real time. This model evaluates the relevance score of each context fragment to the current user intent (user_intent), and only retains high-quality, highly relevant information with scores higher than a preset threshold, which is then sent to the subsequent scheduling subsystem.

[0204] 4. Multi-tool / workflow candidate set retrieval:

[0205] Upon receiving the context template generated by the upstream subsystem, this subsystem first retrieves all tools or predefined workflows related to the current task from the workflow knowledge graph through vector retrieval (based on the embedding of user intent) or structured query. The candidate set may include: single tools such as SQLQueryTool and ChartGenerationTool; agents for multi-tool collaboration such as DataAnalysisAgent (which internally encapsulates multiple tools for data querying, cleaning, and analysis); and validated, stable workflows such as FinancialReportWorkflow, a sequence of tool calls historically proven to successfully complete similar tasks.

[0206] 5. Prediction-based dynamic ranking engine:

[0207] The LTR model can be trained offline using sub-historical execution data and inferred online when a new task is received, thereby predicting the performance of each candidate in the current context. Training data can include contextual features of historical tasks, performance metrics of candidate tools / workflows, and the final task success or failure as labels. Specifically:

[0208] Input Features: This model uses multi-dimensional context and historical performance data of candidate tools / workflows as input features. These features include, but are not limited to:

[0209] Semantic relevance: cosine similarity between user intent and tool / workflow description; Historical success rate: frequency of successful execution of a workflow in historical tasks; Average latency: average response time of the tool or workflow; Average token cost: LLM token consumption required to execute the process; Contextual features: current system state, user profile, etc.

[0210] Ranking and Fusion: The LTR model predicts the expected performance of each candidate in the current context through a comprehensive analysis of these features and generates a dynamic ranking score. To balance "relevance" and "reliability," the system employs a "Reciprocal Rank Fusion (RRF)" algorithm to weight and fuse semantic relevance scores with historical performance scores. This ensures that for new tasks, the system can make reasonable attempts based on semantic similarity while prioritizing processes that have historically performed best.

[0211] 6. Execution and scheduling of optimal tools / workflows:

[0212] Based on the output of the sorting engine, the system selects the highest-ranked tool, toolset, or predefined workflow for execution. For multi-step workflows, complex tasks can be broken down into subtasks that can be completed collaboratively by multiple tools or agents, and scheduled for execution in a predetermined order or in parallel.

[0213] 7. Construction and updating of workflow knowledge graph:

[0214] Each successful LLM agent workflow (including user intent, execution steps, tool call sequence, and final result) is persisted as nodes and relationships in a knowledge graph, with the structure as follows: Figure 7 As shown.

[0215] Nodes: Represent entities, such as UserIntent, Workflow, and ToolCall;

[0216] Relationships: Represent connections, such as TRIGGERS (triggers) and USES_TOOL (use tools);

[0217] Properties: The key is that the system attaches workflow performance metrics (such as success rate: 0.95, average latency: 15s) as properties to the corresponding nodes.

[0218] 8. Closed-loop feedback and adaptive optimization:

[0219] Establish an automated closed-loop feedback mechanism. After each task is executed, the system will automatically collect and record data such as the actual execution result (success / failure), real-time latency of tool calls, and resource consumption.

[0220] Knowledge graph updates: This feedback data is used to continuously update the performance attributes of the corresponding workflow nodes in the knowledge graph. For example, if the delay of a workflow execution is 10 seconds, the system will update its "average delay" attribute.

[0221] Ranking Model Optimization: Further, this data is used as new training samples to fine-tune and optimize the dynamic ranking engine in Subsystem Two using paradigms such as reinforcement learning or meta-learning. In this way, the system learns which tool combinations are more successful in which contexts and adjusts its ranking strategy accordingly.

[0222] For example, the following detailed explanation uses a specific business scenario: A finance director (user ID: U123) wants the system to "generate a sales performance report for the third quarter and compare it with the previous quarter." Specifically:

[0223] Step 1: Context Acquisition (via the Context Service Subsystem)

[0224] 1. Receiving Requests: After receiving a user request, the smart agent calls the context service: getContext(user_id='U123', query='Generate the sales performance report for the third quarter and compare it with the previous quarter');

[0225] 2. Data Acquisition: The data acquisition modules start in parallel:

[0226] Query the CRM system for user_id='U123' to obtain the user profile: {"role": "Financial Director", "department": "Finance Department", "preferences": ["Chart Visualization", "Data Export to PDF"]};

[0227] Query the monitoring system to get the system status: {"db_api_latency": "low", "chart_service_status": "healthy"}.

[0228] 3. Data Fusion: The data fusion module integrates the above information into a single JSON object;

[0229] 4. Quality Screening: After evaluation, the quality screening module determined that all information was highly relevant to "generating financial reports" and therefore retained it.

[0230] 5. Return Result: The context service ultimately returns an enhanced context object to the smart agent:

[0231] {

[0232] "user_context": {

[0233] "user_id": "U123",

[0234] "role": "Chief Financial Officer",

[0235] "preferences": ["Chart Visualization", "Data Export to PDF"]

[0236] },

[0237] "system_context": {

[0238] "db_api_latency": "low",

[0239] "chart_service_status": "healthy"

[0240] }

[0241] }

[0242] Step 2: Optimal decision scheduling (through the scheduling service subsystem)

[0243] 1. Receive request: The smart agent uses the result of the previous step to call the scheduling service.

[0244] 2. Candidate Set Retrieval: Based on the query "Sales Performance Report", the candidate set retrieval module retrieves 3 candidate solutions from the knowledge graph:

[0245] Candidate A (Workflow): WF_Sales_Report_Gen, a stable workflow that has been successfully executed multiple times in history, consisting of four steps: querying data, data analysis, generating charts, and assembling PDF;

[0246] Candidate B (Tool): DataAnalysisAgent, a general-purpose data analysis agent that can receive raw data and generate analysis results, but does not directly generate PDFs;

[0247] Candidate C (Tool): SQLQueryTool, a basic tool that can only execute SQL queries to obtain raw data.

[0248] 3. LTR Model Ranking: The LTR model extracts features and scores the three candidate options respectively.

[0249] For candidate A (WF_Sales_Report_Gen):

[0250] Contextual features: role=CFO (positive high weight), preferences=chart visualization, PDF (highly matches workflow output, positive high weight);

[0251] Historical performance characteristics: success_rate=0.98, avg_latency=30s, avg_cost=4000_tokens (all excellent metrics);

[0252] Semantic relevance: 0.95;

[0253] Predicted score: 9.8.

[0254] For candidate B (DataAnalysisAgent):

[0255] Contextual feature: preferences=PDF (mismatch, negative weight);

[0256] Historical performance characteristics: success_rate=0.85, avg_latency=50s, avg_cost=6000_tokens (poor performance);

[0257] Semantic relevance: 0.80;

[0258] Predicted score: 6.5.

[0259] For candidate C (SQLQueryTool):

[0260] Contextual features: Unable to meet multiple requirements such as comparative analysis, charts, and PDFs; a serious mismatch.

[0261] Historical performance characteristics: N / A (particle size too fine);

[0262] Semantic relevance: 0.60;

[0263] Predicted score: 3.2.

[0264] 4. Decision Generation: The decision generation module finds that WF_Sales_Report_Gen has the highest score, so it generates a plan to execute the workflow and returns it to the intelligent agent.

[0265] Step 3: Execution and Observation

[0266] After receiving the instruction, the intelligent agent begins to execute the WF_Sales_Report_Gen workflow, sequentially calling multiple tools such as SQLQueryTool and DataAnalysisTool, and finally successfully generates a PDF report containing charts.

[0267] Step 4: Recording and Learning (through the Learning and Memory Service Subsystem)

[0268] 1. Reporting Record: After the task is completed, the intelligent agent calls the learning and memory service to report the complete record of this execution: {decision: "WF_Sales_Report_Gen", result: "success", actual_latency: "28s", actual_cost: "4100_tokens", context: {...}}.

[0269] 2. Knowledge Graph Update: After receiving the data, the data processing module updates the attributes of the WF_Sales_Report_Gen node in the knowledge graph, such as fine-tuning its average latency and success rate.

[0270] 3. Model Sample Addition: The model update module stores this complete execution record as a new high-quality training sample in the sample library for future iterative optimization of the LTR model.

[0271] Through the above embodiments, the present invention demonstrates how to utilize contextual information for accurate, efficient, and self-optimizing tool selection and scheduling, fully embodying the technical advantages of the present invention.

[0272] For example, the following is a simplified example of system prompts demonstrating how to guide an intelligent agent to perform a decision-enhancing closed loop according to the method of this invention:

[0273] You are an intelligent assistant capable of understanding user intent and calling external tools to complete tasks. Your decision-making process needs to follow the enhanced workflow below:

[0274] 1. Context Awareness: Before executing any task, you must first call `getContextService` to obtain enhanced context information for the current task. For example: `context = call_tool("getContextService",user_id="<user_id> ", query="<user_query> Replace `user_id` and `user_query` with the actual user ID and user request.

[0275] 2. Optimal Tool Scheduling: After obtaining the context, you must call `dispatchService` to select the most suitable tool or workflow for the current task. For example: `decision = call_tool("dispatchService", user_query="<user_query> `dispatchService` will return a JSON object containing specific tool call instructions or workflow execution plans.

[0276] 3. Execution and Observation: Parse the instructions returned in `decision` and call the corresponding external tools. For example: `observation = call_tool(decision["tool_name"], decision["tool_params"])` records the execution results (`observation`) of the tool, as well as performance metrics such as execution time and token consumption.

[0277] 4. Learning Feedback: After the tool finishes execution, you must call `learningMemoryService` to report the execution record so that the system can learn and optimize. For example: `call_tool("learningMemoryService", decision=decision, result=observation, actual_latency=" <latency>", actual_cost=" <cost>", context=context)` will <latency>` and` <cost>Replace ` with actual performance metrics.

[0278] 5. Complete the task: Provide the final answer to the user based on the observation. Please strictly follow the above process for decision-making and action. Your goal is to complete the user task efficiently and accurately, and continuously optimize your decision-making abilities.

[0279] The task execution method of this application, by injecting such prompt words into the LLM-driven Agent, can make it follow the decision enhancement method of this invention without modifying the core code of the Agent, thus achieving non-intrusive integration.

[0280] The various methods of the embodiments of this application have been described above. Apparatus for implementing the above methods will now be provided.

[0281] like Figure 8 As shown in the figure, this application embodiment also provides a task execution device 800, including:

[0282] The receiving module 801 is used to receive user task requests;

[0283] The first determining module 802 is configured to determine a candidate toolset related to the task request based on the task request and / or user data; the user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; the candidate toolset includes: tools or historical workflows.

[0284] The second determining module 803 is used to determine the target tool or target workflow with the highest running performance index value in the candidate toolset; the running performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow;

[0285] The execution module 804 is used to execute the task request through the target tool or the target workflow.

[0286] The task execution device of this application embodiment, upon receiving a task request, can determine the user's user identifier and user data, and then filter a candidate toolset related to the user based on the task request and / or user data. By calculating the performance index values ​​of tools or historical workflows in the candidate toolset, it selects the target tool or target workflow with the highest performance index value to process the task request, ensuring the accuracy and real-time performance of task processing. This solves the technical problems of insufficient accuracy and personalization in decision generation in existing technologies, and the inability to make globally optimal scheduling decisions among multiple selectable tools.

[0287] Another embodiment of the task execution device of this application, such as Figure 9 As shown, it includes a transceiver 910, a processor 900, a memory 920, and a program or instructions stored in the memory 920 and executable on the processor 900; when the processor 900 executes the program or instructions, it implements the various processes of the above-described task execution method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0288] The transceiver 910 is used to receive and send data under the control of the processor 900.

[0289] Among them, Figure 9 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 900) and memory (memory 920). The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 910 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. The processor 900 is responsible for managing the bus architecture and general processing, and the memory 920 can store data used by the processor 900 during operation.

[0290] This application also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the various processes of the above-described task execution method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0291] This application also provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the above-described task execution method embodiments and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0292] It should be noted that the collection, gathering, updating, analysis, processing, use, transmission, and storage of user personal information involved in this disclosed technical solution all comply with relevant laws and regulations, are used for legitimate purposes, and do not violate public order and good morals. Necessary measures are taken to prevent unauthorized access to user personal information data and to safeguard user personal information security and network security.

[0293] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0294] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0295] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.< / cost> < / latency> < / cost> < / latency>

Claims

1. A task execution method, characterized in that, include: Receive task requests from users; Based on the task request and / or user data, determine a candidate toolset related to the task request; The user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; The candidate toolset includes: tools or historical workflows; Identify the target tool or target workflow with the highest runtime performance index value in the candidate toolset; the runtime performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow; The task request is executed through the target tool or the target workflow.

2. The method according to claim 1, characterized in that, The user data is determined based on at least one of the following: The user identifier is determined based on the task request, and the user profile and historical interaction data are obtained through synchronous or asynchronous queries; the user identifier is determined based on the task request. Based on the user identifier, subscribe to the change data capture stream via direct database connection or message queue; Based on the task request, the environmental data, device status data, and network status data are obtained through the monitoring interface.

3. The method according to claim 1, characterized in that, Before determining the candidate toolset related to the task request based on the task request and / or user data, the method further includes: The user data is integrated and standardized to obtain structured user data; The structured user data is filtered using a language model to obtain user data related to the task request.

4. The method according to claim 3, characterized in that, The structured user data is filtered using a language model, including: The structured user data is filtered using the language model based on a preset threshold. The preset threshold is determined based on at least one of the following: the context window size of the language model, the task completion rate, the token consumption, the user satisfaction, the real-time load, and the urgency of the task request.

5. The method according to claim 1 or 3, characterized in that, Based on the task request and / or user data, a candidate toolset related to the task request is determined, including at least one of the following: Perform semantic analysis on the task request and map the task request to user intent nodes in the knowledge graph to determine the candidate tool or the historical workflow; The user's preferences are determined based on the user data, and the candidate tool or the historical workflow is determined based on the preferences. The nodes and relationships of the knowledge graph are mapped to a vector space, and the candidate tools or historical workflows that are similar to the vectors corresponding to the task request and the user data are queried in the vector space.

6. The method according to claim 5, characterized in that, The knowledge graph includes: nodes and the relationships between nodes; The node includes at least one of the following: user intent, workflow, tool call, smart agent, and contextual features; The node is accompanied by at least one of the following node attributes: success rate, average latency, average token cost, last execution time, application interface endpoint, input parameters, output results, and average error rate; The relationships include: triggering, using, associating, and executing.

7. The method according to claim 5, characterized in that, Executing the task request through the target tool or the target workflow includes: Based on the target model, the task request is executed through the target tool or the target workflow; Obtain the execution time, token consumption, and execution result of the task request; the execution result includes the decision information corresponding to the task request. The target model and the knowledge graph are optimized and updated based on the task request, the user data, the execution time, the token consumption, and the execution result.

8. The method according to claim 1, characterized in that, The user profile includes at least one of the following: the user's role, preferences, and historical purchase records; The device status data includes at least one of the following: device type, load status, CPU / GPU utilization, memory usage, and network status; The environmental data includes at least one of the following: network latency and application interface health status data.

9. A task execution device, characterized in that, include: The receiving module is used to receive user task requests; The first determining module is used to determine a candidate toolset related to the task request based on the task request and / or user data; the user data includes at least one of the following: user profile, historical interaction data, environmental data, and device status data; The candidate toolset includes: tools or historical workflows; The second determining module is used to determine the target tool or target workflow with the highest runtime performance index value in the candidate toolset; the runtime performance index value is determined based on at least one of the following: the relevance of the tool or the historical workflow to the task request, the complexity of the tool or the historical workflow, the resource consumption of the tool or the historical workflow, and the timeliness of the tool or the historical workflow; An execution module is used to execute the task request through the target tool or the target workflow.

10. A task execution device, characterized in that, include: Transceiver, processor, memory, and programs or instructions stored in the memory and executable on the processor; When the processor executes the program or instructions, it implements the steps of the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 8.

Images