Intelligent agent selection method, task processing method, device, equipment, medium and product

Abstract

The invention relates to an agent selection method and device, a task processing method and device, equipment, a medium and a product. The method comprises the steps of obtaining a target task and preference information for the target task; decomposing the target task to obtain sub-tasks of the target task; obtaining capability labels of the candidate intelligent agents; the capability label comprises quantized values of a plurality of capability dimensions; according to a weight vector in the preference information, carrying out weighted calculation on the quantized numerical value of each capability dimension of the candidate intelligent agent to obtain a comprehensive score of the candidate intelligent agent; and based on the comprehensive score, selecting a target agent for executing the subtask from the candidate agents. By adopting the method, the resource utilization efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for selecting intelligent agents, a task processing method, an apparatus, a device, a medium, and a product. Background Technology

[0002] In multi-agent task scheduling systems, there are usually multiple agents with the same or similar functions to choose from. Current common scheduling strategies, such as random allocation, round-robin, or load balancing, mainly focus on the availability or simple load status of agents to ensure that tasks are functionally executed.

[0003] Due to the lack of a quantitative evaluation mechanism for the multidimensional performance of intelligent agents, the system struggles to make intelligent optimal decisions based on the specific needs of task execution (such as high speed, low cost, etc.), resulting in low overall resource utilization efficiency of the system. Summary of the Invention

[0004] Therefore, it is necessary to provide a method for selecting intelligent agents, a task processing method, an apparatus, a device, a medium, and a product that can improve resource utilization efficiency in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for selecting an agent, the method comprising:

[0006] Obtain the target task and the preference information related to the target task;

[0007] The target task is decomposed into subtasks.

[0008] Obtain the capability labels of candidate agents; capability labels include quantified values ​​of multiple capability dimensions;

[0009] Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent;

[0010] Based on the comprehensive score, the target agent for performing the sub-task is selected from the candidate agents.

[0011] Secondly, this application provides a task processing method, which includes:

[0012] Obtain a structured execution plan for the target task; wherein the structured execution plan includes multiple subtasks of the target task, the execution logical order between the subtasks, and the target intelligent agent corresponding to each subtask; the target intelligent agent is determined based on the intelligent agent selection method of any one of the first aspects;

[0013] According to the execution logic order, the target intelligent agent corresponding to each subtask is called in turn to execute the corresponding subtask and obtain the subtask execution result;

[0014] The task processing result of the target task is generated based on the execution result of the subtask.

[0015] Thirdly, this application also provides an agent selection device, which includes:

[0016] The information acquisition module is used to acquire the target task and the preference information for the target task;

[0017] The processing module is used to decompose the target task into subtasks.

[0018] The tag acquisition module is used to acquire the capability tags of candidate agents; the capability tags include quantified values ​​of multiple capability dimensions.

[0019] The calculation module is used to perform weighted calculations on the quantified values ​​of each capability dimension of the candidate agent based on the weight vector in the preference information, so as to obtain the comprehensive score of the candidate agent.

[0020] The selection module is used to select the target agent for performing sub-tasks from the candidate agents based on a comprehensive score.

[0021] Fourthly, this application also provides a task processing apparatus, the apparatus comprising:

[0022] The acquisition module is used to acquire a structured execution plan for the target task; wherein, the structured execution plan includes multiple subtasks of the target task, the execution logical order between the subtasks, and the target agent corresponding to each subtask;

[0023] The calling module is used to sequentially call the target agent corresponding to each subtask to execute the corresponding subtask according to the execution logic order, and obtain the execution result of the subtask;

[0024] The generation module is used to generate the task processing results of the target task based on the execution results of the subtasks.

[0025] Fifthly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0026] Obtain the target task and the preference information related to the target task;

[0027] The target task is decomposed into subtasks.

[0028] Obtain the capability labels of candidate agents; capability labels include quantified values ​​of multiple capability dimensions;

[0029] Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent;

[0030] Based on the comprehensive score, the target agent for performing the sub-task is selected from the candidate agents.

[0031] Sixthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0032] Obtain the target task and the preference information related to the target task;

[0033] The target task is decomposed into subtasks.

[0034] Obtain the capability labels of candidate agents; capability labels include quantified values ​​of multiple capability dimensions;

[0035] Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent;

[0036] Based on the comprehensive score, the target agent for performing the sub-task is selected from the candidate agents.

[0037] Seventhly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0038] Obtain the target task and the preference information related to the target task;

[0039] The target task is decomposed into subtasks.

[0040] Obtain the capability labels of candidate agents; capability labels include quantified values ​​of multiple capability dimensions;

[0041] Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent;

[0042] Based on the comprehensive score, the target agent for performing the sub-task is selected from the candidate agents.

[0043] The aforementioned agent selection method, task processing method, apparatus, device, medium, and product first acquire the target task and preference information for that task. This allows the server to activate only processing flows and computing resources highly relevant to the current task, avoiding indiscriminate loading or evaluation of all available agents, thus reducing unnecessary system initialization overhead and memory usage. Next, the target task is structurally decomposed into multiple subtasks. This decouples the complex task into independently allocable and executable units, enabling the server to perform refined resource matching based on the characteristics of each subtask. During the selection phase, the server filters based on a pre-built capability tag library, eliminating the need for real-time performance testing or complex evaluation of agents with each task allocation. Subsequently, based on the weight vector in the user preferences, the quantified values ​​of each capability dimension of the candidate agents are weighted and calculated to obtain a comprehensive score. This process integrates weights and quantified values, directly deriving the optimal solution ranking for the current task through efficient calculation. Finally, a target agent is selected based on the comprehensive score to execute a specific subtask. This mechanism ensures that each subtask is executed by the agent with the highest score under the current conditions. This precise allocation maximizes the expertise of each agent, avoiding task execution timeouts, repeated attempts, or retries due to capability mismatch, thereby directly reducing the waste of time and computing resources during execution and improving resource utilization efficiency. Attached Figure Description

[0044] Figure 1 A flowchart of a function-driven static agent scheduling process;

[0045] Figure 2 This is a flowchart of the rule-based filtering process;

[0046] Figure 3 This is a diagram illustrating the application environment of an agent selection method in one embodiment.

[0047] Figure 4 This is a flowchart illustrating the agent selection method in one embodiment;

[0048] Figure 5 This is a flowchart illustrating a task processing method in one embodiment;

[0049] Figure 6 This is a flowchart illustrating the agent selection method in another embodiment;

[0050] Figure 7 A flowchart illustrating the process of selecting a method for an agent;

[0051] Figure 8 The architecture diagram corresponding to the method selected for the intelligent agent;

[0052] Figure 9This is a structural block diagram of an agent selection device in one embodiment;

[0053] Figure 10 This is a structural block diagram of a task processing device in one embodiment;

[0054] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0056] With the development of artificial intelligence technology, multi-agent task planning and scheduling systems have been widely used in the field of complex task processing. In such systems, multiple agents with the same or similar functions are usually deployed to provide redundancy and parallel processing capabilities.

[0057] Currently, the scheduling strategies for this type of system are mainly based on the functional matching of the agent or simple operational state, specifically manifested in the following two schemes:

[0058] Reference Figure 1 As shown, Figure 1 The system employs a function-driven static agent scheduling flowchart, maintaining a registry containing descriptions of each agent's capabilities (e.g., labeling an agent as "capable of performing searches"). After generating a task plan, the system selects an agent from the registry based solely on the degree of capability matching, either randomly or through round-robin. The drawback of this approach is that the selection process lacks consideration for non-functional attributes of the agents, completely ignoring differences in performance, cost, and quality among different agents, thus failing to guarantee overall optimal task execution.

[0059] Reference Figure 2 As shown, Figure 2 This is a flowchart of a rule-based filtering process. The system pre-defines several static rules, such as "select the most recently active agent" or "select the agent with the lowest current load," and filters and schedules agents based on these single rules. The limitation of this approach is that the rules themselves are fixed and have a single dimension, making it unable to handle complex optimization objectives that take into account multiple dimensions and are flexible (such as "maximizing speed while controlling costs"), and difficult to flexibly respond to diverse real-time user preferences.

[0060] However, both of these strategies have significant technical limitations. They focus only on the basic availability, simple load, or static rules of agents, completely ignoring the multidimensional differences in non-functional attributes of agents. In actual operation, even agents with the same functionality often exhibit significant differences in key dimensions such as execution speed, resource consumption, reliability, and result accuracy. Furthermore, due to the lack of a quantitative evaluation mechanism for the multidimensional performance of agents, existing systems cannot perceive and respond to users' specific preferences for task execution paths (such as prioritizing speed or cost control), resulting in scheduling decisions lacking specificity and adaptability.

[0061] The aforementioned technical deficiencies directly lead to the following problems: the scheduling strategy cannot make intelligent and optimal choices among multiple agents with similar functions, and the decision-making process lacks quantitative basis; the system configuration is rigid and it is difficult to adapt to the real-time and ever-changing service quality requirements of users; the actual performance of the agents may change dynamically or be inconsistent with the nominal capabilities, but the system lacks the ability to adapt and adjust, and may continue to make suboptimal decisions, resulting in low resource utilization efficiency and poor user experience.

[0062] Therefore, how to implement an intelligent scheduling method that can comprehensively and quantitatively evaluate the multi-dimensional capabilities of intelligent agents, dynamically adapt to user preferences, and possess continuous optimization capabilities has become a pressing technical problem in this field. Based on this, this application proposes an intelligent agent selection method to address the aforementioned problem.

[0063] The agent selection method provided in this application embodiment can be applied to, for example, Figure 3 The application environment is shown. Terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on other devices.

[0064] The agent selection method of this application is provided by Figure 3 The process involves collaboration between terminal 102 and server 104. In this collaborative process, server 104 first receives the target task and corresponding preference information sent by terminal 102. Next, it decomposes the target task into corresponding sub-tasks. Then, the server retrieves the capability tags of candidate agents from a capability tag library; these capability tags contain quantified values ​​for multiple capability dimensions. Following this, based on the weight vector in the preference information, it performs a weighted calculation on the quantified values ​​of each candidate agent across all capability dimensions to obtain a comprehensive score for each candidate agent. Finally, based on the comprehensive score, it selects a target agent from the candidate agents to execute the corresponding sub-task; then, it schedules the target agent to execute the corresponding sub-task, obtains the returned task execution result, and returns the final task execution result to terminal 102.

[0065] The terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart in-vehicle systems, and projection devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted displays. Head-mounted displays can be virtual reality (VR) devices, augmented reality (AR) devices, and smart glasses.

[0066] Server 104 can be a standalone physical server or a service node in a blockchain system. These service nodes form a peer-to-peer (P2P) network, where the P2P protocol is an application-layer protocol running on top of the Transmission Control Protocol (TCP). Alternatively, server 104 can be a server cluster consisting of multiple physical servers, and can be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, security services, content delivery networks (CDNs), and big data and artificial intelligence terminals.

[0067] In one embodiment, such as Figure 4 As shown, an agent selection method is provided, which can be applied to... Figure 3 Taking the server in the example, the following steps are included:

[0068] S201, Obtain the target task and the preference information for the target task.

[0069] In this context, a target task is a computational job with a clear purpose and an executable scope. Specifically, it refers to a complex instruction or problem description that a user inputs through an interactive interface, hoping that multiple agents will complete the task. For example, a user inputting a natural language instruction, "Help me analyze and summarize the three most recent technical articles about a certain artificial intelligence model," defines the final result to be achieved (the analysis and summary of the technical articles).

[0070] Preference information refers to additional constraints or optimization guidelines provided by users to guide the decision-making of multi-agent systems, going beyond the basic functional requirements of the task. Specifically, it refers to the user's statement of preference for the execution process or result in a non-functional dimension when performing a target task. For example, the text instruction "Please prioritize the most economical solution" attached by the user when submitting a task expresses the user's explicit preference in the "cost" dimension.

[0071] A weight vector is a set of numerical values ​​that quantifies the importance of each preference in a decision-making process. Specifically, it's a mathematical vector where each element corresponds to a specific capability dimension (such as cost or speed), and its value represents the relative importance of that dimension in the overall score. For example, a weight vector {"cost":0.8,"speed":0.2} indicates that in this decision, the "cost" dimension is four times more important than the "speed" dimension.

[0072] In this embodiment, the server receives a network request from a client application (such as a chatbot) via an application programming interface (API). The request body contains a data object whose task field carries the user-input natural language text (i.e., the target task), and its preference field carries another piece of guiding text (i.e., preference information). The server parses the request and extracts the content of these two fields. For example, the task might be "Create a one-week fitness and diet plan for me," and the preference might be "Focus on the plan's feasibility, followed by its professionalism." The server then activates its natural language understanding module to perform semantic analysis on these two texts.

[0073] In another embodiment, the server-provided interface allows users to specify preferences graphically. After submitting the target task of "detecting the stock market and generating a daily report," the user can see a component on the interface containing multiple sliders such as "execution speed," "computation cost," and "report depth." The user drags the "execution speed" slider to the highest priority and the "computation cost" slider to medium priority, and the interface generates and displays a corresponding weight vector in real time: {"speed": 0.7,"cost": 0.3}. This vector, along with the target task text, is encapsulated and sent to the server backend.

[0074] S202, decompose the target task to obtain the subtasks of the target task.

[0075] A subtask is a basic task unit generated after decomposition and processing, which can be assigned as an independent work unit to a single agent for execution. Specifically, it is a component of the target task and usually has clearly defined input, output, and execution logic. For example, crawling the full text of an article from a specified website is a subtask, which can be independently assigned to a web crawling agent to complete.

[0076] In this embodiment, the server decomposes the target task into subtasks. For example, the acquired target task text is input into a pre-trained large language model, and the model is prompted to "decompose this complex task into executable steps". The model returns a list of steps, such as: ["Step 1: Perform a web search based on the keywords 'a certain model', 'technical article', and 'the three most recent articles'", "Step 2: Select the three most relevant links from the search results and extract the article text", "Step 3: Extract the core technical arguments of the three articles respectively", "Step 4: Synthesize the arguments of the three articles and write a comparative summary report"]. The server recognizes each step in this list as an independent subtask.

[0077] In another embodiment, the server internally maintains a task template library for specific vertical domains (such as financial analysis). When receiving a target task such as "Generate a quarterly financial risk summary for a company," the server first uses an intent recognition module to determine that it belongs to the "financial analysis" domain, and then calls the corresponding task decomposition template. This template is a predefined workflow that includes fixed steps such as "obtaining the company's latest financial report," "calculating key financial ratios," "obtaining industry average data," "conducting ratio comparison analysis," "identifying abnormal risk points," and "generating a narrative summary." Based on the specific company name and quarterly information in the target task, the server instantiates the template, fills in specific parameters, and thus generates a series of specific subtasks.

[0078] S203, Obtain the capability labels of the candidate agents; the capability labels include quantified values ​​of multiple capability dimensions.

[0079] In this context, a candidate agent is the set of all agent instances that are functionally qualified to perform a given subtask. Specifically, in a multi-agent system, it refers to agents whose registration information indicates they can perform the functions required for that subtask. For example, for the subtask of "scraping the main text of an article," all agents registered in the system with the capability of "web scraping" are candidate agents.

[0080] Capability tags are a set of metadata used to describe the performance level of candidate agents in various non-functional capabilities. Specifically, it is a structured data record that provides comparable quantitative values ​​for each agent across multiple dimensions. For example, an agent's capability tags might be stored in a specific data format: {"Cost per call": 0.05,"Average latency in milliseconds": 150,"Reliability": 0.95,"Data freshness in hours": 1}.

[0081] A capability dimension is a specific perspective or attribute category for evaluating the performance of an agent. Specifically, it is each independent evaluation metric included in the capability label, reflecting a particular aspect of the agent's performance characteristics. For example, "cost per call," "average response latency," and "task success rate" are all different capability dimensions.

[0082] A quantified value is a specific, mathematically calculable, and comparable number within a capability dimension of a capability label. Specifically, it is the result of measuring and digitizing the agent's performance in that dimension. For example, in the dimension of "average response latency," agent A's quantified value is "80," and agent B's quantified value is "200," both in milliseconds.

[0083] In this embodiment, the server obtains the capability tags of each candidate agent. For example, after determining that the current subtask to be assigned is "image style transfer," the server queries the central registry to find a list of agent identifiers whose function descriptions contain "image style transfer." The agents corresponding to these identifiers are the candidate agents. Next, the server accesses a separate "capability tag database," using these agent identifiers as keys to query and batch retrieve their latest capability tags. Each tag is a document that lists quantitative values ​​such as "processing time": 2.5, "cost": 0.1, and "output quality score": 0.88, along with their corresponding capability dimensions.

[0084] S204. Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent.

[0085] The overall score is a single numerical result calculated using weighted averages to compare the overall priority of different candidate agents. Specifically, it is a final quantitative evaluation obtained by comprehensively weighing the agent's performance across all considered capability dimensions according to user preference information. The higher the score, the more suitable the agent is for performing the task under the current preferences.

[0086] In this embodiment of the application, the server performs weighted calculations on the quantified values ​​of each capability dimension of the candidate agent based on the weight vector in the preference information to obtain the comprehensive score of the candidate agent.

[0087] For example, the parsed weight vector is {"Cost":0.7,"Speed":0.3}. For each candidate agent, the server extracts the quantified values ​​corresponding to "Cost" and "Latency" from its capability labels. Since the cost value (e.g., 0.1 yuan) and the latency value (e.g., 200 milliseconds) have different dimensions, and both cost and latency are better the lower they are, the server first normalizes the values ​​of these two dimensions separately (e.g., for "Cost," it uses the formula 1 - (current value / maximum value) for inverse normalization, making it better the higher it is). Then, the server performs a weighted calculation: multiplying the normalized cost score by 0.7 and the normalized latency score by 0.3, and then adding the two products to obtain the agent's comprehensive score.

[0088] In another embodiment, the weight vector can be derived from solving a multi-objective optimization function. For example, the user preference is "the fastest speed under the premise that the cost does not exceed 0.2 yuan". The server transforms this into a constrained optimization problem. For each candidate agent, its cost quantification value is first checked to see if it meets the constraint (≤0.2 yuan), and those that do not meet the constraint are eliminated. For agents that meet the constraint, instead of performing a simple weighted summation, the latency quantification value is directly used as the comprehensive score (at this time, the lower the latency, the higher the score), because cost has already served as a hard filtering condition.

[0089] S205, based on the comprehensive score, select the target agent from the candidate agents to perform the sub-task.

[0090] In this context, the target agent refers to the agent that, after a selection process, is ultimately determined and assigned to execute a specific sub-task. Specifically, it is the unique instance from the set of candidate agents that wins the selection within the current scheduling cycle based on a comprehensive score and selection rules. The target agent will receive task input, consume computational resources, and generate task output.

[0091] In this embodiment, the server selects the target agent for performing the sub-task from candidate agents based on a comprehensive score. For example, for the sub-task "generate a summary," candidate agents A, B, and C have scores of 0.85, 0.92, and 0.78, respectively. The server uses a highest-score selection strategy, directly comparing these values ​​to identify agent B (0.92 points), which has the highest score. Subsequently, the server generates a task allocation instruction, sending the specific parameters of the "generate summary" sub-task (such as the text to be summarized) to agent B's service interface. At this point, agent B is officially determined as the target agent for performing the sub-task.

[0092] In another embodiment, the server also calculates a comprehensive score for all candidate agents. However, it does not always select the agent with the absolute highest score. The server maintains a counter for each agent's "recent selection count." During selection, the server combines the comprehensive score with a decay factor based on this counter to produce an "adjusted score." For example, even if agent D's original comprehensive score (0.90) is slightly lower than agent E's (0.95), because agent E has been frequently selected recently, its adjusted score may drop to 0.88, while agent D's adjusted score may become 0.91, thus making agent D the target agent in this round. This method prevents high-performing agents from being overloaded while ensuring that newly added or improved agents have a chance to be selected to perform tasks, achieving a long-term balance between load and opportunity.

[0093] In the above embodiments, firstly, the target task and its associated preferences are acquired. This allows the server to activate only processing flows and computing resources highly relevant to the current task, avoiding the indiscriminate loading or evaluation of all available agents, thus reducing unnecessary system initialization overhead and memory usage. Next, the target task is structurally decomposed into multiple subtasks. This decouples the complex task into independently allocable and executable units, enabling the server to perform refined resource matching based on the characteristics of each subtask. During the selection phase, the server filters based on a pre-built capability tag library, eliminating the need for real-time performance testing or complex evaluation of agents each time a task is assigned. Subsequently, based on the weight vector in the user preferences, the quantified values ​​of each capability dimension of the candidate agents are weighted and calculated to obtain a comprehensive score. This process integrates weights and quantified values, directly deriving the optimal solution ranking for the current task through efficient calculation. Finally, a target agent is selected to execute a specific subtask based on the comprehensive score. This mechanism ensures that each subtask is executed by the agent with the highest score under the current conditions. This precise allocation maximizes the expertise of each agent, avoiding task execution timeouts, repeated attempts, or retries due to capability mismatch, thereby directly reducing the waste of time and computing resources during execution and improving resource utilization efficiency.

[0094] In one embodiment, the weight vector in the aforementioned preference information includes the weights of each capability dimension. Based on this, the aforementioned "weighted calculation of the quantified values ​​of each capability dimension of the candidate agent according to the weight vector in the preference information to obtain the comprehensive score of the candidate agent" includes:

[0095] The quantified values ​​of each ability dimension are normalized to obtain a normalized score for each ability dimension. Based on the weights of the corresponding ability dimensions in the weight vector, the normalized scores are weighted and summed to obtain a comprehensive score.

[0096] The normalized score is a standardized numerical value obtained after normalization, used to represent the relative performance level of an agent in a specific capability dimension. Specifically, it is a scalar whose magnitude directly reflects the agent's performance relative to all candidate agents in that dimension. The normalized score falls within a predefined range (e.g., 0 to 1), with a higher score indicating better performance in that dimension. For example, agent A has an original value of 80 milliseconds in the "latency" dimension, which, after normalization, yields a score of 0.9; agent B has an original value of 200 milliseconds, which, after normalization, yields a score of 0.2. This shows that agent A performs significantly better than agent B in the "latency" dimension.

[0097] Weighted summation is a multi-indicator comprehensive evaluation method. It multiplies multiple input values ​​(here, the normalized scores of each dimension) by coefficients reflecting their importance (here, the corresponding weights in the weight vector), and then sums all the products to obtain a comprehensive single value. Specifically, its mathematical expression is usually: Comprehensive Score = Σ(Weight × Normalized Score). The core idea of ​​this method is to assign different importance to different dimensions according to user preferences, and the final comprehensive result reflects the overall performance across all considered dimensions after weighting according to user preferences.

[0098] The overall score is a single quantitative metric used to rank and compare candidate agents, calculated through a weighted summation process. Specifically, it integrates the agent's performance across various capability dimensions and incorporates user preference information (represented by a weight vector), thus representing the agent's overall suitability within the current task context and user preferences. A higher score indicates that the agent better meets the overall expectation of "excelling in aspects valued by the user." For example, based on the preference of "prioritizing cost," with a weight vector of {"cost": 0.8, "speed": 0.2}, an agent with extremely low cost but slightly slower speed might have a higher overall score than an agent with extremely high speed but high cost.

[0099] In this embodiment, the server first normalizes each capability dimension. For example, for the dimensions of "cost" and "latency," the server collects the raw quantified values ​​of all candidate agents in these two dimensions and finds the maximum and minimum values ​​for each dimension. For cost (lower values ​​are better), the normalized score is calculated using the formula: normalized score = (maximum value - current value) / (maximum value - minimum value); the same formula is used for latency (lower values ​​are better as well). Next, the server parses a weight vector from user preferences, for example, {"cost": 0.7, "latency": 0.3}. Then, for each agent, the server performs a weighted summation process: multiplying its normalized cost score by 0.7 and its normalized latency score by 0.3, and adding the two products together, the sum is the agent's comprehensive score. Finally, all agents are ranked according to their respective comprehensive scores.

[0100] In another embodiment, instead of simply using maximum and minimum values, the server defines an "ideal value" (e.g., an ideal cost value of 0, an ideal latency value of 10 milliseconds) and a "worst value" for each capability dimension. Normalization is performed by calculating the distance between the current value and the ideal and worst values, for example, using the formula Normalized Score = (Worst Value - Current Value) / (Worst Value - Ideal Value). This more stably handles uneven data distribution. When performing weighted summation, the server does not directly multiply and add fixed weights. It introduces the concept of a "weight effectiveness threshold": only when the agent's normalized score in a certain dimension exceeds a preset threshold for that dimension is the weight corresponding to that dimension fully included in the overall score; if it is below the threshold, it is discounted proportionally. For example, for the "reliability" dimension, the weight is 0.4, and the threshold is 0.8. If agent A's reliability normalized score is 0.9 (above the threshold), its reliability contribution is 0.9 * 0.4 = 0.36; if agent B's reliability score is 0.7 (below the threshold), its contribution might be 0.7 * 0.4 * (0.7 / 0.8) = 0.245. This method ensures that the comprehensive score not only reflects performance levels but also introduces a certain "weakest link effect," guaranteeing that the selected target agents meet the basic requirements in all key dimensions.

[0101] In the above embodiments, the quantified values ​​of each capability dimension are normalized to obtain a normalized score for each capability dimension; based on the weights of the corresponding capability dimensions in the weight vector, the normalized scores are weighted and summed to obtain a comprehensive score; in this method, the normalization operation eliminates the differences in dimensions and scales between different capability dimensions, making the scores of each dimension within a fair and comparable range, providing an unbiased data foundation for subsequent weighted calculations, thereby reducing the risk of resource misallocation caused by data standardization issues.

[0102] In one embodiment, the aforementioned "normalizing the quantified values ​​of each capability dimension to obtain a normalized score for each capability dimension" includes:

[0103] For the inverse indicator dimension within the capability dimension, the quantified values ​​of the inverse indicator dimension are subjected to inverse normalization to obtain a normalized score for the inverse indicator dimension. For the positive indicator dimension within the capability dimension, the quantified values ​​of the inverse indicator dimension are subjected to linear normalization to obtain a normalized score for the positive indicator dimension. Here, the inverse indicator dimension refers to the capability dimension where smaller values ​​indicate better performance; the positive indicator dimension refers to the capability dimension where larger values ​​indicate better performance. The linear normalization process is configured to make the quantified values ​​and normalized scores positively correlated; the inverse normalization process is configured to make the quantified values ​​and normalized scores negatively correlated.

[0104] Among them, the inverse indicator dimension is a category of capability dimensions, and its performance is judged by the criterion that "the smaller the value, the better the performance." Specifically, it reflects the attributes that people expect the intelligent agent to minimize in terms of resource consumption, waiting time, and other cost-related indicators when completing a certain task. For example, "cost per call (yuan)," "average task response time (milliseconds)," and "unit output power consumption (watts)" are all inverse indicator dimensions. The lower the value, the higher the efficiency and the better the performance of the intelligent agent in that aspect.

[0105] Positive metrics are another category of capability dimensions, where performance is judged by the criterion that "the higher the value, the better the performance." Specifically, they reflect the attributes that, when an agent completes a task, people expect to maximize the output quality, stability, and other benefit-related indicators. For example, "task execution success rate (percentage)," "output accuracy (percentage)," and "data update frequency (times / day)" are all positive metrics; the higher the value, the stronger the agent's capability and the better its performance in that area.

[0106] Inverse normalization is a special normalization method designed for inverse performance metrics. Its core principle is to reverse the relationship between numerical magnitude and performance quality during the mapping of original values ​​to a standard interval (e.g., [0,1]). Specifically, through specific mathematical transformations, smaller values ​​(corresponding to better performance) in the original data are mapped to larger normalized scores, while larger values ​​(corresponding to worse performance) are mapped to smaller scores. For example, a commonly used inverse normalization formula is: Normalized Score = (Maximum Value - Current Value) / (Maximum Value - Minimum Value). This ensures that the transformed scores conform to the unified evaluation standard of "the larger the score, the better the performance."

[0107] Linear normalization is a standard normalization method used for positive performance metrics. Its core principle is to maintain consistency between numerical magnitude and performance performance while mapping the original values ​​to a standard interval (e.g., [0,1]). Specifically, through mathematical transformation, larger values ​​(corresponding to better performance) are mapped to larger normalized scores, and smaller values ​​(corresponding to worse performance) are mapped to smaller scores, with a positive correlation between the two. For example, a commonly used linear normalization formula is: Normalized score = (current value - minimum value) / (maximum value - minimum value).

[0108] A positive correlation is a trend between two variables, where an increase in the value of one variable leads to an increase in the value of the other. In the claims, the linear normalization process is configured to make the quantized value and the normalized score positively correlated; specifically, the normalized score after processing monotonically increases as the original quantized value increases, ensuring consistency in the direction of performance improvement before and after the transformation.

[0109] A negative correlation is a trend of opposite change between two variables; that is, when the value of one variable increases, the value of the other variable decreases. In the claims, the inverse normalization process is configured to make the quantized value and the normalized score negatively correlated, specifically meaning that the normalized score after processing decreases monotonically as the original quantized value increases, thus reversing the evaluation criteria for performance quality.

[0110] In this embodiment, the server pre-defines capability dimension types in the configuration file: {"Cost": "Reverse", "Latency": "Reverse", "Reliability": "Forward", "Accuracy": "Forward"}. When the server processes the capability tags of a candidate agent, it first reads the agent's raw quantified values ​​for each dimension, for example: {"Cost": 0.2, "Latency": 80, "Reliability": 0.98, "Accuracy": 0.95}. Next, the server identifies the capability dimension types, determining that "Cost" and "Latency" belong to reverse indicator dimensions, while "Reliability" and "Accuracy" belong to forward indicator dimensions. Then, the server finds the maximum and minimum values ​​for each dimension in the candidate pool. Assume that in the "Cost" dimension, the values ​​of all candidate agents are between [0.1, 1.0]. For the negative metric dimension "cost", the server applies inverse normalization: the agent's score = (1.0 - 0.2) / (1.0 - 0.1) = 0.8 / 0.9 ≈ 0.89. For the positive metric dimension "reliability", assuming the value is between [0.90, 0.99], the server applies linear normalization: the agent's score = (0.98 - 0.90) / (0.99 - 0.90) = 0.08 / 0.09 ≈ 0.89. Ultimately, the original values ​​for all dimensions are converted into comparable normalized scores with consistent direction.

[0111] In another embodiment, when the server receives a new set of capability dimensions (e.g., a newly added "peak memory usage" dimension), it initiates an analysis process to determine its type. The server first analyzes the distribution of all agent values ​​for that dimension over a period of time and performs correlation analysis in conjunction with task execution performance logs. If the statistical analysis shows a significant negative correlation between the dimension's value and task execution success rate or user satisfaction (i.e., the larger the value, the worse the performance), it is automatically identified as a negative indicator dimension; if a significant positive correlation is found, it is identified as a positive indicator dimension. After determining the type, during normalization, the server no longer simply uses global maximum and minimum values, but instead employs a robust normalization method based on normal distribution quantiles. For example, for a negative indicator dimension, the percentile P of the current value is calculated (the smaller the value, the larger P), and then the normalized score is defined as P / 100. For a positive indicator dimension, the percentile P is also calculated (the larger the value, the larger P), and then the normalized score is defined as P / 100. This method avoids the excessive influence of extreme values ​​on the normalization results, making the processing more robust, especially suitable for scenarios where the data distribution may be skewed or outliers may exist.

[0112] In the above embodiments, firstly, the method ensures that the evaluation logic of the scores of all capability dimensions is consistent with the actual business meaning by distinguishing between positive and negative indicators and adopting the corresponding normalization direction. This processing unifies the optimization direction of indicators of different natures at the data level, so that the scoring results can intuitively reflect the quality of comprehensive performance, avoid decision misguidance caused by inconsistent evaluation logic, and fundamentally improve the accuracy of resource matching.

[0113] In one embodiment, the above-mentioned "decomposing the target task to obtain subtasks of the target task" includes:

[0114] The target task is semantically parsed and the steps are serialized to obtain a directed acyclic graph.

[0115] The directed acyclic graph consists of multiple task nodes, and each task node corresponds to a subtask.

[0116] A directed acyclic graph (DAG) is a graph consisting of task nodes and directed edges connecting these nodes. The edges indicate the direction of dependencies between nodes (e.g., A→B means B depends on A or A is executed before B), and there are no circular paths in the graph (i.e., starting from a node and following an edge, it is impossible to return to itself). This structure is naturally suitable for representing subtasks decomposed into tasks and their dependencies. For example, a simple DAG might contain three nodes: A (acquire data), B (process data), and C (generate a report), with edges A→B and B→C, indicating that data must be acquired before processing, and a report can only be generated after data processing.

[0117] Task nodes are the basic units that make up a directed acyclic graph (DAG), representing an atomic or independently schedulable unit of operation. Specifically, each task node encapsulates the execution logic description, input data requirements, and expected output of a subtask. In the graph, nodes are typically represented graphically, with attributes including node ID, corresponding subtask description, and state. For example, in a DAG of a data analysis task, there might be a task node with ID "N2," described as "calculate the month-on-month growth rate of sales data," whose input depends on the output of its predecessor node "N1" (which retrieves the raw data).

[0118] In this embodiment, the server performs semantic parsing and step serialization on the target task to obtain a directed acyclic graph. For example, the server receives the user's input target task: "Summarize the three most recent news articles about the technological advancements of large-scale models." First, the server performs semantic parsing: using a pre-trained language model, it identifies the core action as "summarize," the object as "news," and the limiting conditions as "recent," "three articles," and "about the technological advancements of large-scale models." Next, it performs step serialization: based on general task planning knowledge, the server infers that completing the task requires four steps: "searching for news," "filtering relevant articles," "extracting key information," and "comprehensively writing a summary," and determines that their dependencies are sequential. Then, the server instantiates these steps as task nodes and constructs a directed acyclic graph based on the dependencies. This graph contains four nodes: node 1 (search), node 2 (filter), node 3 (extract), and node 4 (write), and there are directed edges: 1→2, 2→3, 3→4. Finally, the server outputs this DAG as the result of task decomposition, where each node (such as node 1) corresponds precisely to a subtask to be assigned ("search for the latest news on the progress of large model technology").

[0119] In another embodiment, firstly, semantic parsing not only identifies basic elements but also links entities in the target task (such as "large model" or "news") to an internal domain knowledge graph that defines the relationships between concepts and the operations that can be applied. For example, the knowledge graph might show that "news" can be obtained through a "search engine" and processed by a "text summarization model." Then, the step-sequence processing is modeled as a constraint satisfaction and optimization problem. The server generates a candidate set of possible operation steps based on the knowledge graph, considering user preferences (such as "speed priority") as optimization objectives and incorporating resource constraints (such as available agent types). Finally, using a constraint solver or planning algorithm, a sequence of steps that satisfies all dependencies (such as certain models requiring specific data input formats) and the optimization objective is searched in the candidate space, outputting it as a directed acyclic graph (DAG). For example, for the task of "translating a Chinese technical document and generating a bilingual version," the system might plan a complex DAG consisting of multiple parallel and serial nodes, including "document parsing," "chapter segmentation," "machine translation," "format alignment," and "typesetting generation," to maximize the use of parallel processing capabilities and shorten the overall completion time.

[0120] In the above embodiments, the structured representation of the directed acyclic graph clearly defines the dependencies and execution order between tasks. Semantic parsing transforms natural language or structured instructions into a machine-understandable sequence of steps, and then the task flow is visualized and structured, enabling the identification of which subtasks can be executed in parallel and which must be executed sequentially. This provides topological constraints for subsequent agent scheduling, thereby maximizing parallel processing potential and shortening overall execution time.

[0121] In one embodiment, after the above-mentioned "selecting a target agent from candidate agents for performing a sub-task based on a comprehensive score", the method further includes:

[0122] The target agent is bound to the subtask corresponding to the task node in the directed acyclic graph, and the bound subtask is executed based on the target agent.

[0123] In this embodiment of the application, the server binds the target agent to the subtask corresponding to the task node in the directed acyclic graph, and executes the bound subtask based on the target agent.

[0124] For example, after selecting agents for each task node in the DAG, binding is performed. For node "N2: Data Cleaning", assume the selected target agent is D. The server updates the assigned_agent_id field in the data structure of DAG node N2 with D's identifier in memory or persistent storage. Subsequently, the scheduling engine begins to monitor the execution status of the DAG. When node N1 (data acquisition) completes execution and the output data is ready, the scheduling engine checks the status of node N2 and finds that it has completed binding. Then, the scheduling engine executes the action of binding the subtask based on the target agent: it finds D's service address based on D's registration information, constructs an execution request, takes the output of node N1 as input parameters, and sends it to D via remote procedure call, thereby starting the execution of the data cleaning subtask.

[0125] In the above embodiments, by fixing the selected target agent to a specific task node, the target agent for each subtask is determined, avoiding decision delays and resource contention caused by dynamic scheduling during execution. Secondly, the target agent is the optimal execution unit selected based on its capability tags and task requirements. After binding, it will be dedicated to handling the assigned subtask, preventing interruption or resource contention by other unrelated tasks during execution. This allows the agent to perform at its best while focused, reducing the decrease in execution efficiency caused by multitasking.

[0126] In one embodiment, the aforementioned "acquiring the capability tags of candidate agents" includes:

[0127] Retrieve the capability tags of candidate agents from a pre-defined capability tag library.

[0128] The pre-defined capability tag library is a centralized data storage system dedicated to storing and managing all non-functional capability information of intelligent agents. Specifically, it is a database or registry center whose access address, data mode, and storage backend are configured during system deployment or initialization, and data is organized according to a predefined structure to support efficient querying. For example, the capability tag library can be seen in Table 1.

[0129] Table 1

[0130] Candidate agents Ability Tags Quantitative values Latest update timestamp agent a latency / milliseconds 150 20XX-XX-XX agent a Cost per call 0.05 20XX-XX-XX agent b latency / milliseconds 80 20XX-XX-XX agent b Cost per call 0.12 20XX-XX-XX

[0131] A capability tag is a structured data unit that represents an agent's historical performance and current state in a specific non-functional dimension. Specifically, it is a record or data object in a pre-defined capability tag library, containing two core elements: a quantified numerical value and a recent update timestamp. These elements together describe the agent's "performance score" in a particular capability dimension and the "freshness" of that score. For example, a capability tag could be {"Dimension":"Latency","Value":150,"Unit":"Milliseconds","Update Time":"20XX-XX-XX"}.

[0132] A quantified value is a numerical value used in capability tags to precisely measure an agent's performance level in a specific capability dimension. Specifically, it is a scalar quantity derived through measurement, statistics, or calculation, possessing a clear physical or logical meaning and unit, allowing for objective comparisons of the performance of different agents in the same dimension. For example, for the "cost" dimension, its quantified value might be 0.05 (representing a cost of 0.05 monetary units per call); for "reliability," it might be 0.98 (representing a historical task success rate of 98%).

[0133] The latest update timestamp is the identifier in the capability tag that records the last time the tag information (mainly referring to quantified values) was modified or confirmed. Specifically, it is a time data, usually in a standard time format, used to determine the timeliness of the data, and is crucial for assessing the reliability of the data and deciding whether an update is needed.

[0134] Key-value pair storage is a simple data model that organizes data into associated "keys" and "values". Specifically, within the context of a pre-defined capability tag library, it means that the index (key, such as agent_a:latency) and its specific content (value, such as {"value":150,"updated_at":"20XX-XX-XX"}) of each capability tag are stored in pairs. This format allows for fast retrieval using a unique key.

[0135] In this embodiment, the server retrieves the capability tags of candidate agents from a pre-defined capability tag library. For example, when selecting agents for the subtask "text summarization," three candidate agents are identified: Agent_1, Agent_2, and Agent_3. Next, the server performs a retrieval operation: it sends a batch query request to a pre-defined capability tag library, the request body containing a list of IDs for the three agents. Upon receiving the request, the capability tag library service searches its internal database for the record corresponding to each ID. Each record (i.e., a capability tag) contains quantified values ​​for multiple dimensions (e.g., "accuracy: 0.92", "speed: 200ms") and the corresponding latest update timestamp. This data is stored in the database as key-value pairs; for example, the primary key is a combination of the agent representation and the dimension name, and the corresponding record fields store the numerical value and timestamp. Finally, the capability tag library service encapsulates this tag data into an array and returns it to the server. The server receives and parses the array, completing the retrieval of the capability tags.

[0136] In another embodiment, the server employs an extended mechanism that supports versioning and incremental retrieval to access the capability tag library. This pre-defined capability tag library is designed to store not only the current value but also historical versions of each capability tag (i.e., a new version is generated with a timestamp each time the quantized value changes). When the server needs to retrieve capability tags for a batch of candidate agents, it first checks if the tags for these agents already exist in its local cache and records the cached version number or last retrieval time. Then, when the server sends a request to the capability tag library, it includes this "known version" information. Upon receiving the request, the capability tag library does not return complete tag data but performs a comparison: for each requested agent-dimension pair, if the latest update timestamp of its latest data is later than the "known version" time provided in the request, it returns the latest quantized value and update timestamp for that dimension; otherwise, it returns an "unchanged" identifier. The server updates its local cache based on the returned incremental information. This versioned design, using key-value pairs, makes retrieval operations more efficient in network transmission and data synchronization, making it particularly suitable for scenarios with a large number of agents and frequent capability tag updates.

[0137] In the above embodiments, firstly, capability tags are directly obtained from a pre-built capability tag library, avoiding the computational overhead of real-time evaluation. By pre-building a capability tag library, the capability tags of candidate agents can be quickly obtained through querying, eliminating the need to perform time-consuming performance tests or real-time data analysis during each task scheduling, thereby significantly reducing decision latency and computational resource consumption. Secondly, the quantified values ​​and latest update timestamps contained in the capability tags are stored in key-value pairs, enhancing the structure and manageability of the data. The quantified values ​​directly provide specific data for the capability dimensions used in scoring calculations, while the latest update timestamp records the last update time of the value. The two are stored together as a key-value pair, enabling efficient retrieval and verification of data timeliness.

[0138] In one embodiment, the above agent selection method further includes:

[0139] After the target agent executes a subtask, the performance data of the subtask is obtained. The performance data includes at least one of execution time, resource consumption, and execution success indicator. Based on the performance data, the quantitative values ​​of the target agent in the corresponding capability dimension are adjusted to obtain the updated quantitative values.

[0140] Performance data refers to the set of raw metrics that reflect the characteristics and outcome status of a target agent during the completion of a sub-task. Specifically, it is observable data generated during the agent's runtime, used to evaluate its performance afterward. For example, after an image processing task, the system records that the execution time from the start of the call to receiving the result was 205 milliseconds, the resource consumption of this call was 0.15 CPU cores, and the execution success flag derived from the result verification was "success".

[0141] Execution time is a type of performance data that refers to the length of time it takes for a target intelligent agent to process a subtask from the start to the output of a final result (or explicit failure). Specifically, it is a time interval metric that reflects the speed at which the agent processes the task, usually expressed in units such as milliseconds or seconds. For example, if a natural language translation agent processes a 100-word text and takes a total of 1200 milliseconds from receiving the request to returning the translation result, this time is the execution time.

[0142] Resource consumption is a type of performance data that refers to the total amount of system computing resources used or consumed by a target intelligent agent during the execution of a subtask. Specifically, it can include multiple aspects such as CPU time, memory usage, GPU utilization, network I / O, and disk read / write operations, and is typically used to measure the economic cost of task execution. For example, a data encryption agent consuming a total of 5 seconds of CPU time and 50MB of peak memory while processing a 1GB file; these metrics collectively constitute resource consumption data.

[0143] The execution success flag is a type of performance data; it's a discrete state marker indicating whether the target agent's execution of a subtask resulted in success or failure. Specifically, it's a Boolean or enumerated value, potentially determined based on result verification, timeout checks, anomaly detection, or the agent's self-reported state. For example, in a web scraping task, if the returned HTTP status code is 200 and the content matches expectations, the execution success flag is marked as "success"; if the connection times out, it's marked as "failure."

[0144] The updated quantization value is a new quantization value generated after an adjustment process and will be written back to the preset capability tag library. Specifically, it represents the system's latest estimate of the agent's performance in a specific capability dimension after incorporating the observations from this execution. For example, if the agent's original "average latency" quantization value was 180 milliseconds, based on the execution time of 150 milliseconds in this instance, a new updated quantization value of 175 milliseconds was generated after adjustment using a smoothing algorithm.

[0145] In this embodiment, the target agent Agent_E completes a "video transcoding" subtask. After the task is completed, the detection agent deployed next to the agent's runtime environment automatically collects the performance data of this execution: {"execution time": 6500, "resource consumption.cpu_seconds": 12.5, "execution success flag": true}, and sends it to the server through an event bus. The server detects the event bus and obtains this message. Subsequently, the server determines, according to the configured mapping rules, that "execution time" corresponds to the "latency" capability dimension, "resource consumption.cpu_seconds" corresponds to the "cost" dimension, and "execution success flag" corresponds to the "reliability" dimension. Then, the server queries the preset capability tag library for the current quantified values ​​of Agent_E in these three dimensions, for example, {"latency": 6000, "cost": 11.0, "reliability": 0.96}. Then, the server adjusts these values: for "latency" and "cost," an exponential smoothing algorithm is used to incorporate the new data into the old values ​​with a certain weight (e.g., new latency = 0.9 * 6000 + 0.1 * 6500 = 6050); for "reliability," a slight upward adjustment is made for a successful result (e.g., new reliability = 0.96 + 0.001 = 0.961). Finally, the server obtains the updated quantified values ​​{"latency": 6050, "cost": 11.15, "reliability": 0.961} and writes them back to the capability tag library.

[0146] In the above embodiments, firstly, by acquiring performance data during actual execution, the capabilities of the intelligent agent are dynamically quantified and updated. Data such as execution time and resource consumption directly reflect the performance of the intelligent agent in a real-world task environment. Adjusting the quantified values ​​in the capability tags based on this data allows the tag values ​​to better reflect the agent's current actual capability level. Secondly, adjusting the quantified values ​​based on performance data continuously optimizes the data quality and timeliness of the capability tag library. By collecting key indicators such as execution time and resource consumption, the scoring criteria for each intelligent agent in relevant capability dimensions are continuously revised, ensuring that the capability tag library always reflects the latest performance status.

[0147] In one embodiment, the aforementioned "adjusting the quantization value of the target agent in the corresponding capability dimension based on performance data to obtain an updated quantization value" includes:

[0148] Based on the preset smoothing ratio, a first weighting coefficient corresponding to the quantized value and a second weighting coefficient corresponding to the performance data are determined respectively. Based on the first weighting coefficient and the second weighting coefficient, the historical quantized values ​​and performance data of the target agent are weighted and summed to obtain the updated quantized values.

[0149] The preset smoothing ratio is a core adjustment parameter pre-set to control the influence of old and new data during the update process. Specifically, it is a numerical parameter (usually denoted as α, where 0 ≤ α ≤ 1) that directly or indirectly determines the balance between the retention of historical data and the adoption of new observation data. For example, a smoothing ratio α = 0.1 means that in the update calculation, the weight of new data (performance data) is approximately 0.1, and the weight of historical data (quantified values) is approximately 0.9. This ratio can be configured differently based on the characteristics of different capability dimensions (such as stability requirements) or the maturity of the agent.

[0150] The first weighting coefficient is a multiplication factor applied to the historical quantification values ​​(i.e., the quantification values ​​before the update) of the target agent. Specifically, it represents the relative importance or credibility of historical performance data in forming the new estimate within the current update cycle. The larger the coefficient, the more the system trusts the historical data, and the more likely the update result is to remain stable. For example, if the first weighting coefficient is 0.9, then the historical quantification values ​​contribute 90% of the weight in the weighted sum.

[0151] The second weighting coefficient is a multiplication factor applied to the performance data acquired in this update. Specifically, it represents the relative importance or influence of the latest observation in forming the new estimate within the current update cycle. A larger coefficient indicates that the system attaches greater importance to the new data, and the update results are more sensitive to the latest changes. For example, if the second weighting coefficient is 0.1, then the performance data contributes 10% to the weighted sum.

[0152] In this embodiment, the server determines a first weighting coefficient corresponding to the quantized value and a second weighting coefficient corresponding to the performance data according to a preset smoothing ratio; based on the first weighting coefficient and the second weighting coefficient, the server performs a weighted summation of the historical quantized value and performance data of the target agent to obtain the updated quantized value.

[0153] For example, the server presets a smoothing ratio α of 0.2 for the "latency" dimension. After the target agent completes a subtask, the server obtains its performance data (execution time) for this execution as 180 milliseconds. Simultaneously, the server queries the capability tag library to find the agent's current historical quantization value (average latency), which is 200 milliseconds. Next, the server performs a determination operation: based on the exponential smoothing algorithm, it calculates the first weight coefficient = 1 - α = 0.8 and the second weight coefficient = α = 0.2. Then, the server performs a weighted summation: multiplying the historical quantization value 200 by the first weight coefficient 0.8 yields 160, multiplying the performance data 180 by the second weight coefficient 0.2 yields 36, and adding the two together gives 196. This 196 milliseconds is the updated quantization value, which the server uses to update the agent's "latency" dimension record in the capability tag library.

[0154] In the above embodiments, a first weighting coefficient corresponding to the quantized value and a second weighting coefficient corresponding to the performance data are determined according to a preset smoothing ratio, enabling a gradual adjustment of the agent's capability assessment. By reasonably configuring the weight ratio of new and old data, it is possible to respond promptly to the latest performance trend of the agent while effectively avoiding sudden changes in capability labels caused by a single abnormal data, thereby maintaining the stability of scheduling decisions. Based on the first and second weighting coefficients, the historical quantized values ​​and performance data of the target agent are weighted and summed to obtain the updated quantized values, which can reduce the computational complexity in the capability assessment process.

[0155] In one embodiment, the aforementioned "adjusting the quantization value of the target agent in the corresponding capability dimension based on performance data to obtain an updated quantization value" includes:

[0156] Obtain the performance data of the target agent within a preset time period or in the most recent N executions; determine the average value of the performance data; update the quantized value of the target agent in the corresponding capability dimension to the average value, and obtain the updated quantized value.

[0157] The preset time period is a predefined continuous time interval used to define the time range for filtering performance data. Specifically, it is a time window, such as "the past 24 hours," "this week," or "this month." When updating, the system only considers performance data generated by actions performed within this time window. For example, if configured to use "the past 7 days" as the preset time period, the server will only retrieve and process latency data generated by the agent's tasks within the last 7 days during updates.

[0158] The most recent N executions refer to a predefined threshold number used to define the range of execution counts for filtering performance data. Specifically, it specifies a window of recent execution counts, such as "last 10 times," "last 100 times," etc. When updating, the server only considers performance data generated within these most recent N executions. For example, if N=5, the server will retrieve performance data from the agent's 5 most recent completed tasks for calculation.

[0159] The average is a statistic calculated through the process described above, representing the central tendency of the selected performance data set. Specifically, it is the sum of all data values ​​divided by the number of data points, providing a single numerical value that summarizes the overall level of the data set. In the context of capability updates, the average is considered an estimate of the agent's typical recent performance in that dimension. For example, the 152.4 milliseconds calculated above is the average of the agent's recent latency performance.

[0160] In this embodiment, the server obtains the performance data of the target agent within a preset time period or in the most recent N executions; determines the average value of the performance data; and updates the quantified value of the target agent in the corresponding capability dimension to the average value, thus obtaining the updated quantified value. For example, the server is configured to update the "task success rate" dimension using the most recent N executions (N=10). After the target agent Agent_Checker completes a code review task, the server obtains the performance data (execution success indicator) of the agent's most recent 10 executions. Assume that the results of these 10 executions are: [success, success, failure, success, success, success, success, failure, success]. The server determines the average value of these performance data: first, "success" is recorded as 1, and "failure" is recorded as 0, and then the arithmetic mean (1+1+0+1+1+1+1+1+0+1) / 10=0.8 is calculated. This 0.8 represents the recent average success rate. Finally, the server performs an update operation, directly updating the "reliability" (corresponding to success rate) quantification value of Agent_Checker in the capability tag library from the original 0.85 to 0.80, thus obtaining the updated quantification value.

[0161] In the above embodiments, data sampling based on time windows or execution counts ensures the comprehensiveness and representativeness of capability assessment. This method no longer relies on the result of a single execution but comprehensively considers the agent's performance in recent consecutive tasks, thereby effectively smoothing out the impact of random fluctuations or abnormal data, and making capability labels more stably reflect the agent's true level. In addition, the average value calculation effectively reduces the interference caused by random factors in a single execution, while retaining the overall trend of the agent's performance within that time period, providing a more reliable and statistically significant capability basis for subsequent task scheduling.

[0162] In one embodiment, the above agent selection method further includes:

[0163] When the target task contains multiple subtasks with the same function, the candidate agents are divided into multiple candidate groups. For each candidate group, the variance of the quantified values ​​of each candidate agent in each capability dimension is determined. Based on the variance, the comprehensive capability coverage of each candidate group is determined. The larger the variance, the higher the capability coverage of the candidate group. The candidate agents in the candidate group with the highest comprehensive capability coverage are assigned to multiple subtasks with the same function.

[0164] Subtasks with the same function refer to multiple subtasks generated after task decomposition that require performing the same core operations or achieving the same type of goal. Specifically, they have the same or highly similar functional descriptions and may need to be executed in parallel to handle different data shards, serve different user requests, or obtain information from different sources. For example, a goal task "detect the status of three servers A, B, and C" may be decomposed into three subtasks with the same function: "detect the status of server A", "detect the status of server B", and "detect the status of server C".

[0165] Comprehensive capability coverage is a metric used to evaluate the overall capability of a candidate group. It quantifies the diversity and complementarity of the agents' performance across multiple capability dimensions. Specifically, it is a scalar value calculated by combining the variances of each agent within the group across all considered dimensions using a function (such as a weighted sum, product, or a more complex function). The claim defines a larger variance as indicating higher capability coverage. The underlying logic is that greater intra-group diversity implies the presence of agents specializing in a particular area (e.g., extremely low cost, extremely fast speed, extremely high reliability), which may give the group an advantage when facing uncertain future demands or when a broader capability spectrum is desired.

[0166] In this embodiment of the application, when the target task includes multiple subtasks with the same function, the server divides the candidate agents into multiple candidate groups; for each candidate group, the variance of the quantified values ​​of each candidate agent in each capability dimension is determined; based on the variance, the comprehensive capability coverage of each candidate group is determined; wherein, the larger the variance, the higher the capability coverage of the candidate group; and each candidate agent in the candidate group with the highest comprehensive capability coverage is assigned to multiple subtasks with the same function.

[0167] For example, the objective task "translate three documents in different languages" is broken down into three subtasks with the same function: "translate document A", "translate document B", and "translate document C". The system has five translation agents (T1 to T5) that meet the functional requirements. The server first divides the candidate agents into multiple candidate groups. Since three agents are required per group, the server calculates all possible combinations of three agents (e.g., {T1, T2, T3}, {T1, T2, T4}, etc.). For each candidate group, the server obtains the quantified values ​​of each agent within the group in three dimensions: "translation speed", "translation quality", and "cost". Next, for each capability dimension, the server determines the variance of the values ​​of the three agents within the group in that dimension. Then, the server calculates the overall capability coverage based on the variance: here, a simple summation is used, summing the variances of the three dimensions as the coverage. Assume the sum of the variances of candidate group {T1, T2, T3} in the three dimensions is 0.15, and the sum of the variances of candidate group {T1, T4, T5} is 0.23. By definition, the latter has higher overall capability coverage. Ultimately, the server assigns the three agents from the candidate group {T1, T4, T5} with the highest overall capability coverage to the three translation subtasks, completing the assignment.

[0168] In the above embodiments, candidate agents are divided into different candidate groups, and their overall capability coverage is quantified by calculating the variance of capability values ​​in each dimension within the group. This effectively identifies which agent combinations possess a broader capability distribution overall. A larger variance indicates a higher likelihood that the agents in that group have different strengths and complementary advantages in various capabilities, thus providing more comprehensive execution capability coverage when facing multiple subtasks with the same function but different potential needs. By assigning the group of agents with the most complementary capability distribution to multiple parallel subtasks, the differentiated advantages of each agent can be fully utilized, enabling similar types of tasks to achieve better execution performance in different dimensions. This not only helps shorten the overall completion time of parallel tasks but also reduces the risk of multiple subtasks being simultaneously blocked due to a weakness in one capability, thereby improving the success rate of task execution and the effectiveness of resource utilization.

[0169] In one embodiment, such as Figure 5 As shown, a task processing method is provided, which is applied to Figure 3 Taking the server in the example, the following steps are included:

[0170] S501, Obtain a structured execution plan for the target task.

[0171] The structured execution plan includes multiple subtasks of the target task, the logical order of execution between the subtasks, and the target agent corresponding to each subtask.

[0172] A structured execution plan is a standardized description that expresses how complex tasks are broken down, who performs them, and in what order, in a clear, machine-readable format. Specifically, it is a data object or configuration file whose structure clearly defines the blueprint for execution, typically including a list of task units, a dependency graph, resource allocation, and flow control instructions. For example, a plan document written using a workflow description language explicitly describes each step (subtask) and its executor (target agent).

[0173] The execution logical order refers to the sequence and dependency rules by which subtasks are started and run, as specified in a structured execution plan. Specifically, it originates from the dependencies determined during task decomposition (such as edges in a directed acyclic graph), defining which subtasks can be executed in parallel and which must wait for other subtasks to complete before starting. It ensures the correctness of the overall data flow and control flow of the task. For example, in a plan that "first fetch data, then clean data, and finally analyze data," "cleaning" must follow "fetching," and "analysis" must follow "cleaning"—this is the execution logical order.

[0174] In this embodiment, the server obtains a structured execution plan. For example, the obtained structured execution plan is submitted to an independent workflow engine. This plan not only includes tasks and dependencies, but also defines retry policies (e.g., a maximum of 3 retries), timeout settings, and failure handling logic (e.g., notifying the administrator after failure) for each subtask. The workflow engine persists the plan to a database and is responsible for maintaining the state of the entire process. When the engine needs to invoke a subtask, it does not directly invoke the agent, but instead publishes a "task execution message" to a task queue. The target agent of the subtask is bound as a worker node, consumes messages from the queue, and executes the task. After execution, the worker node sends a callback of the result (success or failure) to the workflow engine. The engine updates the task state and determines subsequent steps (e.g., executing the next task or triggering a retry) based on the result and the logic defined in the plan. This invocation method decouples scheduling and execution, providing stronger fault tolerance, state observability, and horizontal scalability, making it particularly suitable for long-running or complex task flows.

[0175] S502, according to the execution logic order, sequentially call the target intelligent agent corresponding to each subtask to execute the corresponding subtask, and obtain the subtask execution result.

[0176] The subtask execution result refers to the data or status information returned by the target agent after completing its assigned subtask, containing the output of that subtask. Specifically, it is the target agent's response to the call, which can be a structured data object, a piece of text, a file link, or a simple success / failure status code. For example, the "text summary" agent returns a summary text; the "data query" agent returns a JSON-formatted data list.

[0177] In this embodiment, the server sequentially calls the target agent corresponding to each subtask to execute the corresponding subtask according to the execution logic order, and obtains the subtask execution result.

[0178] For example, for a plan containing three sequential subtasks (data acquisition, data processing, and report generation), the execution engine first checks the conditions of the first subtask, "data acquisition," and after confirming its executable status, retrieves the target agent identifier and access address bound to it from the plan. Then, the execution engine constructs a call request containing specific acquisition parameters and sends it to the agent via a remote procedure call (RPC) protocol. Upon receiving the request, the agent executes the data acquisition job, stores the acquired raw data file in a specified location, and returns a subtask execution result to the execution engine, containing the file storage path and execution status. Upon receiving this result, the execution engine updates the status of that subtask in the plan to "completed" and passes its output as an input parameter to the next subtask. Next, the execution engine calls the agents corresponding to the "data processing" and "report generation" subtasks in the same manner, waiting for the previous subtask to complete and obtaining its output as input for each call, until all subtasks are executed sequentially, thus obtaining the execution result of each subtask.

[0179] S503 generates the task processing result of the target task based on the execution result of the subtask.

[0180] In this embodiment, the server can directly use the subtask execution result of the last target agent as the task processing result of the target task. For example, for a target task of generating a market analysis report, its structured execution plan can include multiple sequentially executed subtasks, such as data collection, trend analysis, and report writing. Report writing is the last subtask, executed by agent R. After the server sequentially calls and completes the preceding subtasks, it finally calls R and provides it with the structured data generated by the trend analysis subtask. After R completes its execution, it returns a complete PDF-format analysis report as its subtask execution result.

[0181] In another embodiment, the server aggregates and reprocesses the results of multiple subtasks to generate a final result. For example, the objective is to create a quarterly business overview dashboard containing sales data, user feedback, and competitor activity. This objective is broken down into three parallel subtasks: Subtask A (sales data statistics, executed by agent D), Subtask B (user sentiment analysis, executed by agent S), and Subtask C (competitor information retrieval, executed by agent C). After each subtask is completed, it returns the following results: Subtask A is sales metrics in JSON format, Subtask B is sentiment scores and key opinion summaries, and Subtask C is a list of competitor activity. After collecting the results of all parallel subtasks, the server does not directly return any of them. Instead, it calls a result synthesizer component. This component merges the three results (A, B, and C) according to a predefined dashboard template: converting sales metrics into chart data, associating sentiment scores with competitor activity, and integrating all text summaries to ultimately generate an interactive HTML webpage or a multi-page PowerPoint presentation as the final task processing result.

[0182] In the above embodiments, by acquiring and executing a structured execution of each subtask using a pre-bound optimal target agent, the agent selection and task processing flow are integrated, achieving a closed loop from agent selection to task processing. This method ensures that each subtask is executed by the target agent that best matches the user's preferences, thereby significantly improving the overall processing efficiency and result quality of complex tasks. Furthermore, by sequentially calling the target agents corresponding to each subtask according to the execution logic order, delays and errors that may be introduced by manual intervention are avoided.

[0183] In one embodiment, the above task processing method further includes:

[0184] For each subtask in the target task, during the process of calling the target agent to execute the subtask, the execution status of the subtask is detected; if the execution status indicates that the subtask has failed or timed out, the target agent is reselected from the set of candidate agents preset for the subtask; and the reselected target agent is used to execute the subtask.

[0185] Execution status refers to the server's detection and feedback information on the task's running status during the execution of a subtask by the target intelligent agent. Specifically, it includes various status indicators such as whether the task started normally, is currently running, has been completed, failed due to an error, or has exceeded the scheduled time (timeout). Detecting execution status is a continuous or periodic process aimed at timely identifying anomalies.

[0186] The pre-defined set of alternative agents refers to a list of available agents besides the primary target agent, pre-configured for each subtask. Specifically, this set includes identifiers of agents with the same or similar functions that can serve as backups. These agents may not be selected initially due to slightly lower scores, but can be quickly switched to if the primary agent fails.

[0187] In this embodiment of the application, for each subtask in the target task, the server detects the execution status of the subtask during the process of calling the target agent to execute the subtask; if the execution status indicates that the subtask has failed or timed out, the server reselects the target agent from the preset set of candidate agents for the subtask; and uses the reselected target agent to execute the subtask.

[0188] For example, when a server executes a "data cleaning" subtask, it sets a timeout threshold, such as 30 seconds, for this call. After sending a request to the preferred target agent (DA), the server starts a timer and continuously monitors its execution status. If DA returns a success or explicit failure result within 30 seconds, the server updates the subtask status based on that result. If no response is received after 30 seconds, the server determines that the subtask has timed out and marks its execution status as "timeout". Subsequently, the server retrieves its predefined set of candidate agents, such as [DB, DC], based on the subtask's predefined configuration. The server uses the set order as a reselection strategy, directly selecting DB, which is ranked first, as the new target agent. Then, the server executes the subtask using the reselected target agent, i.e., sending the same cleaning request to DB as before and restarting the monitoring.

[0189] In the above embodiments, by dynamically detecting the subtask status during execution and intelligently triggering a reselection and retry mechanism when failure or timeout is detected, the robustness and completion rate of the task execution system are significantly enhanced. This method can detect execution anomalies in real time and quickly select a suitable agent from a preset candidate set to take over, effectively avoiding interruption or delay of the entire task process due to temporary failure or performance bottleneck of a single agent.

[0190] In one embodiment, the aforementioned "reselecting a target agent from the pre-defined set of candidate agents for the subtask" includes:

[0191] Obtain the preference information used when selecting a target agent for a subtask; determine the comprehensive score of each candidate agent in the candidate agent set based on the preference information; and select a new target agent from the candidate agent set based on the comprehensive score.

[0192] In this embodiment, the server obtains the preference information used to select a target agent for a subtask; then, based on the preference information, it determines the comprehensive score of each candidate agent in the candidate agent set; finally, based on the comprehensive score, it selects a new target agent from the candidate agent set.

[0193] For example, when a "graphics rendering" subtask needs to be retried due to a failure of the preferred agent R, the server first obtains the preference information used to select the target agent for the subtask. This preference information might be {"optimization goal": "rendering speed priority"} specified by the user when submitting the task, which the server has parsed into a weight vector {"speed": 0.8,"quality": 0.2}. Next, the server obtains a pre-set set of candidate agents for the subtask, such as [B, C, D]. Then, based on the preference information, the server determines the comprehensive score of each candidate agent in the set: it queries the latest capability labels of these candidate agents in the "rendering speed" and "output quality" dimensions, and uses the same normalization and weighted summation algorithm to calculate a new score for each agent based on the aforementioned weight vector. Assume that the scores for B, C, and D are 0.72, 0.85, and 0.68, respectively. Finally, based on the comprehensive score, the server selects a new target agent from the set of candidate agents, i.e., choosing the highest-scoring agent C to replace the failed task.

[0194] In the above embodiments, by re-acquiring user preference information during fault recovery and using this information to comprehensively score and select the best candidate agent, a high degree of consistency between the fault-tolerance process and the user's original intent is achieved. This method ensures that even if the executor needs to be changed, the server can still select the agent that best meets the current needs from the candidate set. This avoids the performance degradation that may result from simple rotation or random selection, and ensures that the task execution path after retry continues the optimization direction expected by the user to the greatest extent.

[0195] In one embodiment, the above task processing method further includes:

[0196] Based on the execution results of each subtask, update the quantification value of the target agent in the capability tag library for each subtask.

[0197] In this embodiment of the application, the server updates the quantification value of the target agent of each subtask in the capability tag library according to the execution result of each subtask.

[0198] In a specific embodiment, for the image processing subtask, the actual processing time is extracted as 320 milliseconds, peak memory usage as 512MB, and execution status as successful. Next, the server maps these performance data to specific dimensions in the capability tag library according to predefined mapping rules, such as mapping the actual processing time to the latency dimension, the peak memory usage to the resource consumption dimension, and the execution status to the reliability dimension. Then, the server reads the current quantized values ​​of the target agent in these dimensions from the capability tag library, for example, the current latency value is 350 milliseconds. Finally, the server applies a preset update algorithm to fuse the observed 320 milliseconds with the historical value of 350 milliseconds, calculates a new quantized value (e.g., 340 milliseconds), and writes this new value along with a new update timestamp back to the capability tag library.

[0199] In the above embodiments, by using the actual execution results of subtasks as feedback data to dynamically update the quantified values ​​of the relevant agents in the capability tag library, the capability evaluation of the agents no longer relies on static data, but is based on their real, historical performance records. This data-driven dynamic update mechanism ensures that the capability information relied upon for subsequent task scheduling decisions is always close to reality and reflects the latest status.

[0200] In the digital transformation process of large enterprises, there are often a large number of standardized, process-oriented tasks involving multiple system operations, such as daily data entry, periodic report generation, and automated system inspections. These tasks are usually handled by automated processes with different professional capabilities. A unified task scheduling platform built based on an agent selection method can significantly improve the intelligence level and resource utilization efficiency of such tasks.

[0201] Employees can submit complex tasks through the platform interface, such as "generate last week's sales analysis report and send it to management." Employees can also add specific preferences, such as "prefer using the local database" or "the report must be completed within 30 minutes." After the task is received, the planning component will automatically break it down into multiple sub-tasks, including "extracting sales data from the customer management system," "verifying accounts receivable from the financial system," "conducting sales trend analysis," "generating a presentation-format report," and "sending the report via internal communication tools."

[0202] For each subtask, the server queries a pre-established capability tag library. This library records the capability metrics of all registered digital employees, such as "processing speed," "supported data source types," "output format compatibility," and "task success rate." The server combines the specific requirements of the task with the user's preferences to comprehensively score and select the best candidate digital employees, ultimately forming a detailed plan that binds the optimal execution object to each task.

[0203] According to the plan, the task scheduling and execution engine systematically calls upon the corresponding digital employees to execute the tasks step by step. For example, the "Sales Data Extraction Specialist" first obtains the data, and its output is then verified by the "Financial Verification Assistant." Subsequently, the analysis, report generation, and submission processes are executed sequentially. After each sub-task is completed, the engine collects relevant process data, including execution time, data volume processed, and success status, and sends it to the dynamic quantification module for analysis. This module updates the corresponding digital employee's indicator values ​​in the capability tag library based on the actual execution performance, such as revising the "Average Processing Time" for the "Sales Data Extraction Specialist" when handling a certain data volume.

[0204] After all subtasks are completed, the server will integrate the final results and return them to the employee who submitted the task through the user interface.

[0205] In large-scale open-world games or metaverse platforms, there is a massive demand for content generation (such as quest storylines, NPC dialogues, and scene descriptions) and ecosystem operation (such as player behavior analysis, anomaly detection, and community interaction). Traditional single AI models struggle to cover all scenarios, and player preferences are constantly changing. Therefore, the aforementioned agent selection method can be extended to build a centralized platform capable of dynamically coordinating multiple professional AI creation and operation agents.

[0206] Game designers or system events trigger a high-level objective through the user interface, such as "Generate a chain of 5 interconnected adventure quests for the new area 'Twilight Grove,' targeting intermediate casual players with a fantasy and puzzle-solving style." Upon receiving this creative task, the planning component performs deep semantic understanding and task decomposition, planning it into a series of creative sub-tasks, including "world setting," "main storyline outline generation," "detailed descriptions of the 5 sub-quest levels," "NPC character and dialogue creation," "task reward balance design," and "final multimodal integration."

[0207] The platform boasts a pool of Agent execution units, comprising a variety of creative Agents with distinct characteristics, such as "epic fantasy writer," "mystery and puzzle structure expert," "dialogue generation (lighthearted / humorous / serious / profound) model," "game numerical balance AI," and "text-to-image model interface." The capability tag library not only records these Agents' basic abilities (such as "writing style" and "preferred genre"), but also accumulates in-depth preference tags based on historical data, including "popularity among intermediate players," "plot coherence rating," and "fittingness with the 'fantasy' style."

[0208] Based on the decomposed sub-tasks and preferences such as "intermediate casual players" and "fantasy puzzle," the planning component selects the most suitable Agent from the pool for each creative stage, generating a creative execution plan bound to the optimal Agent. The scheduling and execution engine schedules these Agents in a "writing relay" manner: first, the "epic fantasy style writer" generates the world view and main storyline, and its output is passed to the "suspense puzzle structure expert" to break it down into levels. Then, a specific "dialogue generation model" breathes life into the NPCs of each level, and finally, the "text-to-image model" generates concept sketches for key scenes.

[0209] Throughout the collaborative creation process, execution data (such as generation time for each stage, historical player feedback data, and consistency assessment of content output across stages) is collected in real time. The dynamic quantification module acts as the "Chief Experience Officer," analyzing this data to not only update performance tags but, more importantly, to update ecosystem tags for each Agent, such as "style-player preference matching" and "collaborative creation compatibility." For example, the module might discover that a "humorous dialogue model" paired with an "epic fantasy writer" receives significantly higher player approval ratings than when paired with a "serious and profound model," thus reinforcing the "synergistic benefit" relationship between these two Agents in the tag library.

[0210] Ultimately, the generated high-quality, consistent quest chain content that aligns with the target player's preferences is integrated and output for game updates. This extended application not only automates content production but also, through continuous feedback and learning, enables the entire multi-agent system to dynamically adapt to changes in the player community's tastes, forming an intelligent game content ecosystem that becomes increasingly adept at understanding players and increasingly tailored to their needs through continuous creation.

[0211] In one embodiment, such as Figure 6 As shown, the above method also includes:

[0212] S1, obtain the target task and the preference information for the target task.

[0213] S2 performs semantic parsing and step serialization on the target task to obtain a directed acyclic graph (DAG). The DAG consists of multiple task nodes, and each task node corresponds to a subtask.

[0214] S3: Obtain the capability tags of candidate agents from the preset capability tag library.

[0215] S4. Based on the weight vector in the preference information, for the inverse indicator dimension in the capability dimension, perform reverse normalization on the quantified value of the inverse indicator dimension to obtain the normalized score of the inverse indicator dimension; for the positive indicator dimension in the capability dimension, perform linear normalization on the quantified value of the inverse indicator dimension to obtain the normalized score of the positive indicator dimension.

[0216] S5, based on the weights of the corresponding ability dimensions in the weight vector, performs a weighted summation of the normalized scores to obtain the comprehensive score.

[0217] S6. Based on the comprehensive score, select the target agent from the candidate agents to perform the sub-task.

[0218] S7 binds the target agent to the subtask corresponding to the task node in the directed acyclic graph, and executes the bound subtask based on the target agent.

[0219] S8: After the target agent executes the subtask, obtain the performance data of the subtask.

[0220] S9, according to the preset smoothing ratio, determine the first weighting coefficient corresponding to the quantized value and the second weighting coefficient corresponding to the performance data respectively; based on the first weighting coefficient and the second weighting coefficient, perform weighted summation on the historical quantized values ​​and performance data of the target agent to obtain the updated quantized value; or, obtain the performance data of the target agent in the preset time period or in the most recent N executions; determine the average value of the performance data; update the quantized value of the target agent in the corresponding capability dimension to the average value to obtain the updated quantized value.

[0221] It should be noted that when the target task contains multiple subtasks with the same function, the candidate agents are divided into multiple candidate groups; for each candidate group, the variance of the quantified values ​​of each candidate agent in each capability dimension is determined; based on the variance, the comprehensive capability coverage of each candidate group is determined; where, the larger the variance, the higher the capability coverage of the candidate group; and the candidate agents in the candidate group with the highest comprehensive capability coverage are assigned to multiple subtasks with the same function.

[0222] In one embodiment, Figure 7 A flowchart of the process for selecting a method for an agent, as shown below. Figure 7 As shown, firstly, the server receives the target task and preference information submitted by the user, and decomposes and plans the task; secondly, it queries the capability tag library for each sub-task, scores and selects candidate intelligent agents based on user preferences, generates an execution plan that binds the optimal intelligent agent, and schedules its execution; if the task is not fully completed, it collects data such as execution time, token count, and success rate of each intelligent agent, and inputs them into the dynamic quantification module to update the capability tag library, thereby optimizing the subsequent matching effect; if the task is fully completed, it returns the final result to the user.

[0223] In one embodiment, Figure 8 Select the architecture diagram corresponding to the method for the agent, such as Figure 8As shown, the system mainly comprises a user interface layer, a core system layer, an agent execution unit layer, and a capability tag management module. After the user submits a task and preferences through the user interface, the planning component in the server decomposes and plans the task, and queries the capability tag library to match the optimal agent. Subsequently, the scheduling and execution engine distributes the task to the corresponding Agent execution unit in the agent execution unit pool for execution. Throughout the process, the server collects execution process data and sends it to the dynamic quantification module. This module updates the tag values ​​in the capability tag library based on actual execution metrics, thereby dynamically optimizing the agent capability matching. Finally, the server returns the execution result to the user interface via the core system.

[0224] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0225] Based on the same inventive concept, this application also provides an agent selection device for implementing the agent selection method described above. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more agent selection device embodiments provided below can be found in the limitations of the agent selection method described above, and will not be repeated here.

[0226] In one embodiment, such as Figure 9 As shown, an intelligent agent selection device is provided, including: an information acquisition module 801, a processing module 802, a tag acquisition module 803, a calculation module 804, and a selection module 805, wherein:

[0227] The information acquisition module 801 is used to acquire the target task and the preference information for the target task;

[0228] Processing module 802 is used to decompose the target task to obtain subtasks of the target task;

[0229] The tag acquisition module 803 is used to acquire the capability tags of candidate agents; the capability tags include quantified values ​​of multiple capability dimensions;

[0230] The calculation module 804 is used to perform weighted calculations on the quantified values ​​of each capability dimension of the candidate agent based on the weight vector in the preference information, so as to obtain the comprehensive score of the candidate agent.

[0231] The selection module 805 is used to select the target agent for performing the sub-task from the candidate agents based on the comprehensive score.

[0232] In one embodiment, the weight vector in the preference information includes the weights of each ability dimension. Based on this, the calculation module 804 is specifically used to normalize the quantified values ​​of each ability dimension to obtain the normalized score of each ability dimension; and to perform weighted summation on the normalized scores based on the weights of the corresponding ability dimensions in the weight vector to obtain a comprehensive score.

[0233] In one embodiment, the calculation module 804 is specifically used to perform reverse normalization on the quantified values ​​of the reverse indicator dimension in the capability dimension to obtain a normalized score for the reverse indicator dimension; and to perform linear normalization on the quantified values ​​of the reverse indicator dimension in the capability dimension to obtain a normalized score for the positive indicator dimension; wherein, the reverse indicator dimension refers to a capability dimension in which a smaller value indicates better performance; the positive indicator dimension refers to a capability dimension in which a larger value indicates better performance; the linear normalization is configured to make the quantified values ​​and the normalized scores positively correlated; and the reverse normalization is configured to make the quantified values ​​and the normalized scores negatively correlated.

[0234] In one embodiment, the processing module 802 is specifically used to perform semantic parsing and step serialization processing on the target task to obtain a directed acyclic graph; wherein the directed acyclic graph consists of multiple task nodes, and each task node corresponds to a subtask.

[0235] In one embodiment, the agent selection device is further configured to bind the target agent to the subtask corresponding to the task node in the directed acyclic graph, and execute the bound subtask based on the target agent.

[0236] In one embodiment, the tag acquisition module 803 is specifically used to acquire the capability tags of candidate agents from a preset capability tag library; wherein, the capability tag includes a quantized value and a latest update timestamp; the quantized value and the latest update timestamp are stored in key-value pair format.

[0237] In one embodiment, the aforementioned agent selection device is further configured to acquire performance data of the subtask after the target agent executes the subtask; the performance data includes at least one of execution time, resource consumption, and execution success identifier; and adjust the quantitative value of the target agent in the corresponding capability dimension according to the performance data to obtain the updated quantitative value.

[0238] In one embodiment, the agent selection device is further configured to determine a first weighting coefficient corresponding to the quantized value and a second weighting coefficient corresponding to the performance data according to a preset smoothing ratio; and to perform a weighted summation of the historical quantized value and performance data of the target agent based on the first weighting coefficient and the second weighting coefficient to obtain an updated quantized value.

[0239] In one embodiment, the above-mentioned agent selection device is further configured to acquire the performance data of the target agent within a preset time period or in the most recent N executions; determine the average value of the performance data; update the quantized value of the target agent in the corresponding capability dimension to the average value, and obtain the updated quantized value.

[0240] In one embodiment, the agent selection device is further configured to divide candidate agents into multiple candidate groups when the target task includes multiple sub-tasks with the same function; for each candidate group, determine the variance of the quantified values ​​of each candidate agent in each capability dimension; determine the comprehensive capability coverage of each candidate group based on the variance; wherein, the larger the variance, the higher the capability coverage of the candidate group; and assign each candidate agent in the candidate group with the highest comprehensive capability coverage to multiple sub-tasks with the same function.

[0241] Each module in the aforementioned intelligent agent selection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0242] In one embodiment, such as Figure 10 As shown, a task processing device is provided, including: an acquisition module 901, a calling module 902, and a generation module 903, wherein:

[0243] The acquisition module 901 is used to acquire a structured execution plan for the target task; wherein, the structured execution plan includes multiple subtasks of the target task, the execution logical order between the subtasks, and the target intelligent agent corresponding to each subtask;

[0244] The calling module 902 is used to sequentially call the target intelligent agent corresponding to each subtask to execute the corresponding subtask according to the execution logic order, and obtain the subtask execution result;

[0245] The generation module 903 is used to generate the task processing result of the target task based on the execution result of the subtask.

[0246] In one embodiment, the task processing device is further configured to, for each subtask in the target task, detect the execution status of the subtask during the process of calling the target agent to execute the subtask; if the execution status indicates that the subtask has failed or timed out, reselect the target agent from the preset set of candidate agents for the subtask; and use the reselected target agent to execute the subtask.

[0247] In one embodiment, the task processing apparatus is further configured to acquire preference information used when selecting a target agent for a subtask; determine the comprehensive score of each candidate agent in the candidate agent set based on the preference information; and select a new target agent from the candidate agent set based on the comprehensive score.

[0248] In one embodiment, the task processing device is further configured to update the quantization value of the target agent of each subtask in the capability tag library based on the execution result of each subtask.

[0249] Each module in the aforementioned task processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can invoke and execute the operations corresponding to each module.

[0250] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 11 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores relevant data during the agent selection process. The I / O interfaces are used for information exchange between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements an agent selection method.

[0251] Those skilled in the art will understand that Figure 11The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0252] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0253] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0254] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0255] It should 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 analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0256] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic units, data processing logic units, etc., and are not limited to these.

[0257] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0258] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for selecting an intelligent agent, characterized in that, The method includes: Obtain the target task and the preference information for the target task; The target task is decomposed to obtain subtasks of the target task; Obtain the capability tags of the candidate intelligent agent; the capability tags include quantified values ​​of multiple capability dimensions; Based on the weight vector in the preference information, the quantified values ​​of each capability dimension of the candidate agent are weighted and calculated to obtain the comprehensive score of the candidate agent; Based on the comprehensive score, a target agent for performing the sub-task is selected from the candidate agents.

2. The method according to claim 1, characterized in that, The weight vector in the preference information includes the weights of each of the capability dimensions; the step of weighting the quantified values ​​of each capability dimension of the candidate agent according to the weight vector in the preference information to obtain the comprehensive score of the candidate agent includes: The quantified values ​​of each capability dimension are normalized to obtain the normalized score of each capability dimension. Based on the weights of the corresponding ability dimensions in the weight vector, the normalized scores are weighted and summed to obtain the comprehensive score.

3. The method according to claim 2, characterized in that, The normalization process for the quantified values ​​of each capability dimension to obtain a normalized score for each capability dimension includes: For the inverse indicator dimension in the capability dimension, the quantified value of the inverse indicator dimension is reversed and normalized to obtain the normalized score of the inverse indicator dimension. For the positive indicator dimension in the capability dimension, the quantified values ​​of the negative indicator dimension are linearly normalized to obtain the normalized score of the positive indicator dimension. Wherein, the inverse index dimension refers to the capability dimension in which a smaller value indicates better performance; the positive index dimension refers to the capability dimension in which a larger value indicates better performance; the linear normalization process is configured to make the quantized value and the normalized score positively correlated; and the inverse normalization process is configured to make the quantized value and the normalized score negatively correlated.

4. The method according to claim 1, characterized in that, The process of decomposing the target task to obtain its subtasks includes: The target task is subjected to semantic parsing and step serialization to obtain a directed acyclic graph; The directed acyclic graph consists of multiple task nodes, and each task node corresponds to a subtask.

5. The method according to claim 4, characterized in that, After selecting the target agent for performing the sub-task from the candidate agents based on the comprehensive score, the process further includes: The target agent is bound to the subtask corresponding to the task node in the directed acyclic graph, and the bound subtask is executed based on the target agent.

6. The method according to claim 1, characterized in that, The capability tags for acquiring candidate agents include: Obtain the capability tags of the candidate agents from a preset capability tag library; The capability tag includes a quantified value and a latest update timestamp; the quantified value and the latest update timestamp are stored in key-value pairs.

7. The method according to claim 1, characterized in that, The method further includes: After the target agent executes the subtask, performance data of the subtask is obtained; the performance data includes at least one of execution time, resource consumption, and execution success indicator. Based on the performance data, the quantization values ​​of the target agent in the corresponding capability dimension are adjusted to obtain the updated quantization values.

8. The method according to claim 7, characterized in that, The step of adjusting the quantization value of the target intelligent agent in the corresponding capability dimension based on the performance data to obtain the updated quantization value includes: Based on the preset smoothing ratio, a first weighting coefficient corresponding to the quantized value and a second weighting coefficient corresponding to the performance data are determined respectively. Based on the first weighting coefficient and the second weighting coefficient, the historical quantization values ​​of the target intelligent agent and the performance data are weighted and summed to obtain the updated quantization values.

9. The method according to claim 7, characterized in that, The step of adjusting the quantization value of the target intelligent agent in the corresponding capability dimension based on the performance data to obtain the updated quantization value includes: Obtain the performance data of the target intelligent agent within a preset time period or in the most recent N executions; Determine the average value of the performance data; The quantized value of the target agent in the corresponding capability dimension is updated to the average value to obtain the updated quantized value.

10. The method according to claim 1, characterized in that, The method further includes: When the target task contains multiple subtasks with the same function, the candidate agents are divided into multiple candidate groups; For each candidate group, determine the variance of the quantified values ​​of each candidate agent in each capability dimension within the candidate group; Based on the variance, the overall capability coverage of each candidate group is determined; wherein, the larger the variance, the higher the capability coverage of the candidate group. Each candidate agent in the candidate group with the highest comprehensive capability coverage is assigned to one of the multiple subtasks with the same function.

11. A task processing method, characterized in that, The method includes: Obtain a structured execution plan for a target task; wherein the structured execution plan includes multiple subtasks of the target task, the execution logical order between each subtask, and a target intelligent agent corresponding to each subtask; the target intelligent agent is determined based on the intelligent agent selection method according to any one of claims 1 to 10; According to the execution logic order, the target intelligent agent corresponding to each subtask is called sequentially to execute the corresponding subtask, and the subtask execution result is obtained; The task processing result of the target task is generated based on the execution result of the sub-task.

12. The method according to claim 11, characterized in that, The method further includes: For each subtask in the target task, during the process of calling the target agent to execute the subtask, the execution status of the subtask is detected; If the execution status indicates that the subtask has failed or timed out, a new target agent is selected from the preset set of candidate agents for the subtask. The subtask is performed using the newly selected target agent.

13. The method according to claim 12, characterized in that, The step of reselecting a target agent from the preset set of candidate agents for the subtask includes: Obtain the preference information used when selecting the target agent for the subtask; Based on the preference information, determine the comprehensive score of each candidate agent in the candidate agent set; Based on the comprehensive score, a new target agent is selected from the set of candidate agents.

14. The method according to claim 11, characterized in that, The method further includes: Based on the execution results of each subtask, update the quantification value of the target agent of each subtask in the capability tag library.

15. A smart agent selection device, characterized in that, The device includes: The information acquisition module is used to acquire the target task and the preference information for the target task; The processing module is used to decompose the target task to obtain the subtasks of the target task; The tag acquisition module is used to acquire the capability tags of candidate agents; the capability tags include quantified values ​​of multiple capability dimensions; The calculation module is used to perform weighted calculation on the quantified values ​​of each capability dimension of the candidate agent according to the weight vector in the preference information, so as to obtain the comprehensive score of the candidate agent; The selection module is used to select a target agent from the candidate agents to perform the sub-task based on the comprehensive score.

16. A task processing device, characterized in that, The device includes: An acquisition module is used to acquire a structured execution plan for a target task; wherein the structured execution plan includes multiple subtasks of the target task, the execution logical order between the subtasks, and a target intelligent agent corresponding to each subtask; the target intelligent agent is determined based on the intelligent agent selection method according to any one of claims 1 to 11; The calling module is used to sequentially call the target intelligent agent corresponding to each subtask to execute the corresponding subtask according to the execution logic order, and obtain the subtask execution result; The generation module is used to generate the task processing result of the target task based on the execution result of the subtask.

17. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 14.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 14.

Images