Task arrangement method and system in skill training platform and storage medium

Abstract

The invention provides a task arrangement method and system in a skill training platform and a storage medium, and the method comprises the steps: determining a to-be-processed target data object in the skill training platform, and the target data object comprises logic dependency relationship data and a deadline timestamp; based on the logic dependency relationship data and the deadline timestamp, constructing a reverse directed acyclic graph taking the deadline timestamp as a root node; obtaining a historical execution efficiency coefficient associated with each graph node in the reverse directed acyclic graph; performing weighted calculation on each graph node in the reverse directed acyclic graph by using the historical execution efficiency coefficient to obtain a scheduling priority weight of each graph node; and according to the scheduling priority weight, performing time sequence mapping on each graph node in the reverse directed acyclic graph to generate an atomic execution unit sequence. The task arrangement in the skill training platform can be more reasonable, and the phenomenon of time window overflow can be effectively reduced, so that the on-time delivery of the macroscopic target in the skill training platform can be ensured.

Description

Technical Field

[0001] This application relates to the field of skills training technology, specifically to a task arrangement method, system, and storage medium in a skills training platform. Background Technology

[0002] In skills training platforms, it is often necessary to automatically decompose and schedule macro-level objectives. To ensure the orderliness of data processing and timely delivery, a task orchestration management system is generally used. This system aims to transform large-scale engineering objectives into specific instruction sequences that can be recognized by the execution end, and monitor the execution progress according to a preset time window to maintain the integrity of business logic and operational efficiency.

[0003] In related technologies, task orchestration schemes can utilize average allocation algorithms to map subtasks one by one onto the timeline. However, this approach is overly idealistic and prone to time window overflow, causing macro-level objectives to fail to be delivered on schedule. It is evident that current task orchestration methods are often insufficiently rational. Summary of the Invention

[0004] Embodiments of this application provide a task orchestration method, system, and storage medium for a skills training platform, aiming to make task orchestration in the skills training platform more reasonable, reduce time window overflow, and ensure the timely delivery of macro-level goals in the skills training platform.

[0005] In a first aspect, embodiments of this application provide a task scheduling method in a skills training platform, the task scheduling method in the skills training platform comprising:

[0006] Identify the target data object to be processed in the skills training platform, wherein the target data object includes logical dependency data and deadline timestamp;

[0007] Based on the logical dependency data and the deadline timestamp, a reverse directed acyclic graph is constructed with the deadline timestamp as the root node;

[0008] Obtain the historical execution performance coefficients associated with each graph node in the reverse directed acyclic graph;

[0009] Using the historical execution efficiency coefficients, a weighted calculation is performed on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node;

[0010] According to the scheduling priority weight, the nodes of each graph in the reverse directed acyclic graph are time-series mapped to generate the atomic execution unit sequence in the skills training platform.

[0011] In the above embodiments, a reverse directed acyclic graph rooted at the deadline timestamp is constructed, establishing an end-to-end orchestration benchmark. Scheduling priority weights are obtained by weighting each graph node using historical execution performance coefficients, quantifying past execution performance and integrating it into the scheduling strategy. This allows graph nodes with higher execution risks to obtain more reasonable temporal positions. This temporal mapping method, combining reverse logic and dynamic weights, improves the executability of atomic execution unit sequences in the skills training platform, making task orchestration more rational and effectively reducing time window overflow, thus ensuring the timely delivery of macro-level goals in the skills training platform.

[0012] In one embodiment, constructing a reverse directed acyclic graph with the deadline timestamp as the root node based on the logical dependency data and the deadline timestamp includes:

[0013] Generate a graph structure with the stated deadline timestamp as the endpoint vertex;

[0014] Based on the logical dependency data, the predecessor data node pointing to the endpoint vertex is determined;

[0015] Generate a directed edge from the predecessor data node to the endpoint vertex;

[0016] The reverse directed acyclic graph is generated using a graph structure that includes the endpoint vertex, the predecessor data node, and the directed edges.

[0017] In the above embodiments, by determining logical dependency data and deadline timestamps, a reverse directed acyclic graph with the deadline timestamp as the root node is constructed. This method of constructing a reverse topology transforms the forward task flow into a reverse constraint model starting from the final delivery target. It clarifies the subsequent dependencies and endpoint distances of each graph node on the logical link, providing a clear topological foundation for accurately calculating the reverse order of each task node relative to the hard deadline, and establishing a normalized benchmark for task orchestration.

[0018] In one embodiment, the step of using the historical execution performance coefficients to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node includes:

[0019] Based on the historical execution efficiency coefficients corresponding to each graph node in the reverse directed acyclic graph, the execution resistance factor corresponding to each graph node is determined.

[0020] Determine the task importance parameters and execution time urgency parameters for each of the graph nodes;

[0021] Based on the task importance parameter, the execution time urgency parameter, and the execution resistance factor, the scheduling priority weight of the corresponding graph node is determined.

[0022] In the above embodiments, by obtaining the topology level depth and combining it with historical execution efficiency coefficients to determine execution impact factors, the scheduling priority weight of each graph node is quantitatively calculated. By comprehensively considering the task's positional attributes and historical execution performance within the topology, critical nodes located at deeper levels and with lower historical execution efficiency receive higher weights. This allows for priority processing of tasks with higher potential risks or longer delivery dates during resource allocation, optimizing the overall orchestration order logic and preventing task backlog on critical paths.

[0023] In one embodiment, after performing time-series mapping on each graph node in the reverse directed acyclic graph according to the scheduling priority weights to generate the atomic execution unit sequence in the skills training platform, the method further includes:

[0024] Receive execution delay status feedback instructions for the target atomic execution unit in the atomic execution unit sequence;

[0025] In the reverse directed acyclic graph, downstream association graph nodes with the target atomic execution unit as a predecessor dependency are determined;

[0026] Update the execution time urgency parameter of the downstream related graph node;

[0027] Return to the step of determining the scheduling priority weight of the corresponding graph node based on the task importance parameter, the execution time urgency parameter, and the execution resistance factor.

[0028] In the above embodiments, the actual delay duration of the atomic execution unit is obtained, and the execution time urgency parameters of downstream related graph nodes are updated accordingly. This dynamic feedback mechanism can capture deviations in real time during task execution and accurately transmit the impact of upstream delays to subsequent dependent nodes, instantly increasing the urgency of subsequent tasks. This ensures that the orchestration scheme can dynamically respond along with the execution progress, preventing a chain reaction of time window overflows caused by undetected single-point delays.

[0029] In one embodiment, after generating the atomic execution unit sequence in the skills training platform, the method further includes:

[0030] Obtain the actual execution time data for the completed atomic execution units in the atomic execution unit sequence;

[0031] Based on the actual execution time data, the historical execution efficiency coefficients of the corresponding graph nodes in the reverse directed acyclic graph are updated;

[0032] Return to the step of using the historical execution performance coefficient to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node.

[0033] In the above embodiments, historical execution efficiency coefficients are updated based on actual execution duration data, establishing a data-driven model iteration mechanism. This enables the system to use the latest execution results to correct the evaluation of the processing capabilities of each graph node, ensuring that historical execution efficiency coefficients always reflect the current true efficiency level. By continuously reducing the deviation between estimated parameters and actual capabilities, the accuracy of priority calculation and duration estimation in subsequent task orchestration is improved, achieving adaptive evolution of the scheduling model.

[0034] In one embodiment, updating the historical execution performance coefficients of the corresponding graph nodes in the reverse directed acyclic graph based on the actual execution time data includes:

[0035] Obtain the estimated execution time data of the corresponding graph nodes in the reverse directed acyclic graph;

[0036] Determine the execution time deviation between the actual execution time data and the estimated execution time data;

[0037] Based on a preset historical weight decay factor, the historical execution efficiency coefficient and the execution time deviation are weighted and summed to obtain the updated historical execution efficiency coefficient.

[0038] In the above embodiments, a preset historical weight decay factor is used to perform a weighted summation of the historical execution performance coefficients and execution time deviations. While incorporating the latest execution data, the decay factor retains the reference weights of historical experience, achieving smooth coefficient updates. This effectively prevents drastic fluctuations in performance coefficients due to isolated execution anomalies, ensuring the stability and robustness of model parameter updates, thereby maintaining the consistency of task orchestration benchmarks.

[0039] In one embodiment, the step of performing time-series mapping on each graph node in the reverse directed acyclic graph according to the scheduling priority weight to generate the atomic execution unit sequence in the skills training platform includes:

[0040] Based on the scheduling priority weights, the nodes in the reverse directed acyclic graph are sorted to obtain an ordered list of nodes;

[0041] Obtain available time window data for deploying tasks;

[0042] Based on the historical execution performance coefficients, a safe buffer time interval is determined for the cutoff timestamp;

[0043] Starting from the point in time from the cutoff timestamp minus the safety buffer time interval, the graph nodes in the ordered node list are sequentially filled into the available time window data to obtain the atomic execution unit sequence.

[0044] In the above embodiment, an ordered list of nodes is generated according to scheduling priority weights, and then filled in reverse based on a safety buffer time interval to generate a sequence of atomic execution units. This enforces the priority placement of high-priority tasks on the physical timeline, and utilizes a reverse inverted scheduling strategy to arrange all tasks close to the safety boundary before the deadline, maximizing the release of idle time in the early stages of the project. Combined with the safety buffer mechanism, this solution enhances the resilience to cope with sudden interference while ensuring on-time delivery.

[0045] In one embodiment, determining the safety buffer time interval for the deadline timestamp based on the historical execution performance coefficient includes:

[0046] The execution risk multiplier factor of the graph node is determined by using the historical execution efficiency coefficient of each graph node in the reverse directed acyclic graph.

[0047] Based on the execution risk multiplier factor and estimated execution time data of the graph nodes, the safety buffer time of the graph nodes is determined;

[0048] The safety buffer time interval is determined based on the safety buffer time of all graph nodes in the reverse directed acyclic graph.

[0049] In the above embodiments, by determining the execution risk multiplier factor of graph nodes and calculating personalized safety buffer times and total intervals accordingly, dynamic resource reservation based on risk probability is achieved. While providing sufficient fault tolerance for high-risk nodes, it avoids resource waste caused by over-protection of low-risk nodes, thereby maximizing the effective utilization of available time windows by finely buffering execution uncertainties.

[0050] Secondly, embodiments of this application provide a task orchestration system in a skills training platform, the task orchestration system in the skills training platform being used to execute the task orchestration method in the skills training platform as described in any of the preceding claims.

[0051] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program configured to be executed by a processor to implement the task orchestration method in the skills training platform as described in any of the preceding claims.

[0052] The beneficial effects of the embodiments of this application are as follows:

[0053] In the embodiments of this application, a reverse directed acyclic graph with the deadline timestamp as the root node is constructed, establishing an orchestration benchmark starting from the end point. The scheduling priority weight is obtained by weighting each graph node using historical execution performance coefficients, quantifying past execution performance and integrating it into the scheduling strategy. This allows graph nodes with higher execution risks to obtain more reasonable temporal positions. This temporal mapping method, combining reverse logic and dynamic weights, improves the executability of atomic execution unit sequences, making task orchestration in the skills training platform more reasonable and effectively reducing time window overflow, thus ensuring the timely delivery of macro-level goals in the skills training platform. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a schematic flowchart of an embodiment of the task orchestration method in the skills training platform provided in this application. Detailed Implementation

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. In addition, in the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0057] In a first aspect, embodiments of this application provide a task orchestration method in a skills training platform, wherein the executing entity is a task orchestration system (hereinafter referred to as "the system") in the skills training platform.

[0058] Specifically, refer to Figure 1 The task arrangement methods in the skills training platform may include:

[0059] S101. Determine the target data object to be processed in the skills training platform. The target data object includes logical dependency data and deadline timestamp.

[0060] In this embodiment, the skills training platform refers to a computer software system that provides skills training functions such as online programming practice, virtual simulation operation, and vocational skills assessment. The target data object to be processed in the skills training platform refers to complex engineering plans, long-term project goals, or macro-level business plans stored in the platform in structured data form. This data object is typically an abstract, coarse-grained collection in its initial state and requires discretization through computational methods. Logical dependency data is used to define the pre- and post-constraints between the sub-items within the data object. For example, task node A must be completed before task node B starts; this logical constraint forms the basis of the topology. The data format can be encapsulated using JavaScript Object Notation (JSON) or Extensible Markup Language (XML), containing a unique task identifier, descriptive information, and a list of dependencies. The deadline timestamp is a numerical representation of the rigid time node that the target data object must complete, typically stored in a standard date and time format. The process of identifying target data objects is essentially the process of transforming unstructured business requirements into a standardized data input stream that can be recognized and computed by computers, providing boundary constraints for subsequent graph computation.

[0061] S102. Based on logical dependency data and deadline timestamps, construct a reverse directed acyclic graph with the deadline timestamp as the root node;

[0062] In this embodiment, the reversed Directed Acyclic Graph (DAG) is a specific non-linear data structure. Unlike the forward scheduling logic which starts from the "current time," this step employs a "starting from the end" reverse engineering logic. Specifically, the system maps the deadline timestamp to the root or sink node of the graph structure, and extends branch nodes at all levels in reverse based on the pre-constraints in the logical dependency data. Each directed edge points to the next level of dependent node, ultimately converging to the deadline timestamp. The construction process can be executed using a high-performance graph computing engine, such as a graph algorithm library developed based on the Rust language, to ensure construction efficiency under large-scale node data. By constructing the reversed DAG, the system forcibly locks the delivery endpoint at the logical level, and the computation of all paths is subject to the hard constraint of the deadline timestamp, thereby avoiding the time divergence problem commonly found in forward derivation.

[0063] S103. Obtain the historical execution performance coefficients associated with each graph node in the reverse directed acyclic graph;

[0064] In this embodiment, each graph node represents a discretized subtask or execution stage. The historical execution efficiency coefficient is a numerical indicator obtained by quantifying the behavioral characteristics of the execution end in similar past tasks. This coefficient reflects the degree of deviation between actual execution efficiency and theoretical expectations.

[0065] In some embodiments of this application, the system reads historical logs stored in the database, compares the "estimated execution time" and "actual execution time" of historical tasks, and calculates the historical execution efficiency coefficient using statistical algorithms. For example, if historical data shows that the average delay rate of a certain type of node is 20%, the historical execution efficiency coefficient can be set to 1.2; if the execution efficiency is high, the historical execution efficiency coefficient can be less than 1.0. The significance of obtaining this coefficient lies in combining objective engineering logic with the nonlinear characteristics of the execution subject, enabling static topology planning to adapt to dynamic execution environments.

[0066] S104. Using historical execution efficiency coefficients, perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node.

[0067] In this embodiment, weighted calculation refers to the process of correcting the original attributes (such as importance and theoretical execution time) of graph nodes using historical execution performance coefficients. The scheduling priority weight no longer depends solely on the logical order of tasks, but rather incorporates a comprehensive score that integrates execution risk.

[0068] In some embodiments of this application, the calculation formula may take the form of multi-factor product or weighted summation, for example: scheduling priority weight of a graph node = logical priority × (1 / (1-historical execution efficiency coefficient)). Through this calculation, for graph nodes with low historical execution efficiency (i.e., prone to delays or blockages), the system will automatically assign them higher scheduling weights or allocate more lenient time buffers, allowing them to be pre-processed in the orchestration sequence or have more resources reserved. This step realizes the transformation from an "idealized mathematical model" to a "realistic robustness model," reducing the uncertainty risk during execution through a pre-compensation mechanism.

[0069] S105. According to the scheduling priority weight, perform time-series mapping on each graph node in the reverse directed acyclic graph to generate the atomic execution unit sequence in the skills training platform.

[0070] In this embodiment, time-series mapping refers to the process of mapping topological nodes without time attributes to specific calendar time windows or processor time slices. The atomic execution unit sequence is the final generated ordered list of instructions that can be directly read and manipulated by the execution end. An atomic execution unit refers to the smallest indivisible task entity, such as a specific work item for a single day, thereby enabling the orchestration of tasks in the skills training platform. The generation process follows a reverse-engineering principle: starting from the deadline timestamp, deducting the weighted estimated execution time (including buffer) of each graph node, the "latest start time" of each node is determined.

[0071] In some embodiments of this application, the system sorts nodes at the same level according to scheduling priority weights, with nodes having higher weights occupying more favorable time windows first. The final generated sequence not only satisfies the rigid constraints of logical dependencies but also incorporates a flexible buffer based on performance coefficients, ensuring the executability of the plan and the on-time delivery rate.

[0072] As can be seen, the embodiments of this application achieve result-oriented rigid constraint scheduling by constructing a reverse topology model with the deadline as the anchor point. Combined with the weighted calculation of historical execution efficiency coefficients, the system can automatically identify and compensate for nonlinear deviations in the execution process, transforming potential delay risks into pre-set time buffers. This effectively solves the technical problem of error accumulation leading to end-time time window overflow in forward scheduling, and improves the robustness and on-time delivery rate of complex engineering task orchestration in the skills training platform.

[0073] In some embodiments of this application, a reverse directed acyclic graph is constructed based on logical dependency data and deadline timestamps, with the deadline timestamp as the root node, including:

[0074] S201. Generate a graph structure with the end timestamp as the endpoint vertex;

[0075] In this embodiment, the graph structure is a logical container for storing node and edge information, typically initialized in computer memory as an adjacency list or adjacency matrix. The endpoint vertex is the sink node in the graph structure with zero out-degree and a non-zero in-degree; logically, it represents the final state of the overall task completion. During initialization, the system parses the deadline timestamp into the core attribute value of the endpoint vertex.

[0076] In some embodiments of this application, the system first allocates a memory region as the storage space for the graph structure and instantiates the deadline timestamp object as a unique root node, assigning it a globally unique index identifier (ID). This step establishes the geometric anchor point for reverse topology analysis, and all subsequent path planning will converge at this point, ensuring the consistency of the baseline for reverse tracing.

[0077] S202. Based on the logical dependency data, determine the predecessor data node pointing to the endpoint vertex;

[0078] In this embodiment, a predecessor data node refers to a directly upstream task unit that must logically precede the endpoint vertex in terms of timing. Logical dependency data records the parent-child relationships or pre- and post-constraints between tasks. The system identifies data items that directly identify the endpoint vertex's task ID as a "successor" or "parent task" by traversing the target's dependency list. For example, if project delivery (the endpoint) depends on module integration testing, then module integration testing is the predecessor data node of that endpoint vertex. This process is typically implemented using a recursive algorithm or an iterative query algorithm.

[0079] S203. Generate a directed edge from the predecessor data node to the end vertex;

[0080] In the embodiments of this application, a directed edge refers to a logical pointer connecting two vertices, used to represent the irreversible execution order and data flow direction. In the context of reverse construction, the definition of the direction of a directed edge has special characteristics: although the passage of physical time is from the predecessor to the destination, in the deductive path of topology analysis, the edge usually represents the direction of constraint transmission.

[0081] S204. Using a graph structure that includes endpoint vertices, predecessor data nodes, and directed edges, generate a reverse directed acyclic graph.

[0082] In this embodiment, generating a reverse directed acyclic graph (DAG) refers to assembling the discrete vertices and edges into a complete, connected, and loop-free graph model. The system recursively executes steps S202 and S203, where each newly determined predecessor data node is used as a temporary "endpoint" for the next iteration, continuing to search for its next-level predecessor node until all task chains backtrack to a starting node without any predecessor dependencies. During the assembly process, the system runs a loop detection algorithm (such as the coloring method in Depth-First Search (DFS)) in real time to ensure that the generated graph structure does not contain any logical deadlock cycles. The final generated DAG completely maps all causal paths from the final delivery date back to the current time.

[0083] As can be seen, this embodiment constructs a graph model through recursive backtracking, ensuring that all task nodes strictly adhere to logical dependencies and are anchored to the time endpoint. Explicit directed edges connect predecessor and sink nodes, transforming complex hierarchical constraints into a computationally friendly topology. Furthermore, real-time loop detection during construction ensures the logical rationality of the data model, providing a precise and robust data structure foundation for subsequent efficient path-based weight calculation and time-series arrangement.

[0084] In some embodiments of this application, historical execution performance coefficients are used to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node, including:

[0085] S301. Based on the historical execution efficiency coefficients corresponding to each graph node in the reverse directed acyclic graph, determine the execution resistance factor corresponding to each graph node.

[0086] In this embodiment, the execution resistance factor is a scalar parameter that maps historical behavior data to a physical scheduling model, characterizing the inertia of a graph node as it moves or is processed along the time axis. While historical execution efficiency coefficients reflect past delay rates or efficiency ratios, directly using them for ranking may lack dimensional consistency. Therefore, they need to be standardized as the execution resistance factor.

[0087] In some embodiments of this application, the system employs a nonlinear mapping function for transformation, such as using an exponential function to amplify the historical coefficients of high delay rates, thereby giving extremely high resistance values ​​to nodes that were historically prone to delay or difficult to execute. The physical meaning of this factor is that nodes with greater resistance are more difficult to "compress" or "move" in the scheduling algorithm, thus requiring the system to assign them more stable time anchors to prevent them from deviating from their predetermined paths due to minor disturbances.

[0088] S302. Determine the task importance parameters and execution time urgency parameters for each graph node;

[0089] In this embodiment, the task importance parameter is a static attribute value that identifies the coreness of a graph node within the overall target data object. This task importance parameter is typically defined by metadata; for example, nodes labeled as "critical milestones" have the highest numerical level, while "auxiliary tasks" have lower levels. The execution time urgency parameter is a dynamic attribute value calculated based on the topology of the inverse directed acyclic graph. It is the reciprocal of the time difference between the node's latest start time and the current system time.

[0090] S303. Based on the task importance parameter, execution time urgency parameter, and execution resistance factor, determine the scheduling priority weight of the corresponding graph node.

[0091] In this embodiment, the scheduling priority weight is the final composite index used to determine the generation order of atomic execution units. The process of determining this weight is essentially a multi-dimensional feature fusion decision-making process. The system uses a preset fusion algorithm to weight and synthesize the task importance parameter representing business value, the execution time urgency parameter representing time constraints, and the execution resistance factor representing execution risk.

[0092] In some embodiments of this application, a product aggregation model is adopted: scheduling priority weight = task importance parameter × execution time urgency parameter × execution resistance factor. This means that even non-urgent tasks, if their resistance is extremely high (highly likely to be delayed) and their importance is high, will have their weight increased, thus being prioritized. Through this three-dimensional weighting, a resource preemptive scheduling method that is more in line with engineering practice is achieved.

[0093] As can be seen, this application's embodiments construct a comprehensive, multi-factor evaluation system by introducing parameters across three dimensions: execution resistance factor, task importance, and time urgency. This system not only considers objective deadlines but also takes into account the commercial value of the task itself and the historical behavioral inertia of the execution end. The weights calculated by the system accurately identify key nodes that are "important, urgent, and difficult to overcome procrastination habits," and prioritize resource allocation for them, thereby achieving optimal risk control and performance balance in complex concurrent tasks.

[0094] In some embodiments of this application, after performing time-series mapping on each graph node in the inverse directed acyclic graph according to scheduling priority weights to generate the atomic execution unit sequence in the skills training platform, the method further includes:

[0095] S401, Receive execution delay status feedback instruction for the target atomic execution unit in the atomic execution unit sequence;

[0096] In this embodiment, the execution delay status feedback instruction refers to a control signal triggered by the execution end that indicates a specific task has not been completed within a predetermined time window or requests a postponement of execution. The target atomic execution unit is the specific task item in the atomic execution unit sequence that has experienced an abnormal state. This instruction can be received passively by the system through an application programming interface (API), such as clicking a "postpone" button, or it can be a timeout interrupt signal actively generated by the system's background monitoring process when it detects that the current time has exceeded the preset end timestamp of the unit. This step establishes a real-time perception channel between the system and the actual execution state, enabling the static orchestration sequence to respond to dynamic external disturbances.

[0097] S402. In the reverse directed acyclic graph, determine the downstream association graph nodes with the target atomic execution unit as the predecessor dependency.

[0098] In the embodiments of this application, downstream related graph nodes refer to other graph nodes that are logically directly or indirectly dependent on the target atomic execution unit. In the topology of the reverse directed acyclic graph, these nodes are located after the logical path of the target atomic execution unit (i.e., above the reverse tracing path pointing to the target node, or pointed to by the target node in the forward logic).

[0099] S403, Update the execution time urgency parameter of downstream related graph nodes;

[0100] In this embodiment, updating the execution time urgency parameter of the downstream association graph node refers to recalculating the parameters of the downstream node based on the duration of the delay. Due to the delay of the predecessor task, the available time window of the downstream association graph is compressed.

[0101] In some embodiments of this application, the system deducts the actual delay of the target atomic execution unit from the original remaining safe time of the downstream correlation graph node, and recalculates the execution time urgency parameter based on the deducted value (usually, urgency is inversely proportional to the remaining time). If the remaining time is negative, this parameter will be set to an extreme warning state. This step transforms the passage of physical time into a change in mathematical parameters, quantifying the urgent pressure on the downstream caused by upstream default.

[0102] In this embodiment, the update logic for the execution time urgency parameter is calculated using a nonlinear mapping function to amplify the urgency level under critical conditions. The specific data processing logic is as follows: First, the system calculates the remaining safe buffer time for downstream nodes affected by delays. The calculation formula is: Remaining safe buffer time = Original deadline - Current system time - Necessary execution time - Accumulated upstream delay time. Subsequently, the system introduces a preset urgency threshold constant (e.g., 30 minutes) and constructs a normalized mapping model using the arctangent function or an exponential function.

[0103] In a further embodiment of this application, the execution time urgency parameter is updated using the following formula: Execution Time Urgency Parameter = α / (Remaining Safety Buffer Time + ε), where α is a time sensitivity coefficient (e.g., set to 100), and ε is a small constant (e.g., 0.01) to prevent the denominator from being zero. If the calculated remaining safety buffer time is less than or equal to zero, the system directly sets the execution time urgency parameter to the preset maximum value allowed by the system and triggers a forced top-level flag. This calculation logic ensures that when the remaining buffer time decreases sharply, the urgency parameter increases sharply in a hyperbolic manner, thereby overriding other parameters such as task importance in subsequent weighted calculations, forcing the scheduling algorithm to prioritize the node on the verge of default.

[0104] S404. Return to the step of determining the scheduling priority weight of the corresponding graph node based on the task importance parameter, execution time urgency parameter, and execution resistance factor.

[0105] In this embodiment, this is a trigger action of closed-loop feedback control logic. After updating the execution time urgency parameter, the system no longer uses the old sequence but instead redetermines the scheduling priority weights of the corresponding graph nodes. This means that as the execution time urgency parameter increases, the combined scheduling priority weights of downstream nodes that were originally lower priority will instantly increase. The system then reorders and remaps the timing according to the new weights, dynamically generating a corrected sequence of atomic execution units. Through this recursive call, the system achieves dynamic reconstruction of the plan, ensuring that in the event of a sudden delay, the optimal path can be replanned immediately, rather than rigidly executing an invalid solution.

[0106] As can be seen, the embodiments of this application construct a dynamic closed-loop task adaptive adjustment logic. By capturing execution delays in real time and locating affected logic branches, the system can quantify the cascading pressure caused by upstream delays on downstream processes. Utilizing the re-entry mechanism of parameter updates and weight recalculation, subsequent plans can be automatically reconstructed the instant execution deviation occurs, ensuring that high-risk dependent nodes are promptly elevated in weight, thereby effectively curbing the malignant spread of local delays to the global task chain.

[0107] In some embodiments of this application, after generating the atomic execution unit sequence in the skills training platform, the method further includes:

[0108] S501. Obtain the actual execution time data for the completed atomic execution units in the atomic execution unit sequence;

[0109] In this embodiment, a completed atomic execution unit refers to a task instruction item whose status flag in the system record changes from "in progress" to "completed" or "archived". The actual execution duration data is a precise measurement of the physical time consumed by the unit from its start time to its completion time. The acquisition process typically relies on a time monitoring module or log auditing system embedded in the execution terminal. When a user or an automatically executed script reports task completion, the system automatically captures the current timestamp and performs a difference calculation between it and the task's start timestamp to obtain a duration value in minutes or hours.

[0110] S502. Based on the actual execution time data, update the historical execution efficiency coefficients of the corresponding graph nodes in the reverse directed acyclic graph.

[0111] In this embodiment, updating the historical execution efficiency coefficient refers to the process of correcting historical parameters stored in the system knowledge base using newly collected sample data. A corresponding graph node refers to a logical node in the reverse directed acyclic graph that has a mapping relationship with a completed atomic execution unit. As a statistical indicator characterizing execution efficiency, the historical execution efficiency coefficient needs to be continuously iterated as the sample size increases.

[0112] S503, Return to the execution and use the historical execution performance coefficients to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node.

[0113] In this embodiment, this is a control logic that triggers rescheduling. Because the historical execution efficiency coefficients, which form the basis of computation, have changed, the original scheduling priority weights can no longer accurately reflect the current system state. Therefore, the system immediately discards or suspends currently unexecuted old sequences, re-evaluates the scheduling priority weights of the remaining incomplete graph nodes, and then generates a new schedule. This means that if a user exhibits a tendency to procrastinate on a certain type of task, the system will automatically reserve more buffer space for similar tasks or increase their processing priority in subsequent orchestration, thereby achieving dynamic adaptation of the plan.

[0114] As can be seen, the embodiments of this application construct a parameter evolution loop based on real feedback data. By collecting actual completion times and correcting historical efficiency coefficients in real time, the system can continuously learn the behavioral patterns and efficiency characteristics of the executing entity. Utilizing a trigger-based recalculation mechanism, it ensures that the orchestration strategy for subsequent tasks can be dynamically calibrated according to the latest execution capabilities, thereby solving the problem of mismatch between static plans and dynamic execution capabilities, and realizing intelligent self-iteration of task orchestration schemes.

[0115] In some embodiments of this application, the historical execution performance coefficients of corresponding graph nodes in the reverse directed acyclic graph are updated based on actual execution time data, including:

[0116] S601. Obtain the estimated execution time data of the corresponding graph nodes in the reverse directed acyclic graph;

[0117] In this embodiment, the estimated execution time data refers to the theoretical time consumption value planned by the system before the task begins execution, based on standard time quotas, expert experience, or default settings during cold start. This data is stored in the attribute fields of graph nodes, representing the standard time window required to complete the atomic execution unit under ideal conditions or uncorrected historical average conditions. The acquisition process is achieved by reading the static attributes of the target node in the graph database or in-memory data structure. The significance of acquiring the estimated execution time data is to establish a benchmark anchor point for comparison. The system needs to use this as a reference to measure whether the actual execution process has experienced "positive acceleration" or "negative delay".

[0118] S602. Determine the execution time deviation between the actual execution time data and the estimated execution time data;

[0119] In the embodiments of this application, the execution time deviation is a quantitative indicator characterizing the degree of deviation of the current execution activity from the planned baseline. The determination process is typically achieved through arithmetic difference calculation or ratio calculation.

[0120] In this embodiment, the process of determining the execution time deviation includes numerical truncation and normalization to ensure data robustness. The specific processing flow is as follows: The system first calculates the original deviation ratio R = (actual execution time - estimated execution time) / estimated execution time. To prevent extreme abnormal data from a single task (such as idle time caused by system hibernation) from contaminating the model, the system presets a deviation correction range [-0.5, 1.0]. If the calculated R is less than -0.5 (i.e., the execution speed is twice as fast as expected), the system determines that there may be abnormal data collection or a change in the nature of the task, and corrects the execution time deviation to -0.5, not directly accepting the original data; if R is greater than 1.0 (i.e., the delay exceeds 100%), the system truncates the execution time deviation to 1.0. For R values ​​within the range, the system directly assigns them to the execution time deviation. Through this data preprocessing logic with upper and lower limits, the system can effectively filter out outliers, ensuring that the deviation parameters input into the subsequent weighted summation model are always within a controllable range, and preventing irreversible and drastic fluctuations in the historical performance coefficients during a single iteration.

[0121] S603. Based on the preset historical weight decay factor, the historical execution efficiency coefficient and the deviation of execution time are weighted and summed to obtain the updated historical execution efficiency coefficient.

[0122] In this embodiment, the historical weight decay factor is a numerical constant ranging from 0 to 1, used to adjust the system's "forgetting rate" of historical experience data and its "acceptance sensitivity" to the latest data. This factor is similar to the learning rate in machine learning or the smoothing coefficient in the exponential moving average (EMA). The weighted summation process refers to the algorithmic process of using this factor to balance "past experience" with "current reality".

[0123] In some embodiments of this application, the calculation logic is as follows: Updated historical execution performance coefficient = (1 - historical weight decay factor) × original historical execution performance coefficient + historical weight decay factor × (1 + execution time deviation). Alternatively, an incremental correction formula is used: Updated historical execution performance coefficient = historical execution performance coefficient + historical weight decay factor × execution time deviation. By introducing the historical weight decay factor, the system can prevent drastic fluctuations in the historical execution performance coefficient due to single, accidental abnormal fluctuations (such as sudden extreme delays), while also ensuring that the latest execution trends can be gradually incorporated into the model.

[0124] As can be seen, this application's embodiments construct a parameter iteration algorithm with long short-term memory capabilities by introducing a historical weight decay factor. This algorithm can not only keenly capture current execution deviations but also smooth data noise using a decay mechanism, avoiding excessive interference from single anomalies on the overall scheduling model. By weighted fusion of historical coefficients and real-time deviations, the system achieves a mathematical balance between stability and flexibility in the scheduling model, ensuring that the task orchestration baseline can be progressively optimized as the execution team's capabilities change marginally.

[0125] In some embodiments of this application, according to scheduling priority weights, time-series mapping is performed on each graph node in the inverse directed acyclic graph to generate a sequence of atomic execution units in the skills training platform, including:

[0126] S701. Sort the nodes of the reverse directed acyclic graph according to the scheduling priority weight to obtain an ordered list of nodes.

[0127] In this embodiment, the ordered node list refers to a linear task queue waiting to be allocated time resources, arranged according to specific rules. The sorting process is not based solely on a simple numerical comparison of weights, but also needs to consider the preceding and following constraints of the topological structure.

[0128] In some embodiments of this application, the system first uses a topological sorting algorithm (such as Kahn's algorithm) to generate an initial sequence that satisfies dependencies. Then, within the set of nodes at the same level or without dependencies, they are arranged in descending order according to scheduling priority weights. Nodes with higher weights have higher priority in subsequent time slot allocation. Through this step, the system transforms the complex two-dimensional graph structure into a one-dimensional processing flow that balances logical rationality and business urgency, resolving the conflict resolution problem during resource contention.

[0129] S702. Obtain available time window data for deploying tasks;

[0130] In this embodiment, available time window data refers to the set of discrete time intervals that can be used to perform specific tasks after invalid time periods have been removed from the physical timeline. Invalid time periods typically include non-working hours, holidays, system maintenance windows, or reserved time periods for hardware resources. The acquisition process requires querying the system's resource calendar or schedule.

[0131] In some embodiments of this application, the system reads the global clock configuration and, in conjunction with the occupancy status of specific execution resources, generates a series of valid time slices, such as "[2023-10-27 09:00, 12:00]" and "[2023-10-27 13:00, 18:00]". This data constitutes the spatiotemporal foundation for task orchestration, ensuring that the generated plan does not fall into an unexecutable "time black hole".

[0132] S703. Based on historical execution performance coefficients, determine the safe buffer time interval for the deadline timestamp;

[0133] In this embodiment, the safety buffer time interval refers to a defensive time redundancy reserved before the absolute deadline to absorb potential delays due to uncertainties during execution. The deadline is a hard deadline by which the task must be delivered. The system uses historical execution performance coefficients to quantify the thickness of this redundancy.

[0134] S704. Starting from the time point from the deadline timestamp minus the safety buffer time interval, fill the graph nodes in the ordered node list into the available time window data in sequence to obtain the atomic execution unit sequence.

[0135] In this embodiment, the system first calculates the "soft cutoff time" (i.e., the cutoff timestamp minus the safety buffer time interval) and uses this as the starting point for backward calculation. Then, the system traverses each graph node in the ordered node list, combining its estimated execution time, and searches the available time window data from back to front for idle time slots that meet the duration requirements. For example, if a node requires 2 hours and the soft cutoff time is 17:00, the system will first attempt to lock the interval [15:00, 17:00]; if this interval is already occupied by a high-weight node, it will continue to move forward to [13:00, 15:00]. Once all nodes have completed locking their time slots, these task sets with clearly defined start and end time attributes constitute the atomic execution unit sequence. This process ensures that all tasks can theoretically be completed before the safety buffer period.

[0136] As can be seen, this application's embodiment employs a reverse scheduling strategy combined with a safety buffer. By dynamically setting a safety buffer based on historical performance, the system constructs a risk isolation zone before the hard delivery deadline. Combining priority sorting and reverse filling algorithms, this method ensures that high-value tasks occupy high-quality time resources closer to the delivery date, while using backward logic to force all tasks to be compactly arranged based on the "latest start time," maximizing the exposure of idle periods in the early stages of the project and reserving adjustment flexibility to cope with emergencies.

[0137] In some embodiments of this application, determining a safety buffer time interval for a deadline timestamp based on historical execution performance coefficients includes:

[0138] S801. Determine the execution risk multiplier factor of each graph node by utilizing the historical execution efficiency coefficient of each graph node in the reverse directed acyclic graph.

[0139] In this embodiment, the execution risk multiplier factor is a dimensionless value that converts historical performance data into a percentage of project duration increments. This factor is used to quantify the statistically significant probability of a specific task being delayed. The determination process is a numerical mapping process.

[0140] In some embodiments of this application, the system pre-defines a set of risk mapping functions, which use historical performance coefficients as independent variables and risk multiplier factors as dependent variables. If the historical coefficients indicate that the average delay rate of a certain node is 20%, the system maps it to a multiplier factor of 1.2 or 0.2 (depending on the specific multiplicative or additive model). For high-performance nodes that have never experienced delays, this factor can be set as a baseline value (such as 1.0 or 0). This step realizes the transformation from "historical qualitative evaluation" to "future quantitative prediction," assigning a personalized risk label to each task node.

[0141] In some embodiments of this application, historical execution performance coefficients can form a time-series data set stored according to timestamp indexes, which records the performance fluctuations of the graph node in past iteration cycles. The process of determining the execution risk multiplier factor is essentially a process of multi-dimensional feature extraction and nonlinear mapping of the statistical characteristics of the time-series data, aiming to construct a panoramic risk profile from three dimensions: "average performance," "fluctuation stability," and "extreme anomaly probability," as detailed below:

[0142] First, the system extracts the corresponding historical execution performance coefficient sequence for each graph node and calculates the coefficient of variation of the sequence. The coefficient of variation is the ratio of the standard deviation to the mean, used to characterize the relative dispersion of the data. If the coefficient of variation exceeds a preset stability threshold (e.g., 0.3), it indicates that the execution performance of the graph node is extremely unstable, exhibiting a jittery phenomenon of fluctuating speed. The system will positively increase the basic risk value based on the magnitude of the coefficient of variation.

[0143] Secondly, the system fits a probability distribution to the historical execution performance coefficient sequence, calculating kurtosis and skewness parameters. Kurtosis measures the thickness of the tail of the probability distribution. If the calculation result shows positive kurtosis (i.e., a heavy-tailed distribution), it means that although the graph node performs stably most of the time, it exhibits statistical characteristics of "black swan events" (i.e., extremely low probability but extremely high latency anomalies). To address this type of long-tail risk, the system introduces additional punitive weights to increase the execution risk multiplier.

[0144] Finally, the system uses a multi-factor weighted aggregation formula to determine the final execution risk multiplier factor. The calculation formula is: Execution Risk Multiplier Factor = Benchmark Value + α × (1 - Average Efficiency Coefficient) + β × Coefficient of Variation + γ × max(0, Kurtosis). Where α, β, and γ are the mean sensitivity weight, volatility sensitivity weight, and long-tail sensitivity weight, respectively (e.g., set to 0.5, 0.3, and 0.2). The benchmark value is typically set to 1.0.

[0145] Through the above approach, the system can not only identify the explicit risk of "habitual procrastination" (identified through average performance), but also more acutely capture the implicit volatility risk of "execution instability" (identified through coefficient of variation) and the extreme risk of "sudden collapse" (identified through kurtosis). This multi-dimensional calculation method ensures that the generated execution risk multiplier factor can truly reflect the robustness level of graph nodes in complex real-world environments, avoiding the "mean trap" caused by relying solely on average values.

[0146] S802. Based on the execution risk multiplier factor and estimated execution time data of graph nodes, determine the safe buffer time of graph nodes;

[0147] In this embodiment, the safety buffer time refers to a protective time period calculated additionally for a single graph node to offset potential execution deviations. This time period is not used for actual execution but rather acts as a resilient sponge to absorb uncertainty. The determination process typically employs product or incremental operations.

[0148] In some embodiments of this application, the system calculation formula is: Safety buffer time = Estimated execution time data × (Execution risk multiplier factor - Baseline factor). For example, if a task is estimated to take 10 hours and the risk multiplier factor is 1.2 (i.e., a 20% risk premium), then the individual safety buffer time for that task is 2 hours. Through this step, the system concretizes the abstract risk probability into physical time units, accurately calculating the "insurance amount" required for each atomic execution unit.

[0149] In some embodiments of this application, the process of determining the safety buffer time introduces the task entropy attribute as a correction coefficient. The specific data processing logic is as follows: The system first identifies the task type label of the graph node. If it is a "deterministic task" (such as data export, automatic transcoding), the entropy coefficient k=0 is set; if it is a "semi-deterministic task" (such as standardized approval), k=0.5 is set; if it is a "divergent task" (such as solution writing, code development), k=1.0 is set. Subsequently, based on the execution risk factor (Risk Factor, RF), the system calculates the corrected safety buffer time T_buffer using the following formula: T_buffer = estimated execution time × (RF-1) × (1+k).

[0150] The significance of this logic lies in the following: for tasks with low historical performance (high RF) but which are deterministic processes executed automatically by the machine, the system uses a coefficient k to suppress excessive buffer time expansion; while for divergent tasks that heavily rely on manual intervention and have poor historical performance, the system further amplifies the buffer margin using (1+k). Finally, the system compares the calculated T_buffer with a preset "minimum buffer time limit" (e.g., 5 minutes), taking the larger value as the final safe buffer time. This differentiated calculation scheme ensures that time resources are not allocated egally, but rather concentrated and preferentially invested in high-risk, high-uncertainty core bottleneck processes.

[0151] In some embodiments of this application, the system employs a nonlinear exponential growth model to determine the safety buffer time. Specifically, if the execution risk multiplier factor is in the low-risk range of [1.0, 1.2], the system uses linear calculation: buffer time = estimated duration × (factor - 1); if the factor is in the medium-high risk range of (1.2, 2.0], the system switches to an exponential amplification model: buffer time = estimated duration × ((factor)^2 - 1). This segmented calculation logic aims to apply stronger time protection to high-risk nodes, ensuring that the reserved buffer amount grows geometrically when the risk rises sharply, thereby accommodating potential extreme delays.

[0152] S803. Determine the safe buffer time interval based on the safe buffer time of all graph nodes in the reverse directed acyclic graph.

[0153] In this embodiment, the safety buffer time interval is a total buffer pool placed before the overall project deadline. Determining this interval is not simply a linear summation of the buffer times for all nodes, as parallel buffer times should not be counted repeatedly.

[0154] In some embodiments of this application, to avoid the simple accumulation of buffer times on paths leading to an excessively long total project duration, the system employs a buffer aggregation algorithm from Critical Chain Project Management (CCPM) to determine the safe buffer time interval. Specifically, the system identifies the critical path (i.e., the path with the longest total time) in the reverse directed acyclic graph and extracts the safe buffer time for all graph nodes on that path. Subsequently, the system uses the Root Sum Square (RSS) algorithm to aggregate these buffer times: Safe buffer time interval = √[∑(safe buffer time of each graph node)^2]. This calculation method is based on the Central Limit Theorem, which assumes that the probability of all nodes simultaneously experiencing maximum delay is extremely low. Therefore, the interval calculated using the root sum square can cover the vast majority of delay combinations while compressing unnecessary redundant time, achieving a mathematical balance between project timeliness and safety.

[0155] As can be seen, the embodiments of this application adopt a bottom-up risk aggregation strategy. By decomposing macro-level project risks into micro-level risk multipliers for each graph node, the system can accurately calculate the individual buffer for each task based on historical data. Combined with the critical chain aggregation algorithm, this method scientifically calculates the total safety buffer required for the entire project, avoiding both the risk of delays due to insufficient buffers and the waste of resources caused by blindly stacking buffers, thus achieving a mathematical balance between schedule safety and agile delivery.

[0156] In some embodiments of this application, the generated atomic execution unit sequence is configured to drive a physical terminal device (such as a desktop robot) to perform multimodal interactive execution. This process specifically includes: parsing the task attributes in the atomic execution unit sequence, determining the reminder mode combination, and generating corresponding hardware driver instructions.

[0157] Specifically, the system first traverses the sequence of atomic execution units, reading the alert mode field of each unit. If the field is identified as a voice mode, the system calls the speech synthesis engine to extract the "task description" text from the atomic execution unit, synthesizes speech waveform data, and drives the speaker module to play it. If the field is identified as a haptic feedback mode, the system sends a specific vibration control command to the microcontroller of the physical terminal device via the Universal Asynchronous Receiver / Transmitter (UART) protocol. Upon receiving the command, the physical terminal device drives an eccentric rotating mass vibration motor to perform a vibration operation for a specified duration (e.g., 250 milliseconds) to generate a physical tactile alert. If the field is identified as a visual mode, the system creates a notification instance through the rendering process and displays a visual pop-up window containing task details on the display device.

[0158] As can be seen, the embodiments of this application transform the abstract task orchestration results into multimodal feedback in the physical world, using three independent channels—voice, touch, and vision—for simultaneous reminders. This mechanism can effectively break through the information cocoon of a single sensory channel. In particular, the strong interruption capability provided by physical vibration enhances the user's perception of the atomic execution unit sequence, thereby solving the problem of "low reach" that is easily overlooked at the execution end of digital plans.

[0159] In some embodiments of this application, the system also introduces a computer vision-based attention detection mechanism to prevent unnecessary disturbances before notifying and triggering the atomic execution unit sequence.

[0160] The specific processing logic is as follows: The system acquires video stream data from the camera capture device interacting with the user in real time. Using a pre-trained human pose estimation model or face detection algorithm, it analyzes whether the target user's feature data exists in the current video frame. If the detection result is "user absent" (i.e., no face or human outline detected), the system will intercept physical alert signals targeting the current atomic execution unit (such as pausing haptic feedback or muting voice broadcasts) and suspend the alert event to a "pending processing buffer pool." When the detection result changes to "user present," the system immediately releases the alert signal in the buffer pool and resumes the alert operation. Furthermore, users can preset a "Do Not Disturb" authorization in the system. When the system detects that the user is in a highly focused working state (determined through gaze focus analysis), it can automatically downgrade highly intrusive voice / vibration alerts to silent visual breathing light prompts.

[0161] As can be seen, the embodiments of this application construct intelligent gating logic with environmental awareness capabilities. By combining computer vision technology to determine the user's presence and attention allocation in real time, the system achieves a leap from "mechanical timed reminders" to "scenario-based intelligent interruptions." This not only avoids ineffective energy consumption and information idling when the user is absent, but also reflects respect for the user's cognitive load, improving the comfort and intelligence level of human-computer interaction.

[0162] Secondly, embodiments of this application provide a task orchestration system in a skills training platform, which is used to execute the task orchestration method in the skills training platform as described in any of the above embodiments.

[0163] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program configured to be executed by a processor to implement the task orchestration method in the skills training platform as described in any of the above embodiments.

[0164] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A task arrangement method in a skills training platform, characterized in that, The task arrangement method in the skills training platform includes: Identify the target data object to be processed in the skills training platform, wherein the target data object includes logical dependency data and deadline timestamp; Based on the logical dependency data and the deadline timestamp, a reverse directed acyclic graph is constructed with the deadline timestamp as the root node; Obtain the historical execution performance coefficients associated with each graph node in the reverse directed acyclic graph; Using the historical execution efficiency coefficients, a weighted calculation is performed on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node; According to the scheduling priority weight, the nodes of each graph in the reverse directed acyclic graph are time-series mapped to generate the atomic execution unit sequence in the skills training platform.

2. The task arrangement method in the skills training platform as described in claim 1, characterized in that, The construction of a reverse directed acyclic graph with the deadline timestamp as the root node, based on the logical dependency relationship data and the deadline timestamp, includes: Generate a graph structure with the stated deadline timestamp as the endpoint vertex; Based on the logical dependency data, the predecessor data node pointing to the endpoint vertex is determined; Generate a directed edge from the predecessor data node to the endpoint vertex; The reverse directed acyclic graph is generated using a graph structure that includes the endpoint vertex, the predecessor data node, and the directed edges.

3. The task arrangement method in the skills training platform as described in claim 1, characterized in that, The step of using the historical execution performance coefficients to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node includes: Based on the historical execution efficiency coefficients corresponding to each graph node in the reverse directed acyclic graph, the execution resistance factor corresponding to each graph node is determined. Determine the task importance parameters and execution time urgency parameters for each of the graph nodes; Based on the task importance parameter, the execution time urgency parameter, and the execution resistance factor, the scheduling priority weight of the corresponding graph node is determined.

4. The task arrangement method in the skills training platform as described in claim 3, characterized in that, After performing time-series mapping on each graph node in the reverse directed acyclic graph according to the scheduling priority weights to generate the atomic execution unit sequence in the skills training platform, the method further includes: Receive execution delay status feedback instructions for the target atomic execution unit in the atomic execution unit sequence; In the reverse directed acyclic graph, downstream association graph nodes with the target atomic execution unit as a predecessor dependency are determined; Update the execution time urgency parameter of the downstream related graph node; Return to the step of determining the scheduling priority weight of the corresponding graph node based on the task importance parameter, the execution time urgency parameter, and the execution resistance factor.

5. The task arrangement method in the skills training platform as described in claim 1, characterized in that, After generating the atomic execution unit sequence in the skills training platform, the method further includes: Obtain the actual execution time data for the completed atomic execution units in the atomic execution unit sequence; Based on the actual execution time data, the historical execution efficiency coefficients of the corresponding graph nodes in the reverse directed acyclic graph are updated; Return to the step of using the historical execution performance coefficient to perform weighted calculations on each graph node in the reverse directed acyclic graph to obtain the scheduling priority weight of each graph node.

6. The task arrangement method in the skills training platform as described in claim 5, characterized in that, The step of updating the historical execution efficiency coefficients of the corresponding graph nodes in the reverse directed acyclic graph based on the actual execution time data includes: Obtain the estimated execution time data of the corresponding graph nodes in the reverse directed acyclic graph; Determine the execution time deviation between the actual execution time data and the estimated execution time data; Based on a preset historical weight decay factor, the historical execution efficiency coefficient and the execution time deviation are weighted and summed to obtain the updated historical execution efficiency coefficient.

7. The task arrangement method in the skills training platform as described in claim 1, characterized in that, The step of performing time-series mapping on each graph node in the reverse directed acyclic graph according to the scheduling priority weight to generate the atomic execution unit sequence in the skills training platform includes: Based on the scheduling priority weights, the nodes in the reverse directed acyclic graph are sorted to obtain an ordered list of nodes; Obtain available time window data for deploying tasks; Based on the historical execution performance coefficients, a safe buffer time interval is determined for the cutoff timestamp; Starting from the point in time from the cutoff timestamp minus the safety buffer time interval, the graph nodes in the ordered node list are sequentially filled into the available time window data to obtain the atomic execution unit sequence.

8. The task arrangement method in the skills training platform as described in claim 7, characterized in that, The step of determining the safety buffer time interval for the cutoff timestamp based on the historical execution performance coefficient includes: The execution risk multiplier factor of the graph node is determined by using the historical execution efficiency coefficient of each graph node in the reverse directed acyclic graph. Based on the execution risk multiplier factor and estimated execution time data of the graph nodes, the safety buffer time of the graph nodes is determined; The safety buffer time interval is determined based on the safety buffer time of all graph nodes in the reverse directed acyclic graph.

9. A task scheduling system in a skills training platform, characterized in that, The task scheduling system in the skills training platform is used to execute the task scheduling method in the skills training platform as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program configured to be executed by a processor to implement the task orchestration method in the skills training platform according to any one of claims 1 to 8.

Images