Intelligent agent task scheduling planning method

Abstract

The invention discloses an agent task scheduling planning method, and relates to the technical field of agent scheduling. The method comprises the steps of analyzing a task instruction to generate atomic tasks capable of being independently executed, constructing a subtask dependency graph, and defining association constraints between the tasks; determining the real-time resource occupancy state of the intelligent agent to obtain a resource state tensor, completing resource-task association anchoring and dependency priority ranking in combination with the sub-task dependency graph, and generating a task priority sequence with resource constraint; performing dynamic capability matching and predictive load balancing calculation on the sequence through a task-agent adaptation model, and determining a target execution agent of each atomic task; and based on the target execution agent and the subtask dependency graph, performing time sequence scheduling arrangement and conflict resolution, and generating a collaborative execution scheme. The method improves the reasonability and efficiency of agent task scheduling, reduces resource conflicts and execution timeout risks, and is suitable for agent cluster collaborative scheduling in a complex scene.

Description

Technical Field

[0001] This application relates to the field of intelligent agent scheduling technology, and more specifically, to an intelligent agent task scheduling and planning method. Background Technology

[0002] Against the backdrop of rapid development in artificial intelligence and distributed computing technologies, intelligent agent systems are widely used in various fields such as cloud computing, industrial automation, and autonomous driving, undertaking the execution and collaborative work of complex and multifaceted tasks. These multifaceted tasks typically contain multiple interrelated subtasks and have strict requirements on execution timing, resource allocation, and reliability. Therefore, efficient task scheduling and planning have become the core of ensuring the stable operation of intelligent agent systems.

[0003] In existing technologies, a typical agent task scheduling scheme involves simply breaking down task instructions into independent task units, and then allocating and orchestrating tasks based on static resource states. This scheme first performs basic parsing of task instructions, extracting core task elements and breaking them down into executable units; then it collects real-time resource data from the agent to establish a matching relationship between resources and tasks; next, it allocates execution entities based on task priority and agent capabilities; finally, it generates a scheduling scheme and executes it through temporal sequencing and conflict detection.

[0004] However, this existing solution has obvious technical flaws in practical applications: it only performs simple task decomposition and preliminary dependency modeling, without effectively verifying the closure and integrity of the dependencies, which easily leads to circular dependencies causing task deadlocks, and it is difficult to detect implicit dependency conflicts; resource allocation is based on static matching of real-time status, which cannot predict future peak resource demand, resulting in high-priority tasks experiencing execution timeouts due to resource contention, and low resource utilization; and the scheduling scheme lacks a dynamic adjustment mechanism after generation, which cannot respond quickly to task execution anomalies and requires manual intervention to replan, seriously affecting task completion efficiency and system stability. Summary of the Invention

[0005] To address the aforementioned technical problems, this application provides an agent task scheduling and planning method to at least alleviate these problems.

[0006] The technical solutions provided in this application are as follows: A method for intelligent agent task scheduling and planning includes: Step 1, parsing task instructions to generate independently executable atomic tasks to construct a subtask dependency graph; Step 2, determining the real-time resource occupancy state of the intelligent agent to obtain an intelligent agent resource state tensor, and performing resource-task association anchoring and dependency priority sorting based on the intelligent agent resource state tensor and the subtask dependency graph to generate a task priority sequence with resource constraints; Step 3, using a task-intelligent agent adaptation model, performing dynamic capability matching and predictive load balancing calculations on the task priority sequence with resource constraints to determine the target executing intelligent agent for each atomic task; Step 4, performing time-series scheduling orchestration and conflict resolution on the target executing intelligent agent and the subtask dependency graph for each atomic task to generate an intelligent agent task scheduling collaborative execution scheme.

[0007] The intelligent agent task scheduling and planning method provided in this application addresses the technical shortcomings of existing technologies, such as missing dependency verification, static resource allocation, and insufficient scheduling adaptability. Through multi-stage collaborative design, it achieves improved efficiency and robustness in task scheduling. The specific technical benefits are as follows: In the task parsing and dependency modeling stages, this method generates independently executable atomic tasks and constructs a subtask dependency graph through a complete process of semantic deconstruction, granular splitting, and dependency modeling. Compared to the simple task decomposition methods of existing technologies, it systematically sorts out the logical connections between atomic tasks by extracting execution preconditions, matching dependency pairs, and graph-based modeling. This clearly presents the sequential constraints of task execution, providing accurate dependency basis for subsequent scheduling and orchestration, and effectively reducing execution chaos caused by ambiguous dependency relationships. Simultaneously, through refined processing such as word segmentation and syntactic parsing, and redundancy removal, it ensures that no core elements of the task are omitted, resulting in better independence and integrity of atomic tasks and laying the foundation for a rational scheduling scheme.

[0008] In the resource perception and priority ranking stage, this method innovatively tensors the resource state of the agent. Through multi-dimensional data collection and normalization processing, it achieves a comprehensive and accurate representation of the resource state, including computing power, storage, and communication links. Compared to traditional single-dimensional resource monitoring, this method better reflects the actual carrying capacity of the agent. Based on the association and anchoring between the resource state tensor and the subtask dependency graph, it can accurately select resource-suitable task sets, avoiding execution failures or inefficiencies caused by mismatches between tasks and agent resources. Simultaneously, by combining dependency hierarchy partitioning for priority ranking, the task execution order satisfies both dependency constraints and adapts to the resource supply status. The generated task priority sequence with resource constraints is more practical and effectively alleviates scheduling conflicts caused by resource contention.

[0009] In the task-agent adaptation phase, an adaptation model integrating a dynamic capability evolution network, a load prediction feedback loop, and a task type adaptation rule base achieves an organic combination of dynamic capability matching and predictive load balancing. The dynamic capability evolution network, based on the fusion analysis of historical data and real-time status, can capture the evolutionary trend of agent capabilities, adapting better to dynamic changes in agent performance compared to static capability matching. The load prediction feedback loop predicts future load through a time-series prediction model, proactively avoiding overload risks and solving the resource shortage problem caused by "post-event response" in traditional scheduling. The task type adaptation rule base matches agent capability dimensions for different types of tasks, improving matching accuracy. This integrated adaptation model ensures that the selection of the target executing agent not only meets task type requirements but also considers the agent's real-time capabilities and future load, achieving optimal task allocation and improving resource utilization and task execution efficiency.

[0010] In the timing orchestration and conflict resolution stages, the initial timing orchestration based on the subtask dependency graph and the target execution agent ensures the consistency of task execution order and dependency constraints. Through time period overlap detection and logical conflict detection, conflict items in the scheduling scheme are comprehensively identified, which is more comprehensive and accurate than the single-dimensional conflict detection in traditional scheduling. Differentiated resolution strategies for different conflict items resolve resource competition conflicts through time period reallocation and logical execution conflicts through dependency relationship timing calibration. Finally, integrity verification ensures that the scheduling scheme is complete without omissions. The generated collaborative execution scheme is more stable and reliable, effectively reducing interruptions and adjustments during the scheduling process and improving the continuity of task completion.

[0011] Compared to traditional intelligent agent task scheduling schemes, the method in this application achieves closed-loop optimization from task parsing, resource awareness, task allocation to scheduling orchestration through meticulous design throughout the entire process. In dependency handling, it shifts from fuzzy to clear and structured dependency management; in resource utilization, it moves from static matching to dynamic adaptation and predictive planning; and in conflict resolution, it shifts from passive response to proactive prevention and precise resolution. These improvements significantly enhance the rationality, adaptability, and reliability of the scheduling scheme, effectively reducing task execution timeout and failure rates, improving resource utilization and task completion efficiency. It is particularly suitable for scheduling scenarios involving complex and composite tasks, providing strong support for the stable and efficient operation of intelligent agent systems. Attached Figure Description

[0012] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0013] Figure 1 This is a flowchart of an intelligent agent task scheduling and planning method according to an embodiment of the present invention. Detailed Implementation

[0014] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. Various aspects are provided by way of explanation and not limitation of the invention. Indeed, those skilled in the art will recognize that modifications and variations can be made to the invention without departing from its scope or spirit. For example, a feature represented or described as part of one embodiment may be used in another embodiment to produce yet another embodiment. Therefore, it is desirable that the invention encompass such modifications and variations falling within the scope of the appended claims and their equivalents.

[0015] In the description of this invention, the terms "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," and "bottom," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and do not require the invention to be constructed and operated in a specific orientation; therefore, they should not be construed as limitations on the invention. The terms "connected," "linked," and "set up" used in this invention should be interpreted broadly. For example, they can refer to a fixed connection or a detachable connection; they can refer to a direct connection or an indirect connection through intermediate components. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.

[0016] like Figure 1 As shown, this application provides an agent task scheduling and planning method, including: Step 1, parsing task instructions to generate independently executable atomic tasks to construct a subtask dependency graph; Step 2, determining the real-time resource occupancy state of the agent to obtain the agent resource state tensor, and performing resource-task association anchoring and dependency priority sorting based on the agent resource state tensor and the subtask dependency graph to generate a task priority sequence with resource constraints; Step 3, using a task-agent adaptation model, performing dynamic capability matching and predictive load balancing calculations on the task priority sequence with resource constraints to determine the target executing agent for each atomic task; Step 4, performing time-series scheduling orchestration and conflict resolution on the target executing agent and subtask dependency graph for each atomic task to generate an agent task scheduling collaborative execution scheme.

[0017] Optionally, step 1 includes: Step 11, semantically deconstructing and extracting core requirements from the task instructions to generate a set of core task elements; Step 12, performing granular splitting and independent executability determination on the set of core task elements to generate independently executable atomic tasks; Step 13, performing execution logic association analysis and dependency modeling on the atomic tasks to construct a subtask dependency graph. Optionally, step 11 includes: Step 111, segmenting and parsing the task instructions to generate an instruction syntax structure tree; Step 112, extracting key information from the instruction syntax structure tree to generate initial task elements; Step 113, removing redundancy and logically integrating the initial task elements to generate a set of core task elements.

[0018] Preferably, the specific implementation process of step 111 is as follows: The user-input composite task instruction is preprocessed for the scheduling scenario. First, modal particles and redundant modifiers that do not contribute semantic meaning (e.g., "please assist" in "please assist in completing industrial equipment data collection and analysis this week") are filtered out. Then, word segmentation is performed based on a word segmentation model customized for the intelligent agent task scheduling scenario to generate a scenario-adapted word segmentation sequence. Specifically, this word segmentation model uses gated recurrent units (Gated... The RecurrentUnit (GRU) layer is used as the basic feature extraction layer. The output layer integrates a scheduling scenario-specific lexicon and weight matrix. This lexicon contains core words strongly related to task scheduling (such as "computing power," "storage," "priority," "dependency," and "deadline"). The elements in the weight matrix correspond to the semantic contribution of each word in historical scheduling task instructions (values ​​range from 0 to 1; for example, the weight of "computing power" is set to 0.92, and ordinary words are set to 0.3-0.6). The GRU layer captures the contextual relationships between words and optimizes the word segmentation boundaries using the weight matrix, ensuring that core scenario words are not split. This ultimately generates a scenario-adapted word segmentation sequence containing scheduling-specific words. Based on this sequence, a syntactic analysis model incorporating scheduling grammar rules is used to construct an instruction grammar structure tree. This model, in addition to traditional... Based on dependency parsing, three new scheduling scenario-specific syntactic rules are added: "task action-resource requirement", "execution object-constraint", and "subtask-dependency". The words in the word segmentation sequence are syntactically annotated according to the hierarchy of "core action-execution object-resource requirement-constraint"-output target, and the semantic relationship of each component is presented in a tree structure. The root node of the tree is the core action of the composite task (such as "collect", "analyze", "organize"). The first-level child nodes correspond to the core components such as execution object (such as "industrial equipment data" "new product launch") and resource requirement (such as "GPU computing power" "storage capacity"). The second-level child nodes are the specific attributes of the corresponding first-level child nodes (such as "2 cores" and "10GB" for resource requirements, and "within this week" and "within 2 hours" for constraints). Finally, an instruction syntax structure tree containing the syntactic relationship of the scheduling scenario is generated.

[0019] Preferably, in the specific technical implementation of step 112: taking the instruction syntax structure tree as the processing object, the designed hierarchical semantic extraction network is used to generate initial task elements; specifically, the hierarchical semantic extraction network includes three core structures: a node embedding layer, a scene attention layer, and a feature classification layer. The node embedding layer converts each node (corresponding to a single word or phrase) of the instruction syntax structure tree into a fixed-dimensional semantic vector (the dimension is set to 64-256, for example, 128 dimensions). During the conversion process, the grammatical hierarchy weights of the nodes are incorporated (the weight of the root node is set to 0.9, the weight of the first-level child node is set to 0.7-0.8, and the weight of the second-level child node is set to 0.5-0.6), making the semantic features of the core-level nodes more prominent; the scene attention layer focuses on the core action nodes and the first-level child nodes in the instruction syntax structure tree. The semantic correlation between other nodes and the core node is calculated. The correlation is calculated based on the similarity of node semantic vectors and the distance at the syntactic level. Nodes with a correlation higher than a set threshold (e.g., 0.68) are selected as scheduling-related nodes. The feature classification layer uses a multi-layer perceptron (MLP) to classify the semantic vectors of scheduling-related nodes according to preset scheduling element categories (including task type, execution object, resource requirements, time constraints, priority, and dependency hints). The semantic vectors of nodes under each category are integrated into the initial element information of that category. The initial element information corresponding to all categories is summarized to form the initial task element. Each initial element is accompanied by its hierarchical position in the instruction syntax structure tree and the identifier of the associated node.

[0020] Preferably, in one scenario, step 113 is specifically implemented as follows: Semantic redundancy removal is performed on the initial task elements to generate de-redundant task elements. Specifically, a semantic similarity calculation method is used to compare initial task elements under the same element category pairwise. The semantic similarity is determined based on the cosine value of the semantic vector corresponding to the element. A similarity threshold (e.g., 0.82) is set, and initial task elements with similarity higher than the threshold are grouped into redundant groups. The element with the most complete information and the clearest semantic expression in each group is retained as a valid element, and the remaining redundant elements are removed to generate de-redundant task elements. Based on the associated node identifiers attached to the de-redundant task elements, an element semantic association network is constructed. The nodes of the element semantic association network are the de-redundant task elements, and the edges represent the semantic association relationships between elements (such as the matching association between "resource requirements" and "task type", "time constraints" and "execution objects"). The network is used to verify the logical consistency between various elements. For example, the storage capacity in "resource requirements" must match the data size of the "execution object," and the duration of "time constraints" must be compatible with the execution complexity of "task type." Elements with logical contradictions (such as the contradiction between time and data size in "processing 100GB of uncompressed data within 1 hour") are marked and their rationality is corrected based on the element matching patterns in historical scheduling tasks. The corrected and de-redundant task elements are then structured and integrated, organized according to the hierarchy of "core task information - execution constraint information - resource requirement information - relational information." Each element is labeled with its category, specific content, related element identifier, and logical consistency score (the score range is 0-10 points, determined based on the degree of matching between the element and related elements). Finally, a logically consistent and clearly structured set of core task elements is generated.

[0021] Optionally, step 12 includes: step 121, dividing the core task element set into execution unit granularity to generate candidate atomic tasks; step 122, verifying the independent execution conditions of the candidate atomic tasks to eliminate coupled task units; and step 123, integrating the verified task units to generate independently executable atomic tasks.

[0022] Preferably, the specific implementation process of step 121 is as follows: Based on the core task element set, combined with the task type and resource configuration characteristics of the intelligent agent scheduling scenario, the designed multi-level granularity partitioning model is used to partition the core task element set at the execution unit granularity to generate candidate atomic tasks; specifically, the multi-level granularity partitioning model includes three core modules: an element classification layer, a scenario granularity rule base, and a partitioning execution layer. The element classification layer first classifies and extracts the core task element set according to "task type - execution action - resource requirement - constraint condition". For example, after classifying the core task element set of "organizing a new product launch", the task type (event organization), execution action (designing posters, booking venues, etc.), resource requirement (GPU computing power, storage capacity, etc.), and constraint condition (time limit, dependency relationship, etc.) are obtained; the scenario granularity rule base has built-in granularity partitioning rules for different scheduling scenarios, and the rules are divided into "task type, execution action, resource requirement ... The three dimensions of "task complexity, resource consumption, and execution time" are set. For example, the granularity threshold for simple data processing scenarios is set to an execution time not exceeding a preset time (e.g., 30 seconds) and resource consumption not exceeding 20% ​​of the basic configuration of a single agent. The granularity threshold for complex activity organization scenarios is set to an execution time not exceeding a preset time (e.g., 10 minutes) and containing a single core action. The execution layer is divided according to the element classification results and the corresponding rules in the scenario granularity rule base. The composite execution actions in the core element set of the task are decomposed into single core action units. Each unit is associated with corresponding resource requirements and constraints, generating candidate atomic tasks that include task identifier, core action, resource requirement details, constraints, and estimated execution time. For example, "data collection and analysis" is decomposed into three independent units: "data collection candidate atomic task", "data preprocessing candidate atomic task", and "data analysis candidate atomic task".

[0023] Preferably, in the specific technical implementation of step 122: taking candidate atomic tasks as the processing object, a designed multidimensional independent execution verification model is used to verify the independent execution conditions of candidate atomic tasks to eliminate coupled task units; specifically, the multidimensional independent execution verification model includes an input-output parsing layer, a dependency detection layer, and an independent feasibility determination layer. The input-output parsing layer extracts the input parameter type (such as original data, intermediate results, preset parameters) and output result type (such as processed data, status identifier, resource occupation and release information) of each candidate atomic task, clarifying the input source and output destination of each candidate atomic task; the dependency detection layer constructs an input-output correlation matrix between candidate atomic tasks based on the input-output parsing results. The rows and columns of this matrix correspond to candidate atomic task identifiers, and the matrix element values ​​represent the degree of correlation between the input of the candidate atomic task in the corresponding row and the output of the candidate atomic task in the corresponding column (the value range is 0-1, where 0 represents no correlation). (1 represents complete dependence). At the same time, combined with the constraints of the core elements of the task, the system detects whether there is implicit input dependency in the candidate atomic tasks (such as a candidate atomic task requiring the execution state of another candidate atomic task as implicit input). The independent feasibility judgment layer sets multi-dimensional independent execution judgment criteria, including input independence (input parameters can be obtained directly from the system's preset resources or external data sources without depending on the output of other candidate atomic tasks), resource exclusivity (required resources can be allocated independently without sharing exclusive resources with other candidate atomic tasks), and execution time independence (there is no explicit constraint requiring it to start before or after the execution of other candidate atomic tasks). Each candidate atomic task is scored according to the correlation matrix and judgment criteria (maximum score of 10 points, 3-4 points for meeting one criterion). A scoring threshold is set (such as 7 points). Candidate atomic tasks with scores below the threshold are judged as coupled task units and eliminated, while independent candidate atomic tasks that pass the verification are retained.

[0024] Preferably, in a scenario, step 123 is specifically implemented as follows: Structured attribute completion and unique identifier allocation are performed on the verified independent candidate atomic tasks to generate independently executable atomic tasks. Specifically, attribute completion is performed on each independent candidate atomic task, supplementing task priority (determined based on priority information and execution impact range of the core task elements, divided into high, medium, and low levels; for example, those affecting the overall task progress are set to high level), resource requirement threshold (determined based on historical resource consumption data of similar tasks and current agent resource configuration, specifying minimum requirements for computing power, storage, and communication bandwidth, such as a minimum of 2 GPU cores and a minimum of 5GB of storage), and execution timeout threshold (based on estimated execution timeout). Set the timeout threshold to 1.5-2 times the row duration (e.g., if the estimated timeout is 30 seconds, set it to 45-60 seconds). Then, assign a unique task identifier to each completed independent candidate atomic task. The identifier includes the task type code, priority code, and sequence number (e.g., "Data Processing-High-001"). Finally, classify and integrate the completed independent candidate atomic tasks according to task type and priority to generate a set of independently executable atomic tasks containing complete attributes such as task identifier, core action, input and output parameters, resource requirement threshold, priority, and execution timeout threshold. Each independently executable atomic task in this set can be started and executed independently after acquiring the required resources, without waiting for the execution results of other tasks.

[0025] Optionally, step 13 includes: step 131, extracting the execution preconditions for the atomic tasks to generate the preconditions of each atomic task; step 132, matching and associating the preconditions with other atomic tasks to generate atomic task dependency pairs; and step 133, performing graph-based modeling on the atomic task dependency pairs to construct a subtask dependency graph.

[0026] Preferably, the specific implementation process of step 131 is as follows: Taking independently executable atomic tasks as the processing objects, the designed dual-track precondition extraction model is used to extract the execution preconditions for each atomic task to generate complete precondition dependencies for the atomic task; specifically, the dual-track precondition extraction model includes an explicit condition parsing layer and an implicit condition detection layer. The explicit condition parsing layer directly extracts clearly marked preconditions from the attribute information of the atomic task, including the source of input data (such as "requires product data collection results"), resource occupancy prerequisites (such as "requires GPU computing power to be idle"), and timing constraints (such as "must be executed after the reserved venue is completed"), generating an explicit precondition set; the implicit condition detection layer, based on the task type, core actions, and historical scheduling data of the atomic task, mines implicit dependencies through semantic association analysis and scene rule matching. This layer has a built-in scheduling field. The system employs an implicit dependency rule base, which contains a mapping relationship between "task type - implicit dependency" (e.g., data processing tasks implicitly depend on data preprocessing completion, and event organization tasks implicitly depend on venue / resource confirmation). It also uses a semantic association model based on a bidirectional long short-term memory (Bi-LSTM) network to calculate the semantic similarity between the outputs of the current atomic task and other atomic tasks. Outputs with similarity scores higher than a set threshold (e.g., 0.75) are selected as implicit input requirements, generating an implicit precondition set. The explicit and implicit precondition sets are then merged and deduplicated. Each condition is labeled with an "explicit / implicit" type identifier and associated attributes (e.g., data type, resource type, timing requirements), ultimately generating complete preconditions for the atomic task.

[0027] Preferably, in the specific technical implementation of step 132: taking the complete pre-dependencies of the atomic task and all independently executable atomic tasks as the processing objects, a designed multi-dimensional dependency matching model is used for matching and association to generate atomic task dependency pairs; specifically, the multi-dimensional dependency matching model includes an attribute matching layer, a semantic association layer, and a scenario rule verification layer. The attribute matching layer extracts key attributes (such as data identifier, resource type, task identifier) ​​from the complete pre-dependencies of the atomic task and accurately matches them with the output attributes and resource provision capabilities of other atomic tasks to generate an attribute matching candidate set; the semantic association layer uses word embedding technology to convert the pre-conditions and the core actions and output results of other atomic tasks into semantic vectors, calculates the cosine similarity between the vectors, and selects atomic tasks with a similarity higher than a set threshold (e.g., 0.8) as semantic association candidate sets; The scenario rule verification layer calls the scenario dependency matching rule library, which contains "precondition type - matching verification rule" (e.g., time-series constraint conditions need to verify the execution duration and time window compatibility of candidate atomic tasks, and resource conditions need to verify the resource release timing of candidate atomic tasks). It performs cross-verification on the attribute matching candidate set and the semantic association candidate set, and eliminates candidate associations that do not conform to the scenario rules. The dependency strength of the verified associations is quantified. The dependency strength is calculated based on the weighted average of attribute matching degree, semantic similarity and scenario rule adaptability (the value range is 0-1, for example, 1.0 for complete matching and 0.5-0.9 for partial matching). Finally, the combination of "current atomic task - associated atomic task - dependency type - dependency strength" is taken as the atomic task dependency pair, where the associated atomic task is the provider atomic task that meets the precondition dependency.

[0028] Preferably, in one scenario, step 133 is specifically implemented as follows: A hierarchical graph modeling model is used to construct a subtask dependency graph, with atomic task dependency pairs as the processing objects. Specifically, this model includes a node construction layer, an edge construction layer, and a graph optimization layer. The node construction layer treats each independently executable atomic task as a graph node. Node attributes include task identifier, task type, resource requirements, estimated execution time, and priority. A unique identifier is assigned to each node (composed of task type code + sequence number, such as "data processing-001"). The edge construction layer maps atomic task dependency pairs to directed edges in the graph. The starting point of each edge is the associated atomic task (dependency provider), and the ending point is the current atomic task (dependency requester). Edge attributes include dependency type (explicit / implicit), dependency strength, and constraints (such as timing window and data format requirements). The edge weight is set to strong dependency. The degree (ranging from 0 to 1) represents the weight, with higher values ​​indicating more critical dependencies. The graph optimization layer uses a depth-first search (DFS) algorithm to detect loops in the initially constructed graph. If a loop is found (e.g., task A depends on B, B depends on C, and C depends on A), the edge with the lowest strength is removed based on dependency strength, and a loop adjustment prompt is generated (marking the atomic tasks and dependency pairs involved in the loop). Simultaneously, dependency integrity is checked, verifying whether all complete prerequisite dependencies for each atomic task have been mapped to graph edges. Unmapped dependencies are marked as "unmatched dependencies" and prompted for supplementation. Finally, a graph database (e.g., Neo4j) is used to store the optimized nodes and edges, generating a structured subtask dependency graph containing node attributes, edge attributes, and dependency levels. The graph supports hierarchical querying and visualization by dependency type, dependency strength, and task priority.

[0029] Optionally, step 2 includes: step 21, real-time monitoring of the computing power, storage, and communication links of each agent to generate agent resource monitoring data; step 22, tensor modeling of the agent resource monitoring data to obtain an agent resource state tensor; step 23, resource-task association anchoring based on the agent resource state tensor and subtask dependency graph to generate a resource-adapted task set; step 24, dependency priority sorting of the resource-adapted task set to generate a task priority sequence with resource constraints. Optionally, step 21 includes: step 211, collecting the computation thread occupancy rate of the agent's computing power to generate computing power occupancy data; step 212, collecting the remaining space and read / write rate of the agent's storage to generate storage status data; step 213, collecting the bandwidth occupancy and latency of the agent's communication links to generate communication status data; step 214, integrating the computing power occupancy data, storage status data, and communication status data to generate agent resource monitoring data.

[0030] Preferably, the specific implementation process of step 211 is as follows: Multi-dimensional dynamic acquisition and noise filtering are performed on the computing resources of the agent to generate high-fidelity computing power occupancy data. Specifically, the acquisition targets include the CPU, GPU, and other computing cores of the agent. An adaptive frequency acquisition model is used to control the acquisition rhythm. This model dynamically adjusts the acquisition interval based on the agent's current task load. When the computing power occupancy rate is lower than a set low threshold (e.g., 30%), the acquisition interval is set to a longer duration (e.g., 5 seconds) to reduce system overhead. When the computing power occupancy rate is higher than a set high threshold (e.g., 70%), the acquisition interval is shortened to a shorter duration (e.g., 1 second) to capture load fluctuations. The acquisition content includes the occupancy of computing threads. The data includes CPU thread utilization, GPU core utilization, and task queue length. The CPU thread utilization is calculated by iterating through the running thread list of each core and counting the proportion of threads in a "running" state to the total number of threads. Core utilization is obtained by reading the hardware counter to determine instruction execution efficiency. The task queue length is calculated by counting the number of tasks waiting to be allocated computing resources. The raw data is subjected to sliding window mean filtering for noise suppression. The window size is dynamically adjusted according to the collection interval (e.g., a 1-second interval corresponds to a window size of 5, and a 5-second interval corresponds to a window size of 3). Sudden burst noise is removed, and the final result is high-fidelity computing power usage data containing the collection timestamp, CPU thread utilization, GPU core utilization, and task queue length.

[0031] Preferably, in the specific technical implementation of step 212: the storage resources of the intelligent agent are collected and quantified in two dimensions to generate structured storage state data; specifically, the collection dimensions are divided into static storage capacity and dynamic read / write performance. Static storage capacity is collected by calling the storage management interface to traverse each storage partition, collecting the total capacity, used capacity, and remaining capacity, while verifying the consistency of data in each partition to avoid numerical deviations caused by partition mounting anomalies; dynamic read / write performance adopts an asynchronous collection mode, performing read / write operations by simulating standard-sized test data blocks (such as 4KB, 8KB, 64KB), collecting the sequential read / write rate and random read / write rate corresponding to different data block sizes, avoiding the storage access period of the current high-priority task during the collection process to reduce interference with task execution; the collected data is quantified in state, converting the remaining capacity into the remaining capacity percentage (remaining capacity / total capacity), comparing the read / write rate with the theoretical peak rate of the storage medium to generate the rate compliance rate, and finally integrating it into structured storage state data containing the collection timestamp, the remaining capacity and percentage of each partition, the read / write rate of different data block sizes, and the rate compliance rate.

[0032] Preferably, the specific implementation process of step 213 is as follows: Full-link feature collection and quality assessment processing are performed on the communication link of the intelligent agent to generate multi-dimensional communication state data; specifically, the communication link covers the network connection between the intelligent agent and other intelligent agents and external data sources. The collection objects include link bandwidth, transmission delay, packet loss rate, and jitter value. A combination of network packet capture and active probing is adopted. Packet capture obtains the size and interval of the actual transmitted data packets by listening to the network interface and calculates the real-time bandwidth utilization rate (used bandwidth / total bandwidth). Active probing obtains the transmission delay by sending fixed-size ICMP request packets (e.g., 64 bytes) and calculating the time difference between sending the request packet and receiving the response. Continue sending a preset number of probe packets (e.g., 10). Calculate the packet loss rate based on the number of packets without a response and the jitter value based on the standard deviation of each latency. For multi-link agents, collect data according to link priority (e.g., core business link, backup link), and record the connection status (connected / disconnected / abnormal) of each link. Perform quality assessment on the collected data, calculating a communication quality score (out of 10) based on the weights of bandwidth utilization, transmission latency, packet loss rate, and jitter value (e.g., 0.3, 0.4, 0.2, 0.1 respectively). Finally, generate multi-dimensional communication status data including collection timestamp, bandwidth utilization of each link, transmission latency, packet loss rate, jitter value, connection status, and communication quality score.

[0033] Preferably, in the specific technical implementation of step 214: based on high-fidelity computing power occupancy data, structured storage status data, and multi-dimensional communication status data, a designed time-series alignment and structured integration model is used to fuse the data to generate standardized intelligent agent resource monitoring data; specifically, the time-series alignment module synchronizes and matches the three types of data according to the collection timestamp, and associates computing power, storage, and communication data of the same time dimension into a group based on the timetamp difference not exceeding a set threshold (such as 200 milliseconds); the structured integration module organizes the data according to a hierarchical structure of "resource type - core indicator - status parameter - quality assessment", where resource types are divided into computing power, storage, and communication, and core indicators correspond to various types of resources. The key monitoring items for the source are: status parameters, which are specific collected values; and quality assessment, which are status scores for various resources (computing power scores are calculated based on thread occupancy and task queue length; storage scores are calculated based on remaining capacity percentage and rate compliance rate; and communication scores directly adopt the communication quality scores). Simultaneously, a unique monitoring identifier is assigned to each set of data, including the agent ID, data collection period, and data integrity flag (marking whether data is missing). Finally, standardized agent resource monitoring data is generated, including the monitoring identifier, time-aligned subsets of computing power status, storage status, and communication status, as well as quality scores for various resources. This data can be directly input into subsequent resource state tensor modeling processes.

[0034] Optionally, step 22 includes: step 221, performing dimensional normalization processing on the agent resource monitoring data to generate standardized resource data; step 222, performing multi-dimensional tensor mapping on the standardized resource data to generate an initial resource tensor; and step 223, assigning dynamic weights to the initial resource tensor to obtain the agent resource state tensor.

[0035] Preferably, the specific implementation process of step 221 is as follows: Taking the intelligent agent resource monitoring data as the processing object, the data includes multiple dimensions of indicators for three types of resources: computing power, storage, and communication links (such as the computing thread occupancy rate, the remaining storage space, and the bandwidth occupancy rate of communication links). The dimensions and numerical ranges of different indicators vary greatly (such as occupancy rate as a percentage, storage capacity in GB, and latency in ms). The min-max normalization method is used to perform a linear transformation on all data of each indicator dimension, mapping the data values ​​to a unified range (such as 0-1). The mapping formula is determined based on the historical maximum and minimum values ​​of the indicator (for example, if the historical maximum value of an indicator is M and the minimum value is m, the normalized data x is (xm) / (Mm)). The validity of each normalized data point is verified, and abnormal data that exceeds the 0-1 range after mapping (due to extreme historical values) is removed, generating standardized resource data to ensure that data of different resource types and different indicator dimensions are comparable.

[0036] Preferably, in the specific technical implementation of step 222: using standardized resource data as the processing object, and based on the scenario requirements of sales agent task scheduling, a four-dimensional tensor structure is designed for resource state modeling. The first dimension of this tensor is "agent identifier," corresponding to each independent sales agent in the cluster (such as agent A and agent B), used to distinguish different resource supply entities; the second dimension is "resource type," including three core resources: computing power, storage, and communication links, corresponding to the main resource demand direction of sales tasks; the third dimension is "indicator dimension," with multiple specific monitoring indicators under each resource type (such as computing power including operation thread occupancy rate, CPU core utilization rate, etc., and storage including remaining storage space, read / write speed, etc.); the fourth dimension is "time series," containing the data of the most recent preset number of collection cycles (such as the most recent 10 collection cycles, each cycle being 5 seconds), used to characterize the temporal change trend of resource state; the standardized resource data is mapped and filled one by one according to the above four-dimensional structure, with each data point corresponding to a coordinate position of the tensor (agent identifier - resource type - indicator dimension - time node), generating an initial resource tensor, which fully preserves the multi-dimensional and temporal characteristics of agent resources.

[0037] Preferably, in the specific technical implementation of step 223: taking the initial resource tensor as the processing object, and combining the differences in resource requirement weights of different types of tasks in the sales scenario, a dynamic weight allocation mechanism is designed; firstly, a mapping relationship table between sales task types and resource weights is constructed, where task types include product query (dependent on communication links and computing power), parameter filtering (dependent on computing power), result storage (dependent on storage), voice interaction (dependent on communication links and computing power), etc., and each task type corresponds to a set of resource type weights (the total weight is 1.0). For example, the computing power weight of product query tasks is 0.4, the storage weight is 0.2, and the communication link weight is 0.4, while the computing power weight of parameter filtering tasks is 0.6 and the storage weight is 0. 2. Communication link weight 0.2; Based on the type distribution of the current sales tasks to be scheduled, calculate the comprehensive weight of each type of resource (for example, if product query accounts for 60%, parameter filtering accounts for 30%, and result storage accounts for 10% of the current tasks to be scheduled, then the comprehensive weight of computing power = 0.4 × 60% + 0.6 × 30% + 0.2 × 10% = 0.44); All indicator dimension data corresponding to each resource type in the initial resource tensor are weighted according to the comprehensive weight of the resource type to obtain the fused resource state value of each agent at each time node, and finally form an agent resource state tensor with the four-dimensional structure unchanged but the data fused by weight. This tensor can accurately match the resource demand priority of the current sales task.

[0038] Optionally, step 23 includes: step 231, extracting resource requirements of atomic tasks based on the subtask dependency graph to obtain the resource requirement characteristics of each atomic task; step 232, matching and calculating the resource requirement characteristics with the agent's resource state tensor to determine the resource matching score; step 233, screening atomic tasks that meet the resource matching score to construct a resource-adaptive task set.

[0039] Preferably, the specific implementation process of step 211 is as follows: The computing resources of the intelligent agent are dynamically collected and subjected to interference filtering in a layered manner to generate computing power status representation data. Specifically, the collection targets cover the CPU, GPU, and other computing cores of the intelligent agent. A designed load-aware collection model is used to control the collection rhythm. This model dynamically adjusts the collection interval by monitoring the load fluctuation of the computing cores in real time (e.g., the occupancy rate changes by more than a set proportion (e.g., 20%) within 5 seconds). When the load is stable, a longer collection interval (e.g., 3-5 seconds) is used to reduce system overhead; when the load fluctuates violently, a shorter collection interval (e.g., 0.5-1 second) is switched to capture instantaneous changes. The collected content includes the computing thread occupancy rate and the core idle occupancy rate. The ratio of running threads to total threads is calculated by traversing the thread scheduling queues of each core. The core idle ratio is read from the hardware status interface to determine the percentage of cores without assigned tasks. The task queue length is calculated to determine the number of atomic tasks waiting to be allocated computing resources. The raw data is processed using an adaptive median filter to filter out interference. The filter window size is dynamically adjusted according to the load fluctuation (a smaller window value (e.g., 3) is set when the fluctuation is large to preserve details, and a larger window value (e.g., 5) is set when the fluctuation is small to smooth noise). Finally, computing power status representation data including collection timestamp, CPU thread utilization, GPU core idle ratio, and task queue length are generated.

[0040] Preferably, in the specific technical implementation of step 212: the storage resources of the intelligent agent are subjected to dual-dimensional synchronous collection and state quantization processing to generate storage state characterization data; specifically, the collection dimensions are divided into capacity status and read / write performance. The capacity status is collected by calling the storage management interface to traverse all storage partitions, collecting the total capacity, used capacity, and remaining capacity of each partition. At the same time, the consistency between the total capacity and the sum of the capacities of each partition is checked through a cross-partition data verification mechanism to avoid data deviation caused by partition mounting anomalies; the read / write performance is collected in a non-intrusive manner by listening to the storage I / O request queue, counting the number of read / write requests and the average request size per unit time, and calculating the sequential read / write rate and random read / write rate. The collection process avoids the intensive I / O period of high-priority atomic tasks, and the collection priority is set lower than the task execution priority to reduce interference with task execution; the collected data is quantified, the remaining capacity is converted into the remaining capacity percentage (the ratio of remaining capacity to total capacity), and the read / write rate is compared with the theoretical peak rate of the storage medium to obtain the rate achievement rate. Finally, the data is integrated into storage state characterization data that includes the collection timestamp, the capacity details and percentage of each partition, the read / write rate, and the achievement rate.

[0041] Preferably, the specific implementation process of step 213 is as follows: Full-link feature collection and quality assessment processing are performed on the communication links of the intelligent agent to generate communication state characterization data. Specifically, the communication links cover all network connections between the intelligent agent and other intelligent agents and external data nodes. The collection objects include bandwidth utilization, transmission latency, data packet loss rate, and link jitter. Bandwidth utilization is obtained by statistically analyzing the ratio of the total number of data packets transmitted per unit time to the rated bandwidth of the link. Transmission latency is obtained by sending fixed-size probe data packets (e.g., 64 bytes) and recording the round-trip time, taking the average of multiple measurements. Data packet loss rate is obtained by statistically analyzing the number of probe data packets sent. Link jitter is calculated by calculating the standard deviation of multiple transmission delays based on the ratio of the difference between the packet and the received response packet. For agents with multiple links, data is collected separately according to the purpose of the link (such as core task link, backup link), and the connection status (normal / abnormal / disconnected) of each link is recorded. Communication quality is evaluated based on the collected data, and a comprehensive quality score (out of 10) is calculated based on the preset weights of bandwidth utilization, transmission delay, packet loss rate, and jitter (such as 0.3, 0.3, 0.2, and 0.2 respectively). Finally, communication status characterization data containing collection timestamps, transmission characteristics of each link, connection status, and comprehensive quality score is generated.

[0042] Preferably, in the specific technical implementation of step 214: the computing power status representation data, storage status representation data, and communication status representation data are subjected to time-series alignment and structured integration processing to generate intelligent agent resource monitoring data; specifically, firstly, time-series alignment is performed through a timestamp synchronization module, using the standard that the difference in the collected timestamps does not exceed a set threshold (e.g., 300 milliseconds), and the three types of resource data in the same time dimension are associated as a set of time-series data to ensure the time consistency of the data; then, the data is organized hierarchically according to the structured integration module according to the hierarchy of "resource dimension - core indicators - status parameters - quality assessment", where the resource dimension is divided into computing power, storage, and communication, and the core indicators correspond to the key monitoring items of each type of resource, and the status parameters are further organized according to the hierarchy of "resource dimension - core indicators - status parameters - quality assessment". The state parameters are specific collected values, and the quality assessment is the state score of various resources (the computing power score is calculated based on the thread utilization rate and task queuing length, the storage score is calculated based on the remaining capacity ratio and rate achievement rate, and the communication score directly adopts the comprehensive quality score). Finally, a unique monitoring identifier is assigned to each set of integrated data. The identifier includes the agent ID, data collection period, and data integrity mark (marking whether there is missing or abnormal data). Finally, agent resource monitoring data is generated, which includes the monitoring identifier, time-aligned subsets of various resource states, and overall resource quality assessment. This data can be directly input into the subsequent resource state tensor modeling stage to provide complete and consistent resource state support for resource-task association anchoring.

[0043] Optionally, step 24 includes: step 241, dividing the dependency hierarchy in the subtask dependency graph to generate a task dependency hierarchy sequence; step 242, assigning priority values ​​to the resource adaptation task set in combination with the task dependency hierarchy sequence to construct an initial priority task set; and step 243, sorting and optimizing the initial priority task set to generate a task priority sequence with resource constraints.

[0044] Preferably, the specific implementation process of step 241 is as follows: The subtask dependency graph is subjected to hierarchical parsing and strength quantization to generate a hierarchical dependency sequence. Specifically, the designed dependency hierarchy partitioning model is adopted. This model takes the nodes (atomic tasks) and directed edges (dependencies) of the subtask dependency graph as processing objects. First, the basic execution order of atomic tasks is determined by the topological sorting algorithm, and atomic tasks without prior dependencies are identified as initial hierarchy nodes. Then, based on the dependency strength attribute of the dependency edges (explicit dependencies are set to a higher base value (e.g., 0.8), and implicit dependencies are set to a lower base value (e.g., 0.5)), combined with the original... The resource requirement correlation of subtasks is calculated, and the dependency propagation weight of each atomic task is determined. The dependency propagation weight represents the degree of influence of the atomic task on subsequent tasks. Atomic tasks are divided into several dependency levels according to the basic execution order and dependency propagation weight. The same level contains atomic tasks with no direct dependency relationship and similar dependency propagation weights. The level number is incremented in the execution order (e.g., 1, 2, 3, ...). Each level is labeled with the peak total resource requirement and average dependency strength of all atomic tasks in that level. Finally, a hierarchical dependency sequence containing level number, atomic task list, level resource requirement, and average dependency strength is generated.

[0045] Preferably, in the specific technical implementation of step 242: based on the hierarchical dependency sequence and resource adaptation task set, a designed multi-dimensional priority assignment model is used to assign priority values ​​to construct an initial priority task set; specifically, the assignment dimensions of this model include dependency level weight, resource adaptability, and task influence weight. The dependency level weight is set in reverse order of the level number (the smaller the level number, the higher the weight, such as level 1 set to 0.4, level 2 set to 0.3, and so on), ensuring that tasks at the first level receive a higher priority base score; the resource adaptability directly uses the resource matching score (range 0-1) generated during the resource-task matching process, and is included in the total priority score according to a preset ratio (such as 0.3). The task impact weight is determined based on the degree of influence of the execution result of the atomic task on the overall composite task. The degree of influence is calculated by analyzing the number of outgoing edges of the atomic task in the subtask dependency graph (i.e., the number of subsequent tasks that depend on this task) and the sum of the dependency strengths. The more outgoing edges and the higher the sum of the dependency strengths, the greater the task impact weight (the value ranges from 0 to 1, and is included in the total priority score according to a preset ratio (e.g., 0.3)). The weighted sum of the scores of the three dimensions is used to obtain the total priority score (out of 10) for each atomic task. The tasks are divided into three priority levels: high, medium, and low, according to the total score. At the same time, the total priority score, the detailed score of each dimension, and the dependency level of each atomic task are labeled, generating an initial priority task set.

[0046] Preferably, the specific implementation process of step 243 is as follows: Resource constraint conflict resolution and sorting optimization are performed on the initial priority task set to generate a task priority sequence with resource constraints. Specifically, a resource constraint conflict detection matrix is ​​first constructed. The rows and columns of this matrix correspond to atomic tasks in the initial priority task set. The matrix element values ​​represent the degree of resource conflict between the atomic tasks in the corresponding row and column (calculated based on the resource demand type and peak demand of both; no conflict is set to 0, slight conflict to 0.3, and severe conflict to 0.7). Resource conflict groups (i.e., combinations of atomic tasks with element values ​​higher than a set threshold (e.g., 0.5)) are identified by traversing the matrix. For atomic tasks with the same priority level in the same conflict group, priority is determined by… Resource suitability is sorted from high to low; if resource suitability is the same, it is sorted by task impact weight. For atomic tasks of different priority levels, the sorting position of high-priority tasks is retained first, and the execution order of low-priority tasks is adjusted to avoid resource conflicts. For example, if high-priority task A and low-priority task B have a severe conflict over storage resources, task B is adjusted to be sorted after task A is executed. After sorting, tasks are arranged from high to low according to total priority score, and those with the same priority are arranged in the order after conflict resolution, generating a task priority sequence with resource constraints. Each atomic task in the sequence is accompanied by a priority level, resource requirement details, conflict adjustment instructions, and estimated execution time suggestions to ensure that the sequence conforms to dependency logic and adapts to the current resource supply status of the agent.

[0047] Optionally, step 3 includes: Step 31, constructing a task-agent adaptation model, wherein the task-agent adaptation model is obtained by fusing a dynamic capability evolution network, a load prediction feedback loop, and a task type adaptation rule base; Step 32, inputting a task priority sequence with resource constraints and an agent resource state tensor into the task-agent adaptation model, outputting an agent-task dynamic matching matrix through the dynamic capability evolution network, and performing matching verification in conjunction with the task type adaptation rule base to determine a candidate set of capability-matching agents; Step 33, based on the agent predicted load value output by the load prediction feedback loop, fusing the type weights of the task type adaptation rule base, performing dynamic load balancing calculation on the candidate set of capability-matching agents, and selecting the target execution agent for each atomic task. Optionally, step 31 includes: step 311, collecting historical task execution data, real-time resource state tensor and task type adaptation records of each agent, extracting temporal features from the historical task execution data to obtain the capability evolution trend vector, performing residual fusion of the capability evolution trend vector and the real-time resource state tensor, and then learning the adaptation weights of different task types through an attention mechanism to generate a dynamic capability evolution network.

[0048] Preferably, the specific implementation process of step 311 is as follows: The multi-source input data of each agent is cleaned, integrated, and feature-standardized to generate a unified format of agent capability base dataset. Specifically, the multi-source input data includes the agent's historical task execution data, real-time resource state tensor, and task type adaptation records. The historical task execution data covers the atomic task identifiers, task types, resource consumption details, execution duration, and completion quality scores executed within a preset time period (e.g., 30 days). The real-time resource state tensor is a standardized tensor data containing computing power, storage, and communication dimensions (each dimension has a value). The task type adaptation record (range 0-1) includes the historical adaptation success rate and average adaptation time of the agent for different task types (such as data processing, activity organization, and resource scheduling). Missing value imputation (using the statistical mean of the same type of task) and outlier removal (removing data that deviates from the normal range based on the 3σ principle) are performed on the historical execution task data. The task type adaptation record is encoded (the task type is converted into a one-hot encoded vector). The three types of data are associated and aligned according to the agent ID and timestamp to generate a basic dataset of agent capabilities containing agent identifier, timestamp, and multi-dimensional feature items.

[0049] Preferably, based on the agent's capability dataset, hierarchical temporal feature extraction is performed on historical task execution data to generate an agent capability evolution trend vector. Specifically, a designed temporal feature extraction model is adopted, which includes a short-term feature extraction layer, a long-term feature extraction layer, and a feature fusion layer. The short-term feature extraction layer uses a gated recurrent unit (GRU) network, inputting historical task execution data within a preset short-term time window (e.g., 7 days) to capture short-term fluctuation features of the agent's capabilities (e.g., recent changes in the efficiency of a certain type of task execution). The long-term feature extraction layer uses a bidirectional long short-term memory (BSM) network. The Memory (Bi-LSTM) layer takes historical task execution data within a preset long-term time window (e.g., 30 days) as input and mines the long-term evolution trend of the agent's capabilities (e.g., the steady improvement or decline of computing power adaptation capability). The feature fusion layer integrates short-term fluctuation features and long-term evolution trend features through splicing operations, and then maps them into a fixed-dimensional (e.g., 64-dimensional) vector through a fully connected layer. Each element of this vector corresponds to the quantized value of the evolution trend of a certain capability dimension of the agent (with a value range of 0-1), and finally generates the agent capability evolution trend vector.

[0050] Preferably, residual fusion processing is performed on the agent's capability evolution trend vector and the real-time resource state tensor to generate a basic vector of the agent's dynamic capabilities. Specifically, firstly, the dimensions of the real-time resource state tensor are adjusted to match the dimensions of the agent's capability evolution trend vector (e.g., flattening a 3D tensor into a 64D vector and supplementing the dimensional difference through interpolation). Then, a residual fusion module is constructed. This module uses the agent's capability evolution trend vector as the reference vector and the real-time resource state tensor as the residual vector, and achieves fusion of the two through vector addition. During the fusion process, dynamic weights are assigned to the real-time resource state tensor (the weights are determined based on the agent's current load level; the higher the load, the larger the weight (e.g., 0.6-0.8), and the lower the load, the smaller the weight (e.g., 0.3-0.5)) to highlight the impact of the real-time resource state on the current capabilities. Finally, a basic vector of the agent's dynamic capabilities containing historical evolution features and real-time state features is generated.

[0051] Preferably, based on the agent's dynamic capability foundation vector and task type adaptation records, an attention mechanism is used to learn adaptation weights for different task types to generate a dynamic capability evolution network. Specifically, a task type attention layer is constructed. The input to this layer is the agent's dynamic capability foundation vector and the encoding vectors of all task types (e.g., 10-dimensional one-hot encoding vectors corresponding to 10 task types). Initial attention weights are obtained by calculating the semantic similarity between the agent's dynamic capability foundation vector and the encoding vectors of each task type. The initial attention weights are then adjusted by combining the historical adaptation success rate and average adaptation time in the task type adaptation records. Task types with higher historical adaptation success rates and shorter adaptation times correspond to higher attention weights. The larger the weight, the more weights are used. The corrected attention weights are then weighted and fused with the agent's dynamic capability base vector to obtain the agent's dynamic adaptation capability vector for different task types. Finally, a neural network is constructed, consisting of an input layer, a hidden layer (2-3 fully connected layers), and an output layer. The input layer receives multi-source feature data from the agent, the hidden layer performs feature depth mining, and the output layer outputs the agent's dynamic adaptation capability vector for each task type. The network parameters are trained using a backpropagation algorithm (based on the adaptation results of historical task type adaptation records as labels), ultimately generating a dynamic capability evolution network. This network can output the dynamic adaptation capability evaluation results for different task types in real time based on the input agent data.

[0052] Optionally, step 31 includes: step 312, constructing a time-series prediction model based on the agent's historical load data, inputting the agent's real-time load value and outputting the predicted load value for a future preset period, combining the task execution duration annotation in the subtask dependency graph and the type load coefficient of the task type adaptation rule library to generate a dynamic correction rule for the load threshold, forming a load prediction feedback loop.

[0053] Preferably, the specific implementation process of step 312 is as follows: Multi-dimensional feature extraction and standardization processing are performed on the historical load data of the agent to generate a load prediction feature dataset; specifically, the historical load data of the agent covers time-series data such as computing power utilization, storage utilization, bandwidth utilization, and task concurrency within a preset time period (e.g., 90 days), with a collection granularity of fixed short intervals (e.g., 10 seconds / time); outlier removal (removing extreme values ​​exceeding the interquartile range based on box plot method) and missing value filling (using linear interpolation to fill continuous missing values) are performed on the historical load data. The data is first lost, and then classified by resource type (computing power, storage, communication). The time-series features of each resource type are extracted, including trend features (such as sliding window mean, linear trend slope), periodic features (such as daily periodic fluctuation amplitude, weekly periodic peak period), and mutation features (such as load mutation time, mutation amplitude). All features are normalized to the same value range (such as 0-1) and organized into fixed-dimensional (such as 128-dimensional) feature vectors according to timestamp order. Finally, a load prediction feature dataset containing agent ID, timestamp, and multi-dimensional load features is generated.

[0054] Preferably, a hierarchical time-series prediction model is constructed based on the load prediction feature dataset to achieve accurate prediction of the agent's future load. Specifically, this hierarchical time-series prediction model includes a short-term prediction layer, a long-term prediction layer, and a result fusion layer. The short-term prediction layer employs gated recurrent units (GROUP). The first layer uses a GRU (Gross Unit) network, which takes load prediction feature data within a preset short-term time window (e.g., 1 hour) as input, captures the short-term rapid fluctuation pattern of load, and outputs the load prediction value for the next short-term period (e.g., 10 minutes). The second layer uses a Transformer encoder network, which takes load prediction feature data within a preset long-term time window (e.g., 24 hours) as input, mines the long-term cycle trend and correlation pattern of load, and outputs the load prediction value for the next long-term period (e.g., 1 hour). The third layer introduces a dynamic weight allocation mechanism, where the weights are dynamically adjusted based on the prediction error of different time periods (higher weights are assigned when the short-term prediction error is small (e.g., 0.7), and higher weights are assigned when the long-term prediction error is small (e.g., 0.6)). The short-term and long-term prediction results are weighted and fused to generate the final load prediction value for the next preset time period (e.g., 10 minutes, 30 minutes, 1 hour). This value is output separately according to resource type, and each resource type prediction value is accompanied by a prediction confidence score (calculated based on historical prediction errors, with a value range of 0-1).

[0055] Preferably, by combining the subtask dependency graph and the task type adaptation rule base, dynamic load threshold correction rules are generated to improve the load prediction feedback logic. Specifically, firstly, the execution duration annotation and dependency association information of each atomic task are extracted from the subtask dependency graph. The execution duration annotation is the estimated execution time range of each atomic task (e.g., 10-20 seconds), and the dependency association information includes the number of pre-dependent tasks and post-dependent tasks of the atomic task. Then, the task type adaptation rule base is queried to obtain the type load coefficient corresponding to the current atomic task type. The type load coefficient is determined based on the resource consumption ratio of similar tasks in history (e.g., the computing power load coefficient of data processing tasks is set to a higher value (e.g., 0.8), and the bandwidth load coefficient of communication transmission tasks is set to a higher value (e.g., ...). 0.9)); Based on the execution time, dependency information, and type load coefficient of atomic tasks, construct the calculation logic for the load threshold correction factor. The correction factor is positively correlated with the execution time, the number of preceding dependent tasks, and the type load coefficient. Generate dynamic load threshold correction rules. The rules specify the threshold correction methods corresponding to different predicted load value ranges, different task types, and different dependency strengths. For example, when the predicted computing power load value is higher than the preset basic threshold (e.g., 80%) and the atomic task is a high-priority data processing task, the computing power load threshold will be lowered by a preset ratio (e.g., 10%). When the predicted storage load value is lower than the preset basic threshold (e.g., 50%) and the atomic task dependency is weak, the storage load threshold will be raised by a preset ratio (e.g., 15%).

[0056] Preferably, the load prediction output of the hierarchical time-series prediction model is combined with the dynamic load threshold correction rule to form a complete load prediction feedback loop. Specifically, the input of the load prediction feedback loop is the real-time load value of the agent and the attribute information (task type, execution duration, dependency association information) of the atomic task to be assigned. The hierarchical time-series prediction model outputs the load prediction value for a future preset period. Based on the attribute information of the atomic task to be assigned, the dynamic load threshold correction rule is matched to obtain the corresponding load threshold correction amount. The initial load threshold is adjusted with the correction amount to generate a dynamic load threshold adapted to the current task scenario. The load prediction value is compared with the dynamic load threshold. If the prediction value is higher than the dynamic load threshold, a load warning signal is output, indicating that the agent is not suitable for assigning new tasks or that the task assignment order needs to be adjusted. If the prediction value is lower than the dynamic load threshold, a load availability signal is output to support subsequent task assignment. At the same time, the actual load data after task execution is input back into the hierarchical time-series prediction model to update the model parameters to optimize the prediction accuracy, forming a continuous iterative feedback mechanism to ensure that the load prediction and threshold correction always adapt to the agent's operating state and task execution requirements.

[0057] Optionally, step 31 includes: step 313, based on the matching history of the type features of atomic tasks and the ability evolution features of agents, generating a type-ability adaptation mapping rule of "task type-agent ability dimension-adaptation threshold" through statistical learning, embedding the rule into the attention weight learning link of the dynamic ability evolution network and the threshold correction link of the load prediction feedback loop, and integrating the three to construct a task-agent adaptation model.

[0058] Preferably, the specific implementation process of step 313 is as follows: Standardize and preprocess the atomic task type feature data, agent capability evolution feature data, and their historical matching results to generate a rule learning dataset; specifically, the atomic task type feature data includes task type encoding (such as data processing, activity organization, communication transmission, etc., converted into vector form using one-hot encoding), core resource requirement dimensions (weights of computing power, storage, and communication requirements), and execution complexity level (divided based on the number of task steps and the total resource consumption, such as low, medium, and high levels); the agent capability evolution feature data is the agent capability output by the dynamic capability evolution network. Force evolution trend vector (e.g., a 64-dimensional vector, with each element corresponding to the evolution quantification value of different capability dimensions); historical matching result data covers the matching records of atomic tasks and agents within a preset time period (e.g., 90 days), including indicators such as matching success rate, task completion quality score, resource utilization rate, and frequency of load exceeding the standard; the three types of data are normalized (mapped to the 0-1 interval), and the data is organized according to the correlation relationship of "atomic task type characteristics - agent capability evolution characteristics - historical matching results", and samples with abnormal matching results (e.g., resource utilization rate is lower than the preset ratio (e.g., 30%) or higher than the preset ratio (e.g., 95%)) are removed to generate a rule learning dataset.

[0059] Preferably, based on the rule learning dataset, a designed statistical learning model is used to mine association rules to generate a type-ability adaptation mapping rule set. Specifically, this statistical learning model integrates association rule mining algorithms and gradient boosting decision trees. First, the association rule mining algorithm analyzes the strong correlation dimensions between atomic task type features and agent capability evolution features. For example, data processing tasks are strongly correlated with the agent's GPU computing power and data read / write speed capabilities, while activity organization tasks are strongly correlated with the agent's network bandwidth and multi-task parallel scheduling capabilities. Then, the gradient boosting decision tree is used to train on historical matching result data to improve matching success rate, Resource utilization and the frequency of overload are the target variables. The optimal adaptation thresholds corresponding to the combination of different task type features and agent capability dimensions are learned. For example, in data processing tasks, the adaptation success rate is high when the agent's GPU computing power evolution value is not lower than a preset value (e.g., 0.7) and the data read / write rate evolution value is not lower than a preset value (e.g., 0.65). Finally, a type-capability adaptation mapping rule set of "task type-agent capability dimension-adaptation threshold-adaptation weight" is generated. Each rule contains a specific task type, key capability dimension, adaptation threshold of that dimension, and rule effective weight (determined based on the number of historical matching samples and accuracy, with a value range of 0-1).

[0060] Preferably, the type-capability adaptation mapping rule set is embedded into the attention weight learning stage of the dynamic capability evolution network to optimize the learning accuracy of the agent's dynamic capability features. Specifically, a rule adaptation module is added to the attention mechanism layer of the dynamic capability evolution network. This module receives the type features of the atomic task, queries the type-capability adaptation mapping rule set, and obtains the key capability dimensions and adaptation weights corresponding to the task type. The adaptation weights of the key capability dimensions are used as the initial prior values ​​of the attention weights and integrated into the calculation process of the attention weights. This allows the network to prioritize the key capability dimensions specified by the rules when learning the adaptation weights for different task types. For example, when processing data processing tasks, the network assigns higher initial attention weights to features related to the agent's GPU computing power and data read / write speed, and then fine-tunes the weights based on semantic relevance. In this way, the agent's dynamic capability features output by the dynamic capability evolution network are more in line with the adaptation requirements of the current task type, improving the targeting and effectiveness of the features.

[0061] Preferably, the type-capability adaptation mapping rule set is embedded in the threshold correction stage of the load prediction feedback loop to optimize the adaptability of the dynamic load threshold. Specifically, a rule matching unit is added to the threshold correction module of the load prediction feedback loop. This unit receives the type characteristics of the atomic task to be assigned and the capability evolution characteristics of the agent, matches the type-capability adaptation mapping rule set, and obtains the corresponding capability dimension adaptation threshold and rule effectiveness weight. The capability dimension adaptation threshold is compared with the agent's current capability evolution value to calculate the capability adaptation deviation. If the deviation is small (e.g., below a preset value (e.g., 0.1)), it indicates that the agent's capability is adapted to the task type, and the load threshold can be appropriately increased (e.g., increased by a preset ratio (e.g., 10%)) to make full use of resources. If the deviation is large (e.g., above a preset value (e.g., 0.2)), it indicates that the agent's capability is only barely adapted, and the load threshold needs to be reduced (e.g., reduced by a preset ratio (e.g., 15%)) to reserve redundant resources. The rule effectiveness weight is used to adjust the threshold correction magnitude. The higher the weight, the greater the correction magnitude, ensuring that the threshold correction conforms to the type-capability adaptation rule and adapts to the actual capability state of the agent.

[0062] Preferably, the dynamic capability evolution network with embedded rules, the load prediction feedback loop, and the type-capability adaptation mapping rule set are integrated and fused to construct a task-agent adaptation model. Specifically, the fusion process is achieved by constructing a unified model input-output interface. The model input consists of atomic task features (type, resource requirements, priority), the agent's real-time resource state tensor, and the agent's historical running data. The input data is first fed into the dynamic capability evolution network and the load prediction feedback loop, respectively. The dynamic capability evolution network outputs the agent's dynamic capability matching score for the current task type, and the load prediction feedback loop outputs the agent's future load. The predicted value and dynamic load threshold are used to verify and weight the two output results of the type-capability adaptation mapping rule set. If the dynamic capability matching score is higher than the rule adaptation threshold and the predicted load value is lower than the dynamic load threshold, the candidate priority of the agent is increased. Finally, the dynamic capability matching score, load balancing coefficient (calculated based on the predicted load value and dynamic load threshold), and rule adaptation weight are weighted and fused to output the agent-task adaptation score, forming a complete task-agent adaptation model. This model can simultaneously take into account capability adaptability, load rationality, and scenario adaptation rules, thereby improving the overall effect of task-agent matching.

[0063] Optionally, step 32 includes: step 321, extracting type features and labeling priority weights for atomic tasks in the task priority sequence with resource constraints, querying the task type adaptation rule base to obtain the agent capability adaptation dimension and threshold corresponding to the type, so as to generate a task feature vector with weights and adaptation constraints; step 322, inputting the task feature vector with weights and adaptation constraints into the dynamic capability evolution network, performing association calculation with the agent dynamic capability features stored in the network, and generating an agent-task dynamic matching matrix containing temporal adaptation coefficients; step 323, calling the task type adaptation rule base, performing adaptation threshold verification on the agent-task dynamic matching matrix, eliminating agents that do not meet the type adaptation rules, and filtering agents that meet the temporal adaptation coefficient criteria, so as to generate a candidate set of capability-matching agents.

[0064] Preferably, the specific implementation process of step 321 is as follows: For each atomic task in the resource-constrained task priority sequence, feature deconstruction and constraint fusion processing are performed to generate a task feature vector with weights and adaptation constraints. Specifically, firstly, the type features of the atomic tasks are extracted, including task type encoding (such as data processing, venue booking, invitation sending, etc., converted into a fixed-dimensional vector using one-hot encoding), core resource requirement features (the proportion of computing power, storage, and communication requirements, divided based on the total amount of resources required for task execution), and execution complexity features (divided into low, medium, and high levels according to the number of task steps and resource consumption intensity, converted into numerical features). Then, based on the priority level labeled in the resource-constrained task priority sequence, corresponding priority weights are assigned; the higher the priority level, the greater the weight. The priority is set to high (e.g., 0.8-1.0 for high priority, 0.5-0.7 for medium priority, and 0.2-0.4 for low priority). Resource constraints (e.g., computing power limit and storage requirement threshold) are converted into feature constraints. The task type adaptation rule base is queried to obtain the agent capability adaptation dimensions corresponding to the current task type (e.g., GPU computing power and data read / write rate for data processing, and network bandwidth and interface call response speed for venue booking) and the adaptation thresholds for each dimension (determined based on historical adaptation success rates). The type features, priority weights, resource constraints, capability adaptation dimensions, and thresholds are integrated into a fixed-dimensional (e.g., 64-dimensional) vector, with each vector element corresponding to a feature or constraint parameter, generating a task feature vector with weights and adaptation constraints.

[0065] Preferably, in the specific technical implementation of step 322: the weighted and adaptation-constrained task feature vector is input into the dynamic capability evolution network, and temporal correlation calculation is performed with the agent dynamic capability features stored in the network to generate an agent-task dynamic matching matrix; specifically, the agent dynamic capability features stored in the dynamic capability evolution network include agent capability evolution trend vector, real-time resource state features, and historical adaptation preference features, which are fused into a unified agent comprehensive capability feature vector (with the same dimension as the task feature vector) through residual connections; a temporal correlation calculation module is designed, which first calculates the basic matching degree between the task feature vector and the agent comprehensive capability feature vector (based on a vector similarity algorithm), and then introduces the temporal correlation calculation module. The temporal adaptation coefficient is determined based on the degree of matching between the agent's capability evolution trend and the estimated task execution time. For example, when the agent's computing power is on the rise and the task execution time is long, the temporal adaptation coefficient is high (e.g., 0.7-0.9). When the agent's storage is on the decline and the task's storage requirement is high, the temporal adaptation coefficient is low (e.g., 0.3-0.5). The basic matching degree and the temporal adaptation coefficient are weighted and fused to obtain the final matching value. Based on the final matching values ​​of all atomic tasks and agents, an agent-task dynamic matching matrix is ​​constructed. The rows of the matrix represent atomic task identifiers, the columns represent agent identifiers, and the elements at the intersection of rows and columns are the final matching values ​​of the corresponding atomic task and agent (range 0-1).

[0066] Preferably, the specific implementation process of step 323 is as follows: The task type adaptation rule base is called to perform a two-layer threshold verification and filtering on the agent-task dynamic matching matrix to generate a candidate set of capability-matching agents. Specifically, the first layer is type adaptation rule verification, querying the key capability dimension adaptation threshold corresponding to the current atomic task type in the task type adaptation rule base, extracting matching values ​​in the agent-task dynamic matching matrix where the key capability dimension of the agent does not reach the adaptation threshold, marking them as invalid matches (set to 0), and eliminating agents whose matching values ​​are all invalid. The second layer is temporal adaptation coefficient verification, setting a temporal adaptation coefficient threshold (e.g., 0.5) to filter agents. Agents whose final matching value in the agent-task dynamic matching matrix is ​​higher than the threshold are checked against the resource constraints in the task priority sequence with resource constraints. The real-time resource status of the agents is verified to ensure that they meet the task resource requirements (e.g., whether the agent's remaining storage is not less than the task's storage requirements). Agents whose resources do not meet the requirements are eliminated. Agents that pass the double-layer verification are sorted from high to low according to their final matching value. A preset number (e.g., 3-5) of the top-ranked agents are retained for each atomic task. All candidate agents corresponding to atomic tasks are integrated to generate a candidate set of capability-matching agents that includes atomic task identifiers, candidate agent lists, matching value details, and whether the adaptation constraints are met.

[0067] Optionally, step 33 includes: Step 331, inputting the real-time load value of the agent into the load prediction feedback loop, outputting the predicted load value of the agent for a future preset time period, and calculating the load increment value after task execution by combining the resource requirement characteristics of the atomic task and the type load coefficient of the task type adaptation rule base; Step 332, calculating the load balancing coefficient of each agent based on the predicted load value, the load increment value, and the type adaptation weight of the task type adaptation rule base, wherein the load balancing coefficient is obtained by fusing the deviation rate between the predicted load value and the load threshold, the task priority weight, the agent capability redundancy, and the type adaptation weight; Step 333, sorting the candidate set of capability matching agents from high to low according to the load balancing coefficient, and assigning the top-ranked agent to each atomic task to determine the target execution agent for each atomic task.

[0068] Preferably, the specific implementation process of step 331 is as follows: The real-time load value of the agent is input into the load prediction feedback loop. Combining the resource requirement characteristics of the atomic task with the type load coefficient, the incremental value of the task execution load is calculated. Specifically, the real-time load value of the agent covers core indicators such as computing power utilization, storage utilization, and bandwidth utilization. These are input into the hierarchical time-series prediction model of the load prediction feedback loop according to resource type, outputting the predicted load value for each resource type within a preset future time period (e.g., 10 minutes, 30 minutes). The predicted load value is accompanied by a prediction reliability score (calculated based on historical prediction errors, with a value range of 0-1). The resource requirement characteristics of the atomic task are extracted, including the demand ratio, peak demand, and duration of each resource type. For example, the computing power requirement ratio of a data processing atomic task is 0.6, storage utilization, and bandwidth utilization. The peak storage demand is 10GB, lasting for 30 seconds. The task type adaptation rule base is queried to obtain the type load coefficient corresponding to the current atomic task type. The type load coefficient is determined based on the resource consumption intensity of similar tasks in history. For example, the computing power load coefficient for data processing tasks is 0.8, the storage load coefficient is 0.7, and the bandwidth load coefficient for communication transmission tasks is 0.9. Based on the predicted load value, resource demand characteristics, and type load coefficient, the load increment value for each resource type is calculated. The load increment value is the quantified value of the load increase caused to each resource type during the execution of the atomic task. For example, the computing power load increment value = computing power demand ratio × type load coefficient × (peak demand / total agent resources). Finally, the load increment values ​​of each resource type are integrated to generate a task execution load increment vector.

[0069] Preferably, in the specific technical implementation of step 332: based on the predicted load value, task execution load increment vector, type adaptation weight, and other related parameters, a designed multi-dimensional fusion model is used to calculate the agent load balancing coefficient; specifically, the calculation dimensions of this model include the predicted load deviation rate, task priority weight, agent capability redundancy, and type adaptation weight. The predicted load deviation rate is the percentage difference between the predicted load value and the dynamic load threshold for each resource type. For example, if the predicted computing power load value is 80% and the dynamic load threshold is 90%, then the computing power load deviation rate is 0.11. The smaller the deviation rate, the larger the load redundancy space. The task priority weight is extracted from the task priority sequence with resource constraints. The weight value of high-priority tasks is higher than that of medium and low priorities (e.g., high priority is set to 0.9, and medium priority is set to 0.6). (Low priority is set to 0.3); Agent capability redundancy is the percentage difference between the agent's current capability evolution value and the atomic task adaptation threshold. The larger the difference, the more sufficient the capability redundancy. For example, if the agent's GPU computing power evolution value is 0.8 and the adaptation threshold is 0.7, then the computing power capability redundancy is 0.14; The type adaptation weight is obtained from the task type adaptation rule base and determined based on the historical matching success rate (value range 0-1); The parameters of the four dimensions are normalized to the 0-1 range respectively, and weighted and summed according to a preset ratio (such as prediction load deviation rate 0.3, task priority weight 0.25, agent capability redundancy 0.25, type adaptation weight 0.2) to obtain the agent load balancing coefficient (value range 0-1). The higher the coefficient, the better the load balancing and the higher the adaptation after the agent is assigned the task.

[0070] Preferably, the specific implementation process of step 333 is as follows: Calculate the load balancing coefficient for each agent in the capability-matching agent candidate set, sort them from high to low coefficients, and assign target execution agents; specifically, first traverse all agents in the capability-matching agent candidate set, repeat the calculation process of steps 331-332 for each agent to obtain the load balancing coefficient corresponding to each agent; construct an agent-task balancing coefficient matrix, where the rows of the matrix represent atomic task identifiers, the columns represent candidate agent identifiers, and the elements at the intersection of rows and columns are the load balancing coefficients of the corresponding agents; sort the candidate agents corresponding to each atomic task from high to low load balancing coefficients to generate agents. The sorting list is used to sort agents. If the difference in load balancing coefficients among multiple agents is less than a preset threshold (e.g., 0.05), a second sort is performed based on prediction reliability scores and agent capability redundancy. The agent ranked first in the sorting list is assigned as the target execution agent for each atomic task. At the same time, it is checked whether the sum of the predicted load value and the incremental value of the task execution load of the target execution agent exceeds the dynamic load threshold. If it does, the agent ranked second in the sorting list is selected, and so on, to ensure that the agent load does not exceed the limit after allocation. Finally, a matching relationship table between atomic tasks and target execution agents is generated, which includes atomic task identifier, target agent identifier, load balancing coefficient, calculation details of each dimension, and load compliance status.

[0071] Optionally, step 4 includes: step 41, combining the subtask dependency graph and the target execution agents of each atomic task to perform initial time-series scheduling and orchestration to generate an initial scheduling scheme; step 42, performing execution conflict detection on the initial scheduling scheme to generate task conflict items; step 43, resolving and optimizing the task conflict items to generate an agent task scheduling collaborative execution scheme. Optionally, step 41 includes: step 411, determining the execution order of atomic tasks based on the subtask dependency graph to generate a task time sequence; step 412, combining the task time sequence and the target execution agents to allocate task execution time periods for each agent to generate a time period allocation table; step 413, integrating the task time sequence and the time period allocation table to generate an initial scheduling scheme.

[0072] Preferably, the specific implementation process of step 411 is as follows: Based on the dependency relationships of the subtask dependency graph and the priority of atomic tasks, the designed temporal orchestration model is used to determine the execution order of atomic tasks to generate a hierarchical task temporal sequence; specifically, the temporal orchestration model first parses the directed edge relationships of the subtask dependency graph using a topological sorting algorithm to determine the basic execution level of atomic tasks. Atomic tasks without prerequisite dependencies are assigned to the initial level, and those that depend on other atomic tasks are assigned to subsequent related levels; then, a priority weighting mechanism is introduced to prioritize atomic tasks at the same level according to their priority. Priority weights are adjusted and sorted, with higher-priority atomic tasks appearing earlier in the hierarchy (e.g., high-priority tasks are weighted at 0.8-1.0, medium-priority tasks at 0.5-0.7, and low-priority tasks at 0.2-0.4). Simultaneously, based on the dependency strength attribute of the subtask dependency graph, temporal tightness constraints are set for atomic tasks with strong dependencies (e.g., a strongly dependent subsequent task must start within a preset time (e.g., 5 seconds) after the preceding task is completed). Finally, a hierarchical task temporal sequence containing hierarchy number, atomic task identifier, execution order, and temporal constraints is generated.

[0073] Preferably, in the specific technical implementation of step 412: based on the hierarchical task time sequence and the atomic task-target execution agent matching relationship table, a designed time-slot allocation model is used to allocate task execution time slots to each agent to generate an agent time-slot allocation table; specifically, the time-slot allocation model first extracts all atomic tasks corresponding to each target execution agent, and determines the execution order of these atomic tasks by combining the hierarchical task time sequence; then, based on the estimated execution time of the atomic tasks (obtained from the atomic task attributes) and the resource reservation status of the agent (obtained from the resource prediction-dynamic reservation scheduling architecture), the theoretical start time and end time of each atomic task are calculated, for example... If the agent has no task to execute at present, the start time of the first atomic task is set to the current time, and the start time of subsequent atomic tasks is set to the end time of the previous task. A time period conflict prediction mechanism is introduced to detect the overlap of task execution time periods for the same agent. If the theoretical start time of the later task is earlier than the theoretical end time of the earlier task, the start time of the later task is postponed to the end time of the earlier task. At the same time, a preset buffer period (such as 1-3 seconds) is reserved to avoid conflicts caused by untimely resource release. Finally, an agent time period allocation table is generated, which includes agent identifier, atomic task identifier, execution time period (start time - end time), resource reservation details, and time period conflict flag.

[0074] Preferably, the specific implementation process of step 413 is as follows: The hierarchical task time sequence and agent time allocation table are structurally integrated and their execution logic verified to generate a resource-adaptive initial scheduling scheme. Specifically, the integration process organizes data according to a three-level structure of "execution level - agent - atomic task". Each execution level contains task allocation information for all agents under that level, and each agent entry is associated with the corresponding atomic task identifier, execution time period, resource requirements, and timing constraints. The execution logic verification step focuses on verifying three aspects: first, whether the execution time periods of atomic tasks conform to the sequential order of the hierarchical task time sequence; second, whether the execution time periods of the same agent... The system checks whether there are any unresolved overlaps in the execution time of the atomic tasks, and whether the resource requirements of the atomic tasks match the resource reservation details of the intelligent agents. Logical contradictions found during the verification (such as reversed time sequence or mismatched resource requirements) are marked and automatically corrected (such as adjusting the execution time and supplementing resource reservations). Finally, the verified information is integrated to generate a resource-adaptive initial scheduling scheme that includes execution level details, intelligent agent task allocation list, atomic task execution parameters (time period, resources, constraints), and verification correction records. This scheme clarifies the executing intelligent agent, specific time period, and resource guarantee conditions for each atomic task, and can be directly used as the basis for subsequent dynamic adjustments.

[0075] Optionally, step 42 includes: step 421, performing overlap detection on the task execution time periods of the same agent in the initial scheduling scheme to generate time period conflict items; step 422, performing logical detection on the execution sequence of atomic tasks with dependencies in the initial scheduling scheme to generate logical conflict items; step 423, generating task conflict items by integrating time period conflict items and logical conflict items.

[0076] Preferably, the specific implementation process of step 421 is as follows: The execution time periods of the agent tasks in the initial scheduling scheme are subjected to association detection and overlap quantification to generate a detailed list of time period conflicts; specifically, the atomic tasks in the initial scheduling scheme are grouped according to the agent identifier, with each group corresponding to all assigned tasks of one agent; the designed time period overlap detection model is adopted, which first extracts the execution time period (start time, end time) and resource requirement type (computing power, storage, communication) of each atomic task in each group, and constructs an agent-task time period resource matrix, where the rows of the matrix represent atomic task identifiers and the columns represent resource types. The element at the intersection of rows and columns represents the execution time interval of the task on the corresponding resource type. By traversing the matrix, it is detected whether there is an intersection between the execution time intervals of different atomic tasks under the same resource type. If there is an intersection, it is determined to be a time interval conflict. At the same time, the overlap duration ratio (the ratio of the overlap duration to the shorter task execution duration) is calculated, and the conflict level is divided according to the overlap duration ratio (e.g., a ratio lower than a preset ratio (e.g., 20%) is a mild conflict, and a ratio higher than a preset ratio (e.g., 50%) is a severe conflict). Finally, a time interval conflict detail item is generated, which includes the agent identifier, conflicting atomic task pair, conflicting resource type, overlapping time interval, and conflict level.

[0077] Preferably, in the specific technical implementation of step 422: based on the task timing of the subtask dependency graph and the initial scheduling scheme, a designed timing logic verification model is used to detect the execution order of dependent atomic tasks to generate a logical conflict detail; specifically, the model first extracts all atomic task pairs (previous task - subsequent task) with dependencies from the subtask dependency graph, clarifies the dependency type (strong dependency / weak dependency) and timing constraints (e.g., strong dependency requires the subsequent task to start within a preset time (e.g., 5 seconds) after the completion of the preceding task, while weak dependency has no mandatory timing requirements); then, these atomic tasks are extracted from the initial scheduling scheme. During the execution period of a task pair, the startup time of the subsequent task is checked to see if it meets the timing constraints. For example, in a strong dependency scenario, if the startup time of the subsequent task is earlier than the end time of the preceding task, or if the delay time exceeds a preset threshold (such as 10 seconds), it is determined to be a timing logic conflict. At the same time, the timing consistency on the dependency propagation path is checked. For example, if task A depends on task B, and task B depends on task C, and the startup time of task A in the initial scheduling scheme is earlier than the end time of task C, it is determined to be a transitive logic conflict. Finally, a logical conflict detail item is generated, which includes the dependency atomic task path, dependency type, timing constraints, actual execution period, and conflict reason.

[0078] Preferably, the specific implementation process of step 423 is as follows: Analyze and structurally integrate the time-segment conflict details and logical conflict details to generate a total task conflict list; specifically, first construct a conflict association matrix, where the rows and columns represent the time-segment conflict details and logical conflict details, respectively. The element at the intersection of the rows and columns indicates whether two conflicts involve the same set of atomic tasks and agents, thereby identifying related conflicts (such as a set of atomic tasks having both time-segment overlap conflicts and logical conflicts due to dependencies); for unrelated conflict items, directly retain the original information; for related conflict items, merge them and label the conflict association type. (e.g., "time period - logical association conflict"); then introduce a conflict impact weight assessment, the weight is determined based on the conflict level, the priority of the atomic tasks involved, and the scope of impact on the overall scheduling scheme (value range 0-1), the heavy conflict weight of high priority tasks is higher than the light conflict weight of low priority tasks; finally integrate all conflict information, organize it according to the structure of "conflict identifier - involved objects (agent, atomic task) - conflict type - conflict details - conflict level - impact weight", generate a task conflict summary item, this task conflict summary item clearly presents all conflicts and key attributes in the initial scheduling scheme, providing a clear basis for subsequent conflict resolution.

[0079] Optionally, step 43 includes: step 431, resolving time period overlap conflicts by reallocating execution time periods for time period conflict items; step 432, performing dependency timing calibration on logical conflict items to resolve logical execution conflicts; and step 433, performing integrity verification on the resolved scheduling scheme to generate an agent task scheduling collaborative execution scheme.

[0080] Preferably, the specific implementation process of step 431 is as follows: Based on the time period conflict details and the agent resource reservation status, the designed time period redistribution model is used to dynamically adjust the execution time of conflicting atomic tasks to generate a non-overlapping time period allocation table; specifically, the time period redistribution model first extracts the conflicting atomic task pairs, conflicting resource types, conflict levels, and corresponding agent resource reservation details from the time period conflict details, and sorts them according to the conflict level (severe conflicts are handled first); then, combined with the priority weight of the atomic tasks and the estimated execution time, a redistribution strategy is formulated: the core execution time of high-priority atomic tasks is reserved. The execution time of low-priority atomic tasks is postponed until after the conflicting resources are released, and a preset buffer period (such as 1-3 seconds) is reserved. If both conflicting parties are high-priority, the execution time of one atomic task is split based on the resource redundancy of the agent (such as splitting a long-running task into multiple short-running segments), and interspersed with the resource idle window of the other task. After reallocation, the execution time of each atomic task is recalculated, and an intelligent relocation time matrix is ​​constructed. The rows of the matrix represent atomic task identifiers, the columns represent resource types, and the elements at the intersection of rows and columns are the adjusted execution time intervals. Finally, a non-overlapping time allocation table is generated.

[0081] Preferably, in the specific technical implementation of step 432: based on the logical conflict details and the subtask dependency graph, a designed timing calibration model is used to correct the execution timing of dependent atomic tasks to generate a logically consistent timing sequence; specifically, the timing calibration model first extracts the dependent atomic task paths, dependency types, and timing constraints from the logical conflict details, and combines them with the dependency strength attribute of the subtask dependency graph (strong dependencies have higher weights than weak dependencies); for logical conflicts caused by strong dependencies, the start time of subsequent tasks is forcibly adjusted to meet the timing constraints, for example, when the preceding task ends. If the time interval is T, and a strong dependency requires the subsequent task to start within a preset time period (e.g., 5 seconds), then the start time of the subsequent task will be calibrated to T+2 seconds. For logical conflicts caused by weak dependencies, without affecting the overall scheduling cycle, the execution priority of the preceding task will be appropriately adjusted to complete it in advance, or the start time of the subsequent task will be delayed, while ensuring that the calibrated timing does not conflict with the execution time period in the non-overlapping time period allocation table. For transitive logical conflicts, calibration will be performed segment by segment from the source task according to the dependency path to ensure that the timing logic of each group of directly dependent atomic tasks is self-consistent, and finally a logically self-consistent timing sequence will be generated.

[0082] Preferably, the specific implementation process of step 433 is as follows: Integrate the non-overlapping time period allocation table and the logically consistent time sequence, and use the designed full-dimensional integrity verification model for verification and optimization to generate an agent task scheduling and collaborative execution scheme; specifically, the verification dimensions of this full-dimensional integrity verification model include temporal logical integrity, resource allocation integrity, and task coverage integrity. Temporal logical integrity verifies whether the execution sequence of all dependent atomic tasks conforms to the constraint requirements of the subtask dependency graph and has no logical contradictions; resource allocation integrity verifies whether the resource requirements of each atomic task match the resource reservation details of the agent and has no resource gaps; task The system verifies the integrity of the initial scheduling scheme to ensure that all atomic tasks are included in the resolved scheme without omissions or duplications. For issues discovered during verification (such as resource allocation mismatches or task omissions), a secondary adjustment is automatically triggered, such as supplementing agent resource reservations, retrieving missing tasks, and allocating execution time slots. After successful verification, the system organizes data according to the structure of "Agent Identifier - Atomic Task List - Execution Time Slot - Resource Configuration - Timing Constraints - Contingency Plan," generating an agent task scheduling and collaborative execution scheme that includes detailed execution process information, resource guarantee schemes, conflict resolution records, and anomaly handling mechanisms. This scheme can directly guide agents in collaboratively executing atomic tasks.

[0083] The above are merely preferred embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A task scheduling and planning method for intelligent agents, characterized in that, include: Step 1: Parse the task instructions to generate independently executable atomic tasks, in order to construct a subtask dependency graph; Step 2: Determine the real-time resource occupancy status of the agent to obtain the agent resource state tensor. Based on the agent resource state tensor and the subtask dependency graph, perform resource-task association anchoring and dependency priority sorting to generate a task priority sequence with resource constraints. Step 3: Using the task-agent adaptation model, perform dynamic capability matching and predictive load balancing calculations on the priority sequence of tasks with resource constraints to determine the target execution agent for each atomic task. Step 4: Perform time-series scheduling and conflict resolution on the target execution agents and subtask dependency graphs of each atomic task to generate an agent task scheduling and collaborative execution scheme.

2. The intelligent agent task scheduling and planning method according to claim 1, characterized in that, Step 1 includes: Step 11: Semantically deconstruct the task instructions and extract core requirements to generate a set of core task elements; Step 12: Perform granular decomposition and independent execution determination on the core elements set of the task to generate independently executable atomic tasks; Step 13: Perform execution logic association analysis and dependency modeling on atomic tasks to construct a subtask dependency graph.

3. The intelligent agent task scheduling and planning method according to claim 1, characterized in that, Step 2 includes: Step 21: Monitor the computing power, storage, and communication links of each agent in real time to generate agent resource monitoring data; Step 22: Perform tensor modeling on the agent resource monitoring data to obtain the agent resource state tensor; Step 23: Based on the agent's resource state tensor and subtask dependency graph, perform resource-task association anchoring to generate a resource-adapted task set; Step 24: Sort the resource adaptation task set by dependency priority to generate a task priority sequence with resource constraints.

4. The intelligent agent task scheduling and planning method according to claim 1, characterized in that, Step 3 includes: Step 31: Construct a task-agent adaptation model, which is obtained by integrating a dynamic capability evolution network, a load prediction feedback loop, and a task type adaptation rule base. Step 32: Input the task priority sequence with resource constraints and the agent resource state tensor into the task-agent adaptation model, output the agent-task dynamic matching matrix through the dynamic capability evolution network, and perform matching verification in combination with the task type adaptation rule base to determine the candidate set of capability matching agents. Step 33: Based on the agent's predicted load value output by the load prediction feedback loop, integrate the type weights of the task type adaptation rule base, perform dynamic load balancing calculation on the candidate set of capability-matching agents, and select the target execution agent for each atomic task.

5. The intelligent agent task scheduling and planning method according to claim 4, characterized in that, Step 31 includes: Step 311: Collect historical task execution data, real-time resource state tensor and task type adaptation records of each agent, extract the temporal features of the historical task execution data to obtain the capability evolution trend vector, perform residual fusion with the real-time resource state tensor, and then learn the adaptation weights of different task types through the attention mechanism to generate a dynamic capability evolution network.

6. The intelligent agent task scheduling and planning method according to claim 4, characterized in that, Step 32 includes: Step 321: Extract type features and label priority weights for atomic tasks in the task priority sequence with resource constraints, query the task type adaptation rule base to obtain the agent capability adaptation dimension and threshold corresponding to the type, so as to generate a task feature vector with weights and adaptation constraints. Step 322: Input the weighted and adaptation-constrained task feature vector into the dynamic capability evolution network, and perform correlation calculation with the agent dynamic capability features stored in the network to generate an agent-task dynamic matching matrix containing temporal adaptation coefficients. Step 323: Call the task type adaptation rule library to perform adaptation threshold verification on the agent-task dynamic matching matrix, remove agents that do not meet the type adaptation rules, and filter agents with qualified temporal adaptation coefficients to generate a candidate set of capability-matching agents.

7. The intelligent agent task scheduling and planning method according to claim 4, characterized in that, Step 33 includes: Step 331: Input the real-time load value of the agent into the load prediction feedback loop, output the predicted load value of the agent for the future preset time period, and calculate the load increment value after the task is executed by combining the resource requirement characteristics of the atomic task and the type load coefficient of the task type adaptation rule base. Step 332: Based on the predicted load value, the load increment value, and the type adaptation weight of the task type adaptation rule base, calculate the load balancing coefficient of each agent. The load balancing coefficient is obtained by fusing the deviation rate between the predicted load value and the load threshold, the task priority weight, the agent capability redundancy, and the type adaptation weight. Step 333: Sort the candidate set of capability-matching agents from high to low according to the load balancing coefficient, and assign the first-ranked agent to each atomic task to determine the target execution agent for each atomic task.

8. The intelligent agent task scheduling and planning method according to claim 1, characterized in that, Step 4 includes: Step 41: Combine the subtask dependency graph with the target execution agent of each atomic task to perform initial timing scheduling and orchestration to generate an initial scheduling scheme; Step 42: Perform conflict detection on the initial scheduling scheme to generate task conflict items; Step 43: Optimize and resolve task conflicts to generate a collaborative execution scheme for agent task scheduling.

9. The intelligent agent task scheduling and planning method according to claim 8, characterized in that, Step 41 includes: Step 411: Determine the execution order of atomic tasks based on the subtask dependency graph to generate a task time sequence; Step 412: Combine the task time sequence with the target execution agent to allocate task execution time periods for each agent, so as to generate a time period allocation table; Step 413: Integrate the task time sequence and time period allocation table to generate an initial scheduling scheme.

10. The intelligent agent task scheduling and planning method according to claim 8, characterized in that, Step 42 includes: Step 421: Perform overlap detection on the task execution time periods of the same agent in the initial scheduling scheme to generate time period conflict items; Step 422: Perform logical checks on the execution sequence of atomic tasks with dependencies in the initial scheduling scheme to generate logical conflict items; Step 423: Generate task conflict items by integrating time period conflict items and logical conflict items.

Images