An AI agent-based practical training task dynamic scheduling method

Abstract

The application relates to the technical field of education informatization task scheduling, and discloses a practical training task dynamic scheduling method based on an AI intelligent agent; the method first acquires course target information, learner state data and practical training resource information, establishes course target data records, learner state data records and resource digital twin mirror images; collects learner runtime sensing information and generates a standardized runtime event stream, and identifies the current task undertaking state change of the learner; candidate task schemes are generated according to the state change, a skill map and a task library, and resource states are synchronized and hard constraint verification is performed before task issuing; after the verification, task issuing instructions are generated, and abnormal degradation and state updating are performed according to the task execution state, so that task mismatch, resource repeated allocation and abnormal diffusion are reduced.

Description

Technical Field

[0001] This invention relates to the field of educational informatization task scheduling technology, specifically a method for dynamic scheduling of practical training tasks based on AI intelligent agents. Background Technology

[0002] As practical training in vocational colleges, applied undergraduate colleges, and corporate training institutions gradually moves towards informatization and intelligence, the allocation of practical training tasks is no longer limited to course content recommendations. It also needs to be processed in conjunction with the learner's current operating status and the availability of execution resources such as training workstations, software licenses, computing resources, consumables, and simulation images. In existing technologies, for example, authorized Chinese invention patent application CN112381454B discloses a role-based multi-agent task collaboration system, which realizes multi-agent collaboration through task decomposition, role allocation, and agent scheduling. Another example is authorized Chinese invention patent application CN110569443B, which discloses an adaptive learning path planning system based on reinforcement learning, which plans the sequence of learning resources according to the student's ability status. The above technologies can be used for multi-agent collaborative scheduling and learning path planning, but their focus is still mainly on task collaboration relationships or learning resource recommendation relationships. In real-world training scenarios, learners typically rely on real or virtual execution resources to complete operational tasks. If task allocation is primarily based on role mapping, historical scores, static skill levels, or pre-generated learning paths, it becomes difficult to reflect learners' ongoing operational status, such as continuous errors, prolonged pauses, frequent requests for help, and fatigue changes. Furthermore, if candidate tasks are not verified against on-site resource status before being issued, tasks may still be issued even when training workstations are occupied, software licenses are exhausted, computing resources are insufficient, equipment malfunctions, or simulation images are unavailable. These issues can lead to mismatches between candidate tasks and on-site execution conditions, resulting in task mismatches, resource conflicts, task inability to start, and the spread of local anomalies to multiple learners' tasks being interrupted. Therefore, a dynamic scheduling method for training tasks is needed that integrates learner runtime status, training resource status, pre-issuance verification, and anomaly handling processes to improve the executability of candidate task issuance and reduce redundant resource allocation and anomaly propagation. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a dynamic scheduling method for training tasks based on AI agents, which solves the problems mentioned in the background section.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A method for dynamic scheduling of training tasks based on AI agents includes: Acquire course objective information, learner basic status data, and practical training resource information; establish course objective data records, learner initial status data records, and resource digital twin mirrors. Collect learner runtime perception information, preprocess the learner runtime perception information, and obtain a standardized runtime event stream; Based on the standardized runtime event stream, the changes in the learner's current task acceptance status are identified, and a learner status change notification is generated. Candidate task schemes are generated based on the learner status change notification, skill map, task library, and course objectives. Synchronize the resource status involved in the candidate task schemes and perform hard constraint verification on the candidate task schemes before task issuance; After successful verification, write the resource pre-occupancy status and generate the task issuance instruction; Perform abnormal degradation processing based on the task execution status, and update the learner status data record based on the task execution result.

[0005] In one possible implementation, information on course objectives, learners' basic status data, and practical training resources is obtained, including: The course objective information can be obtained from the course syllabus, practical training task library, skill map configuration file, assessment node schedule, or teacher workstation configuration records; The learner's basic status data is formed based on the prior course grades, entrance assessment results, historical training records, completed task records, teacher manual confirmation results, or learner status data update records after the last training session. The training resource information is obtained from the resource pool, software license server, computing power scheduling platform, training workstation controller, consumable inventory system, or virtual simulation server.

[0006] In one possible implementation, the learner's runtime perception information is preprocessed to obtain a standardized runtime event stream, including: Collect operation logs, as well as at least one of the following: process outputs, task submission records, terminal running status, operation rhythm, or help requests; The collected data is preprocessed locally, including at least one of the following: removing meaningless characters, filtering mouse jitter, merging duplicate reported events of the same type, adding missing identifiers, temporarily storing data that exceeds the scope of the current task, and adding a checksum. A unified time base is used to normalize the timestamps of events from different data channels; Transform events from different sources into the standardized runtime event stream.

[0007] In one possible implementation, the change in the learner's current task acceptance state is identified based on the standardized runtime event stream, and a learner state change notification is generated, including: Identify local operational states over a short period of time using microscopic time windows; By aggregating the local operational states within multiple micro time windows through meso-level time windows, we can determine the stage of stagnation, the state of intensive requests for help, or the state of recovery. By combining the judgment results of multiple meso-level time windows, the task completion rate, the quality of phased outputs, the count of consecutive failures, and the teacher's confirmation results, it is determined whether to generate the learner status change notification.

[0008] In one possible implementation, the microscopic time window, the mesoscopic time window, and the macroscopic time window are determined based on the type of training task, the terminal's data acquisition and response capabilities, the typical time consumption of task steps, historical operation records, or on-site calibration results. The training task types include programming training tasks, data analysis training tasks, network configuration training tasks, assembly training tasks, electromechanical training tasks, or CNC training tasks.

[0009] In one possible implementation, candidate task schemes are generated based on the learner state change notification, skill map, task library, and course objectives, including: Determine optional skill nodes based on the current course objectives; Select target skill points by combining the learner's current ability level, prior skill mastery, and course stage; Based on the target skill points, select training tasks from the task library that match the difficulty and resource requirements; Generate candidate task plans, wherein the candidate task plans include at least one of the following: task number, target skill points, difficulty level, typical time consumption, required resource list, preconditions, collaboration mode, risk level, expected completion time window, and downgrade alternative flag.

[0010] In one possible implementation, candidate task schemes are generated, including: Request a resource status summary, and determine the currently available workstations, available licenses, available computing nodes, available consumables, and available simulation images based on the resource status summary; If the resources required for a task are occupied, faulty, insufficient, or in an unconfirmed state, reduce the candidate priority of the corresponding task, or generate a candidate task scheme that includes at least one alternative path among alternative resources, simulation alternatives, and guided distribution. In cases where the AI ​​agent is unavailable, the response times out, or the candidate result field is abnormal, a rule engine is used to generate a rollback candidate task scheme, and the rollback candidate task scheme is sent to the hard constraint verification before task issuance.

[0011] In one possible implementation, synchronizing the resource states involved in the candidate task scheme includes: Maintain resource status data records for various training resources. The resource status data records include at least one of the following: resource number, resource type, resource location, health status, occupancy status, available time window, resource balance, associated learner identifier, associated task number, last heartbeat time, status update time, and status source. Before the candidate task scheme enters the hard constraint verification before task issuance, the key resources involved in the candidate task scheme are subject to forced resource synchronization. If the resource query returns a valid status, the result will be written to the resource status data record. If a resource query times out, fails to verify, or the source of the status is unreliable, the corresponding resource will be marked as having an unverifiable status and treated as an unavailable resource in subsequent verifications.

[0012] In one possible implementation, the candidate task scheme undergoes hard constraint verification before task issuance, including: Perform resource availability verification to determine whether the resources required by the candidate task plan meet the execution conditions; Perform learner acceptance boundary verification to determine whether the learner’s current ability status matches the requirements of the candidate task; Perform a consistency check of teaching constraints to determine whether the candidate task schemes conform to the current course schedule and teaching execution order; If the necessary checks in resource availability verification, learner acceptance boundary verification, and teaching constraint consistency verification fail, no formal task issuance instruction will be generated.

[0013] In one possible implementation, after successful verification, a resource pre-occupancy status is written and a task issuance instruction is generated, including: Write the final task plan that has passed the hard constraint verification before task issuance into the resource pre-occupancy status; If the resource pre-occupancy status is successfully written, a task issuance instruction will be generated. If the learner's training terminal does not return a confirmation of receipt, release the pre-occupied resources that have been written and mark the corresponding task as unsuccessfully sent. During task execution, the task execution status is continuously received. The task execution status includes at least one of the following: task start status, resource handle valid status, procedural output submission status, stage progress completion status, number of errors, number of requests for help, terminal heartbeat, resource call status, and task end status.

[0014] In one possible implementation, exception degradation handling is performed based on the task execution status, including: The anomaly level is determined based on the anomaly type, scope of impact, duration, and task degradability flag; An exception handling instruction is generated based on the exception level. The exception handling instruction includes at least one of the following: retry, refresh resource handle, restart simulation image, replace resource, switch simulation, resume training from breakpoint, pause new task issuance, or manual takeover. The anomaly types include at least one of the following: learner status anomaly, resource status anomaly, communication anomaly, candidate task scheme anomaly, execution environment anomaly, teacher manual intervention conflict, or security incident.

[0015] In one possible implementation, the learner state data record is updated based on the task execution result, including: The task execution results include at least one of the following: task completion rate, stage completion order, final output, output score, cumulative time, effective operation time, number of errors, number of similar errors, number of requests for help, number of teacher interventions, degradation mode records, abnormal reason codes, and resource release records. The skill mastery field is updated incrementally based on task completion, output rating, and error recovery. Confirm changes in capability levels based on the results of consecutive tasks or the status of consecutive time windows; The fatigue level field is updated based on continuous operation duration, error recovery interval, help frequency, and rest time. The consecutive failure count field is updated based on whether the task fails, fails after being downgraded, repeats the same type of error, completes the same type of reinforcement task, or the teacher confirms the result. Before releasing resources, confirm the resource handle occupancy status, learner training terminal resource usage status, software license return status, simulation image closure status, and consumable verification status. If the release confirmation fails, mark the corresponding resource as pending review.

[0016] Compared with existing technologies, this invention provides a dynamic scheduling method for training tasks based on AI agents, which has the following beneficial effects: 1. This invention establishes a data foundation for task scheduling by acquiring course objective information, learner basic status data, and practical training resource information; it identifies changes in learner's current task acceptance status by collecting and preprocessing learner runtime perception information and generates candidate task schemes accordingly; it intercepts candidate tasks that do not meet the execution conditions by synchronizing the resource status of candidate tasks before task issuance and performing hard constraint checks on resource availability, learner acceptance boundaries, and consistency of teaching constraints; and it enables practical training task scheduling to simultaneously combine learner runtime status, on-site resource status, and anomaly handling status by writing resource pre-occupancy status and generating task issuance instructions after successful verification, as well as performing anomaly degradation handling during task execution and updating learner status data records after task completion. This reduces task mismatch, duplicate resource allocation, task inability to start, and local anomaly propagation leading to task interruption for multiple learners.

[0017] 2. This invention, by performing local preprocessing, timestamp normalization, and standardized event stream conversion on learner runtime perceived information, enables data from different sources, such as operation logs, task submission records, terminal running status, and help events, to enter the status recognition process in a unified format. It uses micro, meso, and macro time windows to perform tiered judgments on short-term operation status, phased stagnation status, and continuous acceptance status, respectively. Furthermore, it progressively updates learner status data records after task execution results are collected. This reduces the direct impact of single misoperations, occasional errors, or short pauses on ability levels, fatigue levels, and consecutive failure counts, thereby improving the stability and traceability of the learner status data update process. This allows subsequent task scheduling to be based on learner status data that better reflects the actual training process. Attached Figure Description

[0018] Figure 1 A schematic diagram of the structure of the invention's dynamic scheduling system for practical training tasks; Figure 2 A flowchart illustrating the dynamic scheduling method for practical training tasks. Figure 3 A schematic diagram illustrating the preprocessing of perceived information during the invention's runtime; Figure 4 A schematic diagram of the invention's three-layer time window state recognition; Figure 5 A schematic diagram is generated for candidate invention task schemes; Figure 6 A schematic diagram illustrating the synchronization of digital twin mirrors for invention resources; Figure 7 A schematic diagram of hard constraint verification before the invention task is issued; Figure 8 A schematic diagram illustrating the anomaly classification and downgrade processing; Figure 9 A schematic diagram illustrating the invention of closed-loop feedback and learner state updates; Figure 10 This is a schematic diagram for resuming training from a weak network or offline interruption. Detailed Implementation

[0019] The following description, in conjunction with the accompanying drawings, illustrates the dynamic scheduling method for training tasks based on AI intelligent agents provided in the embodiments of this application. The following embodiments are used to illustrate the technical solutions of this application and are not intended to limit the scope of protection of this application. Where there is no contradiction, the technical features in each embodiment can be combined with each other. The method in the embodiments of this application can be executed by a training teaching cloud platform, a local teaching server, an edge computing gateway, or a training room control device, or it can be executed collaboratively by the above devices, learner-end training terminals, teacher workstations, and a training resource pool. The learner-end training terminal is used to collect learner runtime data and receive task instructions; the teacher workstation is used to configure teaching rules and receive exception prompts; and the training resource pool is used to provide resource status such as workstations, licenses, computing power, consumables, and simulation images.

[0020] In the practical training process of vocational colleges, applied undergraduate colleges, corporate training institutions, and industry-education integration training bases, the practical training tasks performed by learners are usually not simply online quizzes or course browsing, but rather operational tasks that require the use of learner terminals, training workstations, professional software licenses, computing resources, virtual simulation images, consumable kits, or physical equipment. Existing training systems typically assign tasks based on fixed course progress, static ability levels, historical grades, pre-configured task lists by teachers, or the availability of a single resource. While this method can complete basic task distribution, in training environments involving multiple learners, workstations, software licenses, computing resources, and simulation images, the learner's current operational status, the actual availability of resources, and the handling of anomalies will continuously change. A fixed assignment method can easily lead to a mismatch between the task allocation results and the actual execution status. For example, learners may encounter similar errors repeatedly in the current task, fail to submit effectively for a long time, or frequently request help, but the system still assigns them more difficult tasks based on the learner's pre-class status data; a software license may be occupied by another learner, a training workstation may be faulty, a simulation image may fail to start, or a computing node may be overloaded, but candidate tasks may still be sent to the execution terminal; when a network in a certain area experiences a short-term interruption or a device experiences a partial failure, conventional systems often can only pause, reschedule, or wait for manual intervention by the teacher, causing the originally local anomaly to spread to the task interruption of multiple learners; based on the above situations, this application embodiment determines the learner's current task acceptance status by collecting learner runtime perception information, and combines resource digital twin images and task execution constraints to perform hard constraint verification on the candidate task schemes generated by the AI ​​agent before distribution, thereby reducing task mismatch, resource conflict, and overall anomaly spread, enabling training task scheduling to have a closed-loop processing capability that is executable, interceptable, degradeable, and capable of feedback updates.

[0021] The basic processing procedure of this application embodiment is as follows: First, the learner-side training terminal, resource pool interface, and teacher workstation acquire runtime events, course objectives, learner status data records, and training resource status; then, the processing device performs timestamp normalization, field verification, and invalid fragment removal on the runtime events, and identifies changes in the learner's current task acceptance status layer by layer according to micro-time windows, meso-time windows, and macro-time windows; subsequently, the AI ​​agent generates candidate task schemes based on learner status change notifications, task libraries, and skill graphs, and the resource digital twin mirror provides the current status of the resources involved in the candidate task schemes; before the task is issued, the processing device verifies the resource availability of the candidate task schemes and the learner acceptance edge. Boundary verification and consistency verification of teaching constraints are performed. After the verification is passed, a task issuance instruction is generated and written into the resource pre-occupancy status. During task execution, events such as terminal offline, resource desynchronization, license exhaustion, equipment failure, network interruption, and abnormal candidate results are handled in a graded manner. After the task is completed, interrupted, or downgraded, the learner status data record is updated according to the task completion degree, time consumption, error, help request, and downgrade records, so that the next round of task scheduling can be executed based on the updated status. Through the above processing, the candidate task scheme generated by the AI ​​agent will not be directly issued as a terminal execution instruction, but needs to be converted into an executable task instruction constrained by resource status, learner capacity, and teaching sequence.

[0022] In this application embodiment, the AI ​​agent refers to a software functional unit deployed in a teaching server, edge computing gateway, or teaching cloud platform, used to generate candidate task schemes or degradation suggestions based on learner status data records, course objectives, resource status, and abnormal events. The AI ​​agent can be implemented using one or more of the following methods: rule matching, task library filtering, table lookup mapping, state machine control, manual configuration strategy invocation, and interpretable candidate scheme generation rules. This application does not consider the model training process as a necessary technical feature. A training task refers to a training project that can be executed or carried by a learner terminal, training workstation, software license, computing resources, consumable kits, or virtual simulation image, and includes at least fields such as task number, target skill points, difficulty level, task parameters, required resource list, estimated time window, collaboration mode, and degradation candidate flag. Learner status data records refer to data records used to record the learner's training status, and include at least learner identifier and skill mastery level. Fields include: current ability level, operating style, collaboration preference, safety qualifications, fatigue level, and consecutive failure count; cognitive state drift is used to represent the change in the learner's current task acceptance status during practical training due to getting stuck, fatigue, ability improvement, stagnation, or frequent requests for help. This description is only used to describe the change in the ability to accept practical training tasks and does not involve the judgment of psychological state in a medical sense; resource digital twin mirror refers to a resource status table that synchronously maintains the availability, occupancy, health status, reserve, and timestamp of resources such as practical training workstations, software licenses, computing power nodes, consumable inventory, and simulation mirrors. It is not required to include a three-dimensional visualization model; third-order hard constraint verification refers to the resource availability verification, learner acceptance boundary verification, and teaching constraint consistency verification performed sequentially or according to the task risk level before the candidate task scheme enters the execution layer; degradation mode refers to the operation mode that allows the task to continue to execute safely, switch to a backup path, pause and wait, or be manually taken over in abnormal states.

[0023] like Figure 1 As shown, in one possible implementation, the training task dynamic scheduling system 100 includes at least the following functional modules: a data access and preprocessing module 110, a cognitive state drift detection module 120, a candidate task scheme generation module 130, a resource digital twin mirror module 140, a third-order hard constraint verification module 150, a task issuance and execution monitoring module 160, an anomaly classification and degradation control module 170, and a closed-loop feedback and learner status data update module 180. These functional modules can be deployed on the same teaching server or distributed across the training teaching cloud platform, edge computing gateway, or training room control equipment. The data access and preprocessing module 110 is communicatively connected to the learner-side training terminal 10, resource pool 30, and teacher workstation 40. It receives learner runtime events, resource status, course configuration, and teacher intervention information, and performs field validation, timestamp normalization, duplicate event removal, and invalid fragment filtering on the received data. The cognitive state drift detection module 120 identifies learner states such as short-term stagnation, mid-term stagnation, persistent fatigue, and changes in ability levels based on the preprocessed runtime event stream, and generates learner status change notifications. The candidate task scheme generation module 130 generates candidate task schemes based on learner status change notifications, course objectives, skill maps, and the task library. The resource digital twin mirror module 140 maintains resource status data records for training workstations, software licenses, computing resources, consumable inventory, and simulation mirrors, and synchronizes relevant data before candidate task schemes undergo verification. Resource status; the third-order hard constraint verification module 150 is used to verify the resource availability, learner acceptance boundary, and teaching constraint consistency of candidate task schemes before task issuance, and output the verification results and failure reasons; the task issuance and execution monitoring module 160 is used to generate task issuance instructions after the candidate task scheme passes the verification, bind the corresponding resource handles, and receive terminal feedback and process status during task execution; the anomaly classification and degradation control module 170 is used to determine the anomaly level according to the anomaly type, scope of impact, and duration, and generate processing instructions such as retry, resource replacement, simulation switching, breakpoint continuation training, or manual takeover according to the anomaly level; the closed-loop feedback and learner status data update module 180 is used to collect execution results after task completion, interruption, or degradation, and update learner status data records according to completion degree, time consumption, error, help request, and degradation records.

[0024] In one specific implementation, such as Figure 2 As shown, the dynamic scheduling method for practical training tasks may include steps S101 to S108. In step S101, the teaching server 20 acquires course objective information, learner basic status data, and practical training resource information. The course objective information can be provided by the course syllabus, practical training task library, skill map configuration file, assessment node schedule, or configuration records in the teacher workstation 40. The learner basic status data can be formed by prior course grades, entrance assessment results, historical practical training records, completed task records, teacher manual confirmation results, or learner status data update records after the last practical training. The practical training resource information can be provided by the resource pool 30, software license server, computing power scheduling platform, practical training workstation controller, consumable inventory system, or virtual simulation server. After acquiring the above information, the teaching server 20 establishes course objective data records, learner initial state data records, and resource digital twin images. The course objective data records include at least the following fields: target skill points, skill level, prerequisite nodes, typical time consumption, optional task number, assessment node, and task dependency relationship. The learner initial state data records include at least the following fields: learner identifier, skill mastery, ability level, operating style, safety qualification, fatigue level, and consecutive failure count. The resource digital twin images include at least the following fields: resource number, resource type, occupancy status, health status, remaining capacity, available time window, most recent heartbeat time, and status source. Through the above initialization process, subsequent candidate task generation, resource verification, and task distribution can be performed based on a unified data foundation, avoiding inaccurate task matching or inconsistent resource status judgment caused by directly relying on scattered data sources. In step S102, the learner-side training terminal 10 collects runtime perception information of the learner during task execution. The runtime perception information may include one or more of the following: operation log, process output, operation rhythm, help events, terminal running status, and task submission record. To ensure that the learner's operation process can be identified and the task execution result can be retrieved later, in an optional embodiment, the runtime perception information includes at least one of the following: operation log reflecting the operation process, and process output, task submission record, or terminal running status reflecting the execution result. This setting is based on the fact that it is difficult to confirm whether the task output is valid when only the operation log is collected, and it is difficult to identify the blockage, stagnation, or abnormality in the execution process in a timely manner when only the final submission record is collected. Operation logs can include events such as command input, code execution, configuration modification, assembly step confirmation, simulation execution, error messages, undo operations, and save operations; process outputs can include data such as code version files, configuration files, experiment report versions, assembly step status, simulation parameter files, and stage submission files; operation rhythm can include data such as keystroke intervals, mouse pauses, command input speed, step intervals, error recovery intervals, and help response intervals; terminal running status can include data such as training software process status, network connection status, resource handle status, and task execution progress. Not all of the aforementioned runtime perception information needs to be collected. In scenarios with high privacy compliance requirements or limited terminal data collection capabilities, only data directly related to task execution, such as operation logs, procedural outputs, task submission records, help requests, and terminal operating status, can be collected, without collecting camera images, microphone audio, facial expressions, or other sensitive information. In this way, the system can still identify the learner's current task acceptance status based on error reports, pauses, submissions, help requests, and terminal status, and provide a data foundation for subsequent candidate task generation and pre-task verification.

[0025] like Figure 3 As shown, after collecting runtime perception information, the learner-side training terminal 10 can first perform local preprocessing on the collected data. The preprocessing content can include removing meaningless characters, filtering mouse jitter, merging similar events that are repeatedly reported in a short period of time, adding missing data markers to incomplete data, temporarily storing data that exceeds the scope of the current task, and attaching verification codes to event content. Through local preprocessing, the impact of invalid operations, repeated reporting, and missing fields on subsequent status judgment can be reduced. The teaching server 20 can use a unified time base to normalize the timestamps of events from different data channels. The unified time base can be formed by the teaching server 20 for time synchronization, local area network time synchronization service, edge node time base, or the terminal's local time after server correction. If the deviation between the timestamp of an event and the unified time base exceeds the preset allowable deviation, the teaching server 20 can mark the event as an event to be reviewed and reduce its priority or remove it in subsequent time window statistics. The preset allowable deviation can be determined based on the teaching local area network synchronization capability, the terminal system response capability, and on-site test results. For training scenarios using local area network deployment and terminal events are statistically analyzed in second-level windows, the preset allowable deviation can be set in the range of milliseconds to hundreds of milliseconds, which can meet the needs of identifying the order of events between different data channels. For scenarios where offline caching is followed by retransmission, the system can simultaneously retain the original acquisition time and the server receiving time, and determine whether the event should be included in the formal time window statistics based on the server verification result. Through the above processing, the event data used for subsequent status identification has a clear data source, field structure, and time sequence basis, which can reduce the impact of out-of-order events, duplicate events, and accidental touch events on the judgment results. The data access and preprocessing module 110 can convert events from different sources into standardized runtime event streams. These standardized runtime event streams include at least the following fields: learner identifier, terminal identifier, task number, event type, event content, event source, collection time, normalized timestamp, verification result, and exception identifier. Event types can include input events, running events, error events, submission events, help events, pause events, resource call events, terminal status events, and teacher intervention events. For different types of events, the teaching server 20 can adopt corresponding validity judgment rules. For example, for input events, it can determine whether the input event occurred in the current task operation interface; for error events, it can determine whether they are repeated triggers of the same error code, the same error type, or the same operation location; for submission events, it can determine whether the submitted file matches the task number, submission version, and file format; for help events, it can determine whether the source is initiated by the learner, confirmed by the system prompt, or remotely intervened by the teacher. By converting events from different sources into runtime event streams with a unified field structure, a consistent data interface can be provided for subsequent time window processing. In step S103, the cognitive state drift detection module 120 can process the standardized runtime event flow layer by layer according to micro time windows, meso time windows, and macro time windows. The micro time window is used to identify local operation states within a short period of time, such as repeated occurrence of the same error, significant decrease in command input speed, long pauses, frequent undoing, or continuous running failures. The meso time window is used to aggregate the local states within multiple micro time windows to determine whether the learner has experienced a phase of stagnation, frequent requests for help, continuous error reporting, or task progress that is significantly lower than the usual progress of similar tasks. The macro time window is used to combine the judgment results of multiple meso time windows, task completion ratio, phased output quality, continuous failure count, and teacher confirmation results to determine whether it is necessary to formally update the learner's state data record. Through the above three-layer time window processing, the local state output by the micro time window will not directly rewrite the learner's state data record, and the stage judgment formed by the meso time window will not directly change the ability level. Only when the macro time window confirms that the state change continues and meets the update conditions will the system generate a learner state change notification. This processing method can avoid unstable changes in the learner state field due to occasional misoperation, single error, or short pause, making the update of learner state data records more consistent with the actual execution process of the training task.

[0026] like Figure 4As shown, the cognitive state drift detection module 120 can set different time window parameters according to the type of training task to identify changes in the learner's current task acceptance status. For programming, data analysis, or network configuration training tasks, the micro time window can be set to 5 seconds and the sliding step can be set to 1 second. This value is used to cover a typical process of a command input, a running feedback, or a short pause, and can promptly identify states such as repeated occurrence of the same error, decreased input speed, or no effective operation for a short period of time. The meso time window can be set to 30 seconds and the sliding step can be set to 5 seconds. This value is used to cover a common small step of code modification, configuration adjustment, or error recovery, and can determine whether a short-term anomaly has formed a stage of stagnation. The macro time window can be set to 3 minutes and the sliding step can be set to 30 seconds. This value is used to cover the initial progress of a sub-task stage and to determine whether it is necessary to formally update the learner's status data record, avoiding single short-term fluctuations from directly causing changes in the learner's status field. For assembly, electromechanical, or CNC training tasks, since individual physical operation steps, fixture verification, equipment response, and safety checks typically take longer than pure software operations, the micro-time window can be adjusted to 10 seconds, the meso-time window to 60 seconds, and the macro-time window to 5 minutes. These time window parameters can be determined based on the terminal's data acquisition response capability, typical task step times, historical operation records, and on-site calibration results, and are not limited to fixed values ​​during formal implementation. By matching the time window parameters with the task type, equipment response speed, and task step times, misjudgments caused by using the same time window for different training scenarios can be avoided. During the meso-level time window processing, the data read by the teaching server 20 includes at least the local status identifier output by the micro-level time window, the current task progress, the progress position of learners in the same group, historical progress records of similar tasks, and the number of help requests. If multiple similar stuck states occur within the meso-level time window, and the current task progress has not reached the preset progress condition, the teaching server 20 can generate a stage stagnation identifier. If there are continuous help requests within the meso-level time window, and the error status has not been recovered, the teaching server 20 can generate a help request density identifier. If a learner submits a procedural output that meets the task requirements after a short pause, the teaching server 20 can generate a recovery identifier. The above preset progress conditions can be determined based on historical operation records, task stage nodes configured by the teacher, or the progress distribution of similar learners. During macro-level time window processing, the data read by the teaching server 20 includes at least the status indicators from multiple meso-level time windows, task completion rates, quality of interim outputs, consecutive failure counts, consecutive recovery records, teacher manual confirmation results, and system scoring results. If multiple meso-level time windows indicate that the learner's current task capacity is insufficient, the teaching server 20 can use a capacity level downgrade flag as part of the learner's status change notification. If the learner continuously completes tasks exceeding their current capacity level, and the output scores meet preset conditions, the teaching server 20 can generate a capacity level upgrade flag. For learners who operate continuously for extended periods, with increased error recovery intervals or higher request-for-help frequencies, the teaching server 20 can enhance the fatigue level field. Updates to learner status data records within the macro-time window can be implemented gradually, meaning the update magnitude of the learner status field is limited for a single task or time window, and changes in ability levels require confirmation through continuous task results or continuous time window status. These measures reduce the impact of occasional misoperations, single errors, or short pauses on long-term learner status data records, while enabling the system to adjust candidate task schemes promptly when learner status continues to change. In another optional implementation, cognitive state drift detection can be preprocessed and initially judged by the edge computing gateway, and then the teaching server 20 can complete the macro-confirmation. This method is suitable for training scenarios involving multiple campuses, multiple computer rooms, or a large number of terminals. The edge computing gateway can receive operation events reported by multiple learner training terminals 10, complete invalid event elimination, micro-state identification, and meso-state initial judgment locally, and upload the meso-state identifier, statistical summary, and anomaly identifier to the teaching server 20. The teaching server 20 then combines course objectives, historical learner state data records, and resource status to complete the macro-confirmation. This method can reduce network bandwidth consumption and cloud processing pressure, and maintain basic operational status recognition capabilities in weak network scenarios. In another optional implementation, the learner-side training terminal 10 can also generate a temporary status identifier locally. This method is suitable for scenarios where the network is temporarily interrupted but the local task can still continue to be executed. The learner-side training terminal 10 can generate a temporary stuck identifier, a temporary stall identifier, or a temporary recovery identifier based on the operation logs, error events, and task progress over a recent period of time, and use the temporary status for local prompts, breakpoint saving, or pausing high-risk operations. After the network is restored, the learner-side training terminal 10 uploads the temporary status and the original events to the teaching server 20 for formal confirmation. In this way, the system can avoid completely losing its awareness of the task execution status during the network interruption, and at the same time prevent the local temporary status from directly bypassing the learner status data update rules on the server side.

[0027] like Figure 5As shown, in step S104, after receiving the learner status change notification, the candidate task scheme generation module 130 generates candidate task schemes based on the skill map, task library, and course objectives. The learner status change notification includes at least the change field, the value before the change, the value after the change, the triggering event, the time window number, the credibility identifier, and the update time. The candidate task scheme generation module 130 first determines the optional skill nodes based on the current course objectives, and then selects target skill points by combining the learner's current ability level, the mastery of prerequisite skills, and the course stage. For skill points whose mastery level is below the preset reinforcement threshold, the teaching server 20 can prioritize generating prerequisite reinforcement tasks; for skill points whose mastery level is above the preset proficiency threshold, the teaching server 20 can reduce the priority of repeated assignments; for skill points whose mastery level is within the preset improvement range, the teaching server 20 can select training tasks from the task library that match the difficulty and resource requirements; for example, the preset improvement range can be set to 0.4 to 0.7, with skill points below 0.4 given priority for prerequisite reinforcement tasks and skill points above 0.7 having their repeated assignment priority reduced; the value of the above range is based on the fact that skill points with low mastery level usually need to have their prerequisite foundation supplemented first, skill points with high mastery level have less value for repeated training, and skill points in the middle range are more suitable as current training targets; this range can be determined based on the skill point pass rate in the course task library, historical training records, teacher configuration rules, and on-site test results; for practical courses with higher difficulty or higher safety risks, the preset reinforcement threshold and preset proficiency threshold can be increased accordingly; Candidate task solutions should include at least the following fields: task number, target skill points, difficulty level, typical time consumption, required resource list, preconditions, collaboration mode, risk level, estimated completion time window, and downgraded alternative flag. The resource list in the candidate task solution can use specific resource numbers, or resource types and resource quantity requirements. For tasks requiring scarce resource support, such as those requiring professional software floating licenses, specific robot workstations, GPU computing nodes, or specific consumable kits, candidate task solutions can be supplemented with alternative resource identifiers or downgraded alternative flags to generate alternative solutions in case of subsequent resource verification failures. By synchronously writing task content, resource requirements, and downgrade information during the candidate task generation stage, it is possible to prevent candidate task solutions from becoming detached from on-site resource conditions. The generation of candidate task schemes should not only be based on learner status data records, but also need to be constrained by resource status. The candidate task scheme generation module 130 can request a resource status summary from the resource digital twin mirror module 140 to determine the currently available workstations, available licenses, available computing power nodes, available consumables, and available simulation mirrors. If the resources required for a task are occupied, faulty, insufficient in reserve, or in an unconfirmed state, the candidate task scheme generation module 130 can reduce the candidate priority of the task, or generate candidate task schemes that include alternative resources, simulation alternatives, guided step-by-step alternatives, and other alternative paths. By incorporating resource requirements and resource status into the candidate task generation process simultaneously, a resource constraint basis can be formed before the task is issued, reducing subsequent resource conflicts. In one possible implementation, the candidate task scheme generation module 130 can process tasks according to functions such as task planning, task matching, resource coordination, teaching strategies, and degraded response. Task planning is used to determine candidate task generation requests based on learner status change notifications and course objectives. Task matching is used to filter target tasks based on skill maps and task libraries. Resource coordination is used to filter available or alternative resources based on resource status data records. Teaching strategy processing is used to generate teaching constraints based on course progress, assessment nodes, and teacher configuration rules. Degraded response processing is used to generate degraded candidate markers based on task risk levels and exception handling rules. The above processes can interact with data through structured fields, which at least include task number, skill node, resource requirements, time window, constraint conditions, and reason code. In this way, the candidate task scheme not only includes teaching task content but also information required for resource usage, execution conditions, and exception handling. When the AI ​​agent is unavailable, times out, or has abnormal candidate result fields, the system can use the rule engine to generate rollback candidate task schemes. The rule engine can read the current learner status field, the most recent valid candidate task scheme, historical task allocation records for the same course stage, resource availability status, and teacher-preset task sequences, and generate rollback candidate task schemes through table lookup matching or state machine rules. Rollback candidate task schemes still need to undergo third-order hard constraint verification and must not be directly sent to the learner's training terminal 10. By setting the rule engine rollback path, the candidate task generation process can be prevented from becoming a single point of failure, and execution layer errors can be avoided when the AI ​​agent outputs missing fields, out-of-bounds fields, or incomplete resource conditions.

[0028] like Figure 6As shown, the resource digital twin mirror module 140 is used to maintain resource status data records for various training resources. The resource status data records include at least the following fields: resource number, resource type, resource location, health status, occupancy status, available time window, resource balance, associated learner identifier, associated task number, most recent heartbeat time, status update time, and status source. Specifically, the health status and occupancy status of workstation resources can be reported by the workstation controller, training room control cabinet, or terminal agent program; the available balance, bound handles, and application latency of software license resources can be reported by the license server; the node load, queue length, and number of available instances of computing power resources can be reported by the computing power resource pool; the available quantity and locked status of consumable resources can be reported by the inventory system, requisition records, or manual confirmation interface; and the number of mirror instances, startup status, and running health status of simulation mirror resources can be reported by the virtual simulation server. By converting different types of resources into resource status data records with a unified field structure, the teaching server 20 can read consistent resource status data before verifying candidate task schemes. Before the candidate task scheme enters the third-order hard constraint verification, the resource digital twin mirror module 140 can perform forced resource synchronization on the key resources involved in the candidate task scheme. Forced resource synchronization means that the processing device actively reads the current status of key resources before the task is issued, instead of relying solely on periodic heartbeat records. For example, when the candidate task scheme involves a specific training workstation, the system can initiate a status query to the workstation controller; when the candidate task scheme involves a software license, the system can query the license balance and application delay from the license server; when the candidate task scheme involves a computing power node, the system can query the available capacity from the computing power resource pool; when the candidate task scheme involves consumables, the system can read the lock records in the inventory system; when the candidate task scheme involves a simulation image, the system can query the image instance status. If the resource query returns a valid status within the preset delay limit, the system will write the returned result into the resource status data record; if the resource query times out, the verification fails, or the status source is unreliable, the system will mark the corresponding resource as having an unconfirmable status and treat it as an unusable resource in subsequent verifications, while recording the resource desynchronization or resource status timeout in the infeasibility reason code. For example, in one implementation, the maximum forced query latency for workstation status, license availability, and computing power resource status can be set to 300 milliseconds. If a valid status is not returned after 300 milliseconds, the corresponding resource is marked as unconfirmable and treated as an unavailable resource. For software license applications, considering license server queuing, network jitter, and handle return processes, the maximum license acquisition latency can be set to 2 seconds. If a valid license handle is not obtained after 2 seconds, the candidate task scheme can be marked as license unavailable. The above values ​​are based on the fact that workstation, license, and computing power status queries within the teaching LAN should typically be within a few hundred milliseconds of response time, while license applications require server confirmation and handle return. Therefore, the license acquisition latency can be set longer than the normal status query latency. In formal implementation, the above latency limits can be adjusted based on resource interface logs, historical response latency, network conditions, and on-site test results. By using forced resource synchronization and treating timeouts as unavailable, the risk of misallocation caused by resource status lag can be reduced. The resource digital twin mirror module 140 can also be configured with different synchronization cycles according to resource type; workstation status and software license status directly affect whether a task can be issued, and usually require high status freshness; the startup, release, and instance number changes of virtual simulation images do not require millisecond-level response, and a medium synchronization cycle can be used; the inventory status of consumables usually changes through requisition, locking, or manual confirmation, and the change frequency is relatively low, so a longer synchronization cycle can be used, and confirmation should be made again before task issuance; for example, the synchronization cycle of workstation status and software license status can be set to 1 second, and can be adjusted between 500 milliseconds and 2 seconds according to the resource interface load; the synchronization cycle of virtual simulation images can be set to 5 seconds to take into account changes in image startup status. The synchronization cycle for consumable inventory status can be set to 60 seconds, with a confirmation performed again before task issuance. The above synchronization cycle is based on the fact that workstation occupancy and license availability directly affect whether a task can be executed immediately, requiring a shorter synchronization cycle. Simulation image startup and release typically do not require high-frequency queries. Consumable inventory changes relatively slowly, so excessively high-frequency synchronization is not advisable. For resources with frequent status changes, the system can also use event-triggered synchronization in addition to periodic synchronization. For example, resource status data records can be updated immediately when a license is applied for, a workstation is released, a simulation image startup fails, or consumable inventory is locked. Combining periodic synchronization and event-triggered synchronization can balance resource status freshness and system communication load. The resource digital twin mirror module 140 can also perform resource pre-occupancy processing before task issuance. For the final task scheme that passes the third-order hard constraint verification, the system can write the workstations, licenses, computing resources, consumables, and simulation images involved in the task scheme into the pre-occupancy status. The pre-occupancy status includes at least the fields of task number, learner identifier, resource number, pre-occupancy start time, expected release time, pre-occupancy source, and release conditions. If the pre-occupancy is successfully written, the task issuance and execution monitoring module 160 generates a task issuance instruction. If the pre-occupancy fails, the system reselects a candidate task scheme or re-enters the resource verification process. In the case of multiple learners competing for the same resource at the same time, the system can perform arbitration based on the pre-occupancy request timestamp, waiting time, remaining class hours, task priority, and collaboration online status. By writing the pre-occupancy status before the task instruction is issued, the execution resource can be locked in advance to avoid the same scarce resource being concurrently allocated to multiple learners.

[0029] like Figure 7 As shown, in step S105, the third-order hard constraint verification module 150 performs pre-task issuance verification on the candidate task scheme; this verification is used to determine whether the candidate task scheme can be actually executed in the current training environment, and the verification content includes resource availability verification, learner acceptance boundary verification and teaching constraint consistency verification. Resource availability verification is used to determine whether the resources required for a candidate task plan meet the execution conditions. The teaching server 20 reads the resource list in the candidate task plan and compares the resource list with the latest resource status data in the resource digital twin mirror. The resource availability verification includes at least whether the task project has been put on the shelf, whether the training workstation is healthy and not occupied, whether there is available spare software license and it can be obtained within the allowed time, whether the computing power node meets the task operation requirements, whether the consumable inventory is sufficient, whether the simulation mirror can be started, and whether the resource availability time window matches the task's expected time window. If any required resource is unavailable, the system generates a resource unavailability reason code and attempts to perform alternative resource verification based on the alternative resource identifier in the candidate task plan. If the alternative resource is still unavailable, the candidate task plan is intercepted and will not proceed to subsequent verification. Through resource availability verification, the candidate task plans generated by the AI ​​agent can be constrained by the real-world resource status, preventing the candidate tasks from deviating from the actual execution conditions. Learner acceptance boundary verification is used to determine whether the learner's current state is suitable for accepting candidate tasks. The teaching server 20 reads learner status data records, learner status change notifications, and information such as task difficulty, prerequisite skills, safety qualifications, collaboration requirements, and estimated time consumption in the candidate task plan, and determines whether the learner's current ability status matches the requirements of the candidate task. The content of learner acceptance boundary verification includes at least whether the mastery of prerequisite skills meets the preset conditions, whether the current ability level can accept the difficulty of the candidate task, whether the safety qualifications meet the equipment operation requirements, whether the fatigue level is lower than the unsuitable execution condition, whether the consecutive failure count exceeds the downgrade trigger condition, whether the members required for the collaborative task are online, and whether the learner's current terminal has the execution environment. For example, in one implementation, when the pre-requisite node mastery reaches 0.6 or higher, the learner can be deemed to have met the corresponding pre-requisite skill requirements. This value is based on the premise that the learner is suitable to undertake subsequent tasks only after the pre-requisite node reaches a basic usable level. Specific thresholds can be adjusted based on course prerequisites, historical pass records, and teacher configuration rules. The fatigue field can use a state value between 0 and 1; when the fatigue level reaches or exceeds 0.75, the learner is deemed unsuitable to directly undertake high-difficulty tasks. When the consecutive failure count exceeds 3, the current task difficulty or execution method can be determined to have exceeded the learner's current capacity. The aforementioned fatigue threshold and consecutive failure threshold can be determined based on the course task intensity, continuous operation duration, historical failure recovery records, teacher configuration rules, and on-site test results. For high-risk physical equipment operation tasks such as robot assembly, electrical wiring, and CNC machining, the fatigue threshold and consecutive failure threshold can be set more conservatively. For purely software simulation tasks, these thresholds can be appropriately relaxed based on teacher configuration. If a learner fails the boundary verification, the system can adjust the candidate task to a pre-reinforcement task, a guided step-by-step task, or a simulation replacement task. If the verification failure is due to insufficient safety qualifications, excessive fatigue, or too many consecutive failures, the system can refuse to issue high-risk practical tasks and send a confirmation request to the teacher workstation 40. By verifying the learner's acceptance boundary, the system can avoid issuing tasks that the learner cannot currently accept based solely on static learner status data records or partial task matching results. The teaching constraint consistency check is used to determine whether candidate task schemes conform to the current course schedule and teaching execution order. The teaching server 20 reads the course objectives, assessment nodes, group progress, task dependencies, and configuration records in the teacher workstation 40, and determines whether the candidate task scheme is in the current course's allowed stage, whether it meets the prerequisites for assessment nodes, whether it covers the current teaching objectives, whether it conflicts with the group's collaborative rhythm, whether it will occupy the necessary resources required for subsequent assessments, and whether it conflicts with the teacher's manual locking arrangement. For cross-group collaborative training, the system can also determine whether the online status, task stage, and resource availability window of the collaborative members are consistent. If the teaching constraint consistency check fails, the system can add the candidate task scheme to the infeasible set and record reason codes such as course progress mismatch, assessment node conflict, collaborative member non-compliance, or teacher locking conflict. Through the teaching constraint consistency check, the personalized task arrangement of individual learners can be kept consistent with the overall course rhythm, assessment nodes, and collaborative tasks, avoiding the task distribution from disrupting the teaching execution order. In one optional implementation, the execution order of the third-order hard constraint verification can be adjusted according to the risk level or resource scarcity of the training task. For high-risk physical equipment operation tasks, such as robot assembly, electrical wiring, and CNC machining, learner safety qualification and fatigue verification can be performed first, followed by resource availability verification and teaching constraint consistency verification. For tasks with highly scarce resources, such as GPU cluster tasks, specific software license tasks, or unique physical workstation tasks, resource forced synchronization and resource pre-verification can be performed first, followed by learner acceptance boundary verification. Regardless of the verification order, resource availability, learner acceptance boundary, and teaching constraint consistency should all be completed before the task is issued. If any necessary verification fails, the system must not generate a formal task issuance instruction. The output of the third-order hard constraint verification includes at least the verification pass result, failure reason code, and rollback request fields. The failure reason code includes at least the following: resource unavailability, resource query timeout, insufficient license, insufficient computing power, insufficient consumables, unavailable simulation image, insufficient prerequisite skills, mismatched ability level, insufficient security qualifications, excessive fatigue, too many consecutive failures, offline collaborators, mismatched course stage, conflicting assessment nodes, and conflicting teacher lockouts. The rollback request can be sent to the candidate task scheme generation module 130, which can trigger alternative resource selection, task downgrading, task reselection, or manual confirmation. By outputting clear failure reason codes and rollback requests, the system can determine the specific reasons why the candidate task scheme is not executable, which facilitates subsequent scheduling adjustments and traceability of operation records.

[0030] In step S106, after the candidate task scheme passes the third-order hard constraint verification, the task issuance and execution monitoring module 160 determines the final task scheme. If there are multiple candidate task schemes that pass the verification, the teaching server 20 can sort them according to the degree of matching between the candidate task and the current ability level, the degree of matching between the estimated time and the remaining class hours, the resource utilization, the synchronization degree of collaborating members, the priority of teacher configuration, and the completeness of the downgraded alternatives. The sorting rules can be determined by teacher configuration, historical operation records, or preset strategies of the training platform. After the teaching server 20 selects the final task plan, it first calls the resource digital twin mirror module 140 to write the resource pre-occupancy status, and then generates a task issuance instruction. The task issuance instruction includes at least the following fields: instruction number, learner identifier, task number, task parameters, target workstation, software license handle, computing power resource handle, consumable collection identifier, simulation mirror instance identifier, estimated completion time window, downgrade alternative flag, and acceptance confirmation requirements. After receiving the task issuance instruction, the learner-side training terminal 10 returns acceptance confirmation, environment startup status, and task start time. If the learner-side training terminal 10 does not return acceptance confirmation within the preset confirmation time, the system releases the written pre-occupancy resources and marks the task as unsuccessfully issued. The preset confirmation time can be configured based on terminal startup response latency, teaching LAN communication latency, task environment loading time, and on-site test results. It can also be the upper limit or high percentile of the startup time of similar historical task environments, plus the teaching LAN communication jitter margin. For tasks that only require opening the local task page, the preset confirmation time can be shorter than that of tasks that require starting a simulation image, applying for a software license, or loading a large engineering environment. By releasing pre-occupied resources when receiving confirmation failure, resources can be avoided from being occupied for a long time by unsuccessfully sent tasks. During task execution, the task issuance and execution monitoring module 160 continuously receives the task execution status. The task execution status includes at least the following fields: task start status, resource handle validity status, procedural output submission status, stage progress completion status, number of errors, number of requests for help, terminal heartbeat, resource call status, and task end status. If the learner successfully completes the task, the system enters a closed-loop feedback and learner status data update process. If the learner encounters problems such as getting stuck, resource abnormalities, terminal offline, device failure, or network interruption, the system will send the corresponding abnormal event to the abnormality classification and degradation control module 170. By continuously receiving the task execution status, the task issuance process is no longer a one-time instruction transmission, but a dynamic control process that can be confirmed, paused, downgraded, resumed, or released based on the execution process.

[0031] like Figure 8As shown, in step S107, the anomaly classification and degradation control module 170 determines the anomaly level based on the anomaly type, scope of impact, duration, and task degradability flag, and generates corresponding anomaly handling instructions. The anomaly types include at least learner status anomalies, resource status anomalies, communication anomalies, candidate task scheme anomalies, execution environment anomalies, teacher manual intervention conflicts, and security incidents. The scope of impact includes at least a single learner, a single training station, a single type of resource, a single group of learners, the entire computer room, and the entire platform. The duration can be determined based on terminal heartbeat timeout, resource retries, recovery signals, and resource status confirmation results. The task degradability flag can be pre-written into the candidate task scheme to indicate whether the task supports simulation substitution, guided step-by-step training, breakpoint continuation training, backup station, manual takeover, or direct termination. For example, in one possible implementation, the anomaly level can be divided according to the scope and duration of impact; an anomaly occurring in a single learner, a single terminal, or a single resource, and lasting no more than 30 seconds, can be classified as a local disturbance; an anomaly lasting more than 30 seconds but no more than 5 minutes, and affecting only a single group of learners or a single type of resource, can be classified as a regional impact; an anomaly lasting more than 5 minutes, or affecting the entire computer room or multiple resource types, can be classified as a system-level fluctuation; anomalies involving personal safety, serious equipment damage, data leakage, or malicious attacks can be directly classified as unrecoverable events; the aforementioned 30 seconds are used to cover common terminal heartbeat loss, short-term network jitter, and single resource retry processes; the aforementioned 5 minutes are used to distinguish between short-term recoverable anomalies and continuous anomalies sufficient to affect the course rhythm; the aforementioned time boundaries can be adjusted based on the terminal heartbeat cycle, resource interface retry cycle, course task interruption tolerance time, and on-site test records; For local disturbances, the system can prioritize retrying, refreshing resource handles, restarting the simulation image, or prompting learners to check their local environment. For regional impacts, the system can perform group-level replanning, reselecting resources for affected learners or switching to simulation alternative mode, while unaffected learners continue to execute their original tasks. For system-level fluctuations, the system can pause the issuance of new tasks globally, retain the breakpoint state of already executed tasks, and reissue tasks in batches after resources are restored. For unrecoverable events, the system stops automatic scheduling and outputs a manual takeover signal to the teacher workstation 40 or the security management terminal. By selecting the corresponding handling method according to the scope and duration of the anomaly's impact, the system can avoid triggering a global rescheduling due to a single point of failure and prevent serious anomalies from being automatically ignored by the system. The degradation modes include at least the following: online full-function mode, simulation replacement mode, guided step-by-step mode, breakpoint resume mode, and manual takeover mode. The online full-function mode is used in scenarios where both resource and network status are normal, allowing learners to execute the complete task. The simulation replacement mode is used in scenarios where physical equipment is unavailable but the simulation image is available; in this mode, the physical workstation identifier in the task issuance instructions can be replaced with the simulation image instance identifier. The guided step-by-step mode is used in scenarios where learners have insufficient capacity, experience continuous failures, or are highly fatigued; in this mode, the system breaks down the original task into multiple stage instructions and issues the next instruction only after the current stage is completed. The first phase of the task; the breakpoint resume training mode is used for scenarios with short-term network interruptions or temporary terminal offline. In this mode, the learner's training terminal 10 locally caches task parameters and phase outputs, and uploads the breakpoint record and continues execution after the connection is restored; the manual takeover mode is used for scenarios where automatic scheduling is not suitable to continue. In this mode, the system stops automatically issuing new tasks, retains resource occupancy status and task status records, and resumes or terminates the task after confirmation by the teacher; through the above degradation modes, the system can not only output alarm information when an anomaly occurs, but also change the task execution path, resource occupancy status and subsequent scheduling method, so that the anomaly handling has clear execution actions; In one optional implementation, the recovery from the degraded mode can be based on a stabilization time condition. If the abnormal signal has disappeared, but the resource heartbeat, terminal connection, or execution environment has not yet stabilized continuously for the preset recovery time, the system maintains the current degraded mode and does not immediately recover to the online full-function mode. If the continuous stabilization time meets the recovery condition, the system first restores candidate task generation and resource synchronization, then restores task distribution in batches, and finally releases the degraded flag. For example, the stabilization time can be set to 2 minutes. For local disturbances with a small impact range that have already completed retry recovery, the stabilization time can be shortened to 1 minute. For system-level fluctuations, the stabilization time can be extended to 5 minutes. 2 minutes is used to observe whether the resource heartbeat, terminal connection, and execution environment are stable. 1 minute is suitable for rapid confirmation after single-point anomaly recovery. 5 minutes is suitable for continuous confirmation of the status of multiple resource interfaces and multiple terminals after system-level fluctuations. The above-mentioned stabilization time can be configured according to the anomaly level, resource type, terminal heartbeat cycle, resource interface stability, and on-site test records. By setting recovery conditions, frequent switching of the degraded mode can be prevented due to network jitter or short-term resource recovery. Anomaly handling can also cover situations such as candidate task plan field anomalies, resource status desynchronization, multiple learners competing for the same resource, conflicts arising from teacher manual intervention, and learners actively withdrawing or returning. For candidate task plan field anomalies, the third-order hard constraint verification module 150 checks whether the candidate task plan includes at least the following fields: task number, target skill points, difficulty level, resource list, estimated time window, downgraded alternative marker, and source identifier. If the candidate task plan lacks key fields, the field type does not conform to the preset format, the resource list is empty but the task requires resources, the estimated time window exceeds the available time of the course, or the difficulty level exceeds the range defined by the course, then the candidate task plan is marked as having field anomalies, and the candidate task plan is intercepted or returned to the candidate task plan generation module 130. If candidate task plan field anomalies occur continuously, the system can switch to the rule engine rollback method to generate candidate task plans. When resource status becomes out of sync, the resource digital twin mirror module 140 marks the corresponding resource as unconfirmable and treats it as an unavailable resource during the verification process, while simultaneously triggering an active retrieval of the physical resource status. If retrieval fails continuously, the resource is marked as an offline resource, and an exception response is triggered. When multiple learners compete for the same resource, the system can determine resource occupancy rights based on the pre-request timestamp. In the event of a timestamp conflict, the system can arbitrate based on remaining class hours, waiting time, collaborative online status, and teacher configuration priority. For conflicts requiring manual teacher intervention, the teacher workstation 40 can forcibly suspend a specific learner's session. The system can assign tasks to learners, lock resources, or confirm recovery from an anomaly, but resource security checks and learner security qualification checks should not be automatically bypassed. For learners who actively exit or return, the system can save the intermediate state, release resources, or set a pending review status. Upon the learner's re-login, the system will first check fatigue levels, resource availability, and task version consistency before determining whether to continue the original task. These anomaly handling rules cover common anomalies during task execution and ensure that anomaly handling results can be returned to resource verification, task reselection, degraded execution, or manual confirmation processes.

[0032] like Figure 9As shown, in step S108, after the task is completed, interrupted, or downgraded, the closed-loop feedback and learner status data update module 180 collects the task execution results. The task execution results include at least the following fields: task completion degree, stage completion order, final output, output score, cumulative time, effective operation time, number of errors, number of similar errors, number of requests for help, number of teacher interventions, downgrade mode record, exception reason code, and resource release record. The automatic evaluation component performs rule-based scoring on the output according to the task type. For example, for programming tasks, the automatic evaluation component can verify the running results, test case pass status, code style, and performance indicators. For configuration tasks, the automatic evaluation component can verify the configuration file fields, running results, and security rules. For assembly tasks, the automatic evaluation component can verify step confirmation, sensor status, operation sequence, and final detection results. The scoring rules can be configured by the course task library, set by the teacher workstation 40, or determined by the standard answers of historical tasks, and model training is not required. The closed-loop feedback and learner status data update module 180 updates the learner status data record based on the task execution results. For the skill mastery field, the system can perform progressive updates based on task completion, output score, and error recovery, and set an upper limit on the update magnitude caused by a single task. This upper limit can be determined based on historical status data fluctuation records, course task difficulty, teacher configuration rules, or on-site test results to avoid excessive jumps in the learner status field caused by a single accidental high score, a single abnormal failure, or a single short-term network failure. For example, in one possible implementation, a single task only updates the skill point corresponding to the task and the prerequisite skill points directly associated with that skill point, without synchronously updating irrelevant skill points. The single update magnitude of the skill mastery field is lower than the interval between adjacent ability levels, and the specific magnitude is determined by teacher configuration rules or historical status data fluctuation records. For the ability level field, the system can require two consecutive macro time windows or two consecutive task results to be consistent before confirming whether the ability level increases or decreases. For the fatigue level field, the system can increase or decrease the level based on continuous operation duration, error recovery interval, help density, and rest time. For the consecutive failure count field, the system can increase the count when a task fails, fails after being downgraded, or the same type of error occurs repeatedly, and decrease or reset the count after the learner completes a similar reinforcement task or the teacher confirms that the learner has mastered the skill. For the safety qualification field, the system only updates the count based on the teacher's confirmation, assessment results, or equipment operation permit records, and does not automatically increase it based on ordinary runtime events. Through the above progressive updates, the next round of task scheduling can reflect the learner's actual execution status, while reducing frequent task jumps caused by short-term noise. Resource release records are also part of the closed-loop feedback. After a task is completed, canceled, a learner exits, an abnormal interruption occurs, or manual takeover occurs, the task issuance and execution monitoring module 160 sends a resource release request to the resource digital twin mirror module 140. The resource release request includes at least the following fields: task number, learner identifier, resource number, release reason, release time, and terminal confirmation status. Before releasing the resource, the resource digital twin mirror module 140 confirms whether the resource handle is still occupied, whether the learner's training terminal 10 has stopped using the corresponding resource, whether the software license has been returned, whether the simulation mirror has been closed, and whether consumables need to be manually verified. If the release confirmation fails, the system marks the corresponding resource as pending review, instead of directly marking it as idle. Through resource release confirmation, the incorrect release of resource status after an abnormal interruption can be avoided, thereby preventing subsequent tasks from repeatedly allocating the same resource. For example, in a data analysis training course, the training environment is equipped with multiple cloud development workstations, professional software floating licenses, and a unified computing resource pool. After a learner logs in, the system reads the learner's historical training records and current course objectives to establish an initial state data record. When the learner performs data cleaning tasks, the learner's training terminal 10 continuously reports code execution, error reporting, saving, and submission events. Within a micro-time window, the system identifies that the learner has encountered the same error repeatedly in the same data reading step, and within a meso-time window, it identifies that the task progress is lower than the normal progress of similar tasks, accompanied by a help request event. After the macro-time window confirms that the state persists, it generates a learner state change notification indicating a temporary decrease in the learner's current capacity. The candidate task scheme generation module 130 generates candidate task schemes such as a complete data cleaning task and a guided step-by-step data cleaning task based on the learner status change notification. The resource digital twin mirror shows that the professional software licenses required for the complete data cleaning task are insufficient, while the guided step-by-step data cleaning task can be executed in the current cloud development environment. The third-order hard constraint verification module 150 generates a license insufficiency reason code for the complete data cleaning task and intercepts it. For the guided step-by-step data cleaning task, it performs resource availability verification, learner acceptance boundary verification, and teaching constraint consistency verification. After the verification is passed, the system issues the guided step-by-step task instruction and writes the corresponding cloud development workstation into the pre-occupancy status. After the task is completed, the system retrieves the output score and error recovery record to reduce the consecutive failure count and progressively updates the mastery of the corresponding skill points. Thus, task adjustment is not just a simple learning suggestion, but an execution control process that involves resource status interception, task instruction issuance, and closed-loop update of learner status data records. For example, in a robot assembly training course, a physical robot workstation reports a controller malfunction, which affects subsequent practical tasks for learners in the same group. The resource digital twin mirror module 140 marks the workstation as unavailable during forced resource synchronization. The anomaly classification and degradation control module 170 determines the anomaly as a group-level anomaly based on the scope of its impact and reads the degradation candidate flag from the candidate task scheme. If the task supports simulation substitution, the system issues the corresponding simulation mirror task to the affected learners and retains the original physical workstation's maintenance reason code. If the task requires the use of physical equipment, the system reselects a backup workstation and performs resource verification, or sends a manual confirmation request to the teacher workstation 40. Other learners not affected by the workstation malfunction continue to execute the original task without triggering a global rescheduling. Through this processing method, the system can limit equipment anomalies to their actual impact range and reduce the spread of local faults to global task scheduling.

[0033] like Figure 10 As shown, in weak network or offline scenarios, the learner-side training terminal 10 can cache the issued task instructions, resource handles, stage outputs, and local temporary states. If the communication connection between the learner-side training terminal 10 and the teaching server 20 is interrupted, and the current task does not involve high-risk physical equipment operation, the learner-side training terminal 10 can enter the breakpoint resume training mode, allowing the learner to continue completing the current task stage. In the breakpoint resume training mode, the learner-side training terminal 10 records information such as stage completion time, output version, abnormal events, and task execution progress locally. After the network is restored, the breakpoint record is uploaded to the teaching server. After receiving the breakpoint record, the teaching server 20 first checks whether the resource pre-occupancy status is still valid, and then checks whether the task version is consistent with the server-side record. If the resource pre-occupancy status is valid and the task version is consistent, the training continuation result is confirmed, and the learner status data update process is entered. If the resource has been released, the resource handle has expired, or the task version is inconsistent, a manual confirmation request is sent to the teacher workstation 40, or the continuation task is reissued. By combining local caching and server confirmation, the continuity of task execution can be maintained in a weak network environment, while avoiding the execution results generated in the offline state from directly overwriting the server-side record. In training scenarios with high privacy protection requirements, the method of this application embodiment may not collect camera images, microphone voice, facial expressions, or other sensitive information, but only collect data within the authorized scope that is directly related to task execution; the aforementioned data includes at least operation logs, task submission records, procedural outputs, help events, and terminal operating status; the identification of the learner's current task acceptance status can be completed based on error frequency, pause duration, submission interval, task progress, and help density, without relying on sensitive biometric information; if the school or enterprise allows the collection of more terminal environmental signals, such signals can also be used as auxiliary judgment information within the authorized scope, but are not a necessary condition for the main process of this application; thus, the embodiments of this application can be applied to training environments under different privacy compliance requirements, and its core processing is still based on runtime events, resource status verification, anomaly degradation, and feedback updates to form a closed loop; Different types of practical training courses can access different resources. For information technology training, resources may include cloud development environments, software licenses, computing nodes, and simulation images. For intelligent manufacturing training, resources may include physical workstations, robots, fixtures, sensors, and consumable kits. For network operation and maintenance training, resources may include virtual network topologies, device images, account permissions, and simulation instances. For industrial control training, resources may include controllers, input / output modules, simulation equipment, and safety interlock status. Although the types of resources differ in different scenarios, they can all be executed according to the process of runtime data acquisition, current task acceptance status identification, candidate task generation, resource status verification, hard constraint verification before task issuance, anomaly degradation, and closed-loop update. The time window length, synchronization cycle, forced resource synchronization delay, anomaly duration, mastery interval, prerequisite skill threshold, fatigue threshold, consecutive failure threshold, preset confirmation time, preset recovery time, and learner status data update range mentioned above are all parameter ranges or values ​​provided for ease of implementation. In actual deployment, these parameters can be adjusted based on equipment capabilities, network conditions, task type, historical operation records, on-site test results, or teacher configuration. These parameters provide clear judgment boundaries for candidate task generation, resource verification, anomaly degradation, and learner status data updates, enabling the system to complete automatic processing according to preset rules and reducing reliance on subjective human judgment. After adopting the above implementation method, the learner-side training terminal 10 continuously reports runtime data, and the teaching server 20 confirms the changes in the learner's current task acceptance status according to multi-layer time windows; therefore, when learners experience continuous errors, periodic stagnation, frequent requests for help, or skill enhancement, the system can adjust the candidate task scheme accordingly, while avoiding frequent fluctuations in learner status data records due to single misoperations, occasional errors, or short pauses; the resource digital twin mirror module 140 synchronizes the status of resources such as workstations, licenses, computing power, consumables, and simulation images before task issuance, so that the candidate task scheme can be consistent with the actual resource status on site, reducing the situation where occupied resources, offline resources, or insufficient resources are repeatedly allocated; three The hard constraint verification module 150 performs resource availability verification, learner acceptance boundary verification, and teaching constraint consistency verification before task issuance. It can intercept unexecutable tasks before candidate tasks enter the execution layer, preventing candidate task schemes generated by the AI ​​agent from being converted into terminal execution instructions without verification. The anomaly classification and degradation control module 170 can select processing methods such as local retry, group-level replanning, pausing new task issuance, or manual takeover based on the scope and duration of the anomaly's impact, reducing the spread of local anomalies to global scheduling. The closed-loop feedback and learner status data update module 180 progressively updates learner status data records based on task execution results, making subsequent task allocation more consistent with the learner's actual acceptance capacity and resource operation status. The method of this application embodiment can be executed by a processing device having a processor, a memory, a communication interface, and a resource interface; the processing device can be a teaching server 20, an edge computing gateway, a teaching cloud platform server, a training room control device, or a combination of the above devices; the memory can store data such as course objectives, skill maps, task libraries, learner status data records, resource digital twin images, parameter configurations, exception reason codes, degradation mode tables, and historical running records; when the processor executes the program or instructions stored in the memory, it can realize steps such as runtime data acquisition, time window processing, candidate task generation, third-order hard constraint verification, task issuance, exception degradation, and closed-loop learner status data update; the communication interface can communicate with the learner-end training terminal 10, teacher workstation 40, resource pool 30, license server, computing power resource pool, consumable system, and virtual simulation server; through the above hardware and software cooperation, an implementable execution basis can be provided for the method of this application embodiment; In practical implementation, those skilled in the art can make adaptive adjustments to the data collection source, time window length, resource synchronization cycle, verification order, anomaly level, degradation mode, and feedback update rules according to the training environment; the above adjustments do not change the basic processing method of this application to achieve dynamic scheduling of training tasks through runtime data collection, resource status verification, hard constraint verification before task issuance, anomaly degradation, and closed-loop update.

[0034] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0035] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for dynamic scheduling of training tasks based on AI intelligent agents, characterized in that, include: Acquire course objective information, learner basic status data, and practical training resource information; establish course objective data records, learner initial status data records, and resource digital twin mirrors. Collect learner runtime perception information, preprocess the learner runtime perception information, and obtain a standardized runtime event stream; Based on the standardized runtime event stream, the changes in the learner's current task acceptance status are identified, and a learner status change notification is generated. Candidate task schemes are generated based on the learner status change notification, skill map, task library, and course objectives. Synchronize the resource status involved in the candidate task schemes and perform hard constraint verification on the candidate task schemes before task issuance; After successful verification, write the resource pre-occupancy status and generate the task issuance instruction; Perform abnormal degradation processing based on the task execution status, and update the learner status data record based on the task execution result.

2. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Obtain information on course objectives, learners' basic status data, and practical training resources, including: The course objective information can be obtained from the course syllabus, practical training task library, skill map configuration file, assessment node schedule, or teacher workstation configuration records; The learner's basic status data is formed based on the prior course grades, entrance assessment results, historical training records, completed task records, teacher manual confirmation results, or learner status data update records after the last training session. The training resource information is obtained from the resource pool, software license server, computing power scheduling platform, training workstation controller, consumable inventory system, or virtual simulation server.

3. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, The learner's runtime perception information is preprocessed to obtain a standardized runtime event flow, including: Collect operation logs, as well as at least one of the following: process outputs, task submission records, terminal running status, operation rhythm, or help requests; The collected data is preprocessed locally, including at least one of the following: removing meaningless characters, filtering mouse jitter, merging duplicate reported events of the same type, adding missing identifiers, temporarily storing data that exceeds the scope of the current task, and adding a checksum. A unified time base is used to normalize the timestamps of events from different data channels; Transform events from different sources into the standardized runtime event stream.

4. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Based on the standardized runtime event flow, the system identifies changes in the learner's current task acceptance status and generates a learner status change notification, including: Identify local operational states over a short period of time using microscopic time windows; By aggregating the local operational states within multiple micro time windows through meso-level time windows, we can determine the stage of stagnation, the state of intensive requests for help, or the state of recovery. By combining the judgment results of multiple meso-level time windows, the task completion rate, the quality of phased outputs, the count of consecutive failures, and the teacher's confirmation results, it is determined whether to generate the learner status change notification.

5. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 4, characterized in that, The microscopic time window, the mesoscopic time window, and the macroscopic time window are determined based on the type of training task, the terminal's acquisition and response capabilities, the typical time consumption of task steps, historical operation records, or on-site calibration results. The training task types include programming training tasks, data analysis training tasks, network configuration training tasks, assembly training tasks, electromechanical training tasks, or CNC training tasks.

6. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Based on the learner status change notification, skill map, task library, and course objectives, candidate task schemes are generated, including: Determine optional skill nodes based on the current course objectives; Select target skill points by combining the learner's current ability level, prior skill mastery, and course stage; Based on the target skill points, select training tasks from the task library that match the difficulty and resource requirements; Generate candidate task plans, wherein the candidate task plans include at least one of the following: task number, target skill points, difficulty level, typical time consumption, required resource list, preconditions, collaboration mode, risk level, expected completion time window, and downgrade alternative flag.

7. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Generate candidate task schemes, including: Request a resource status summary, and determine the currently available workstations, available licenses, available computing nodes, available consumables, and available simulation images based on the resource status summary; If the resources required for a task are occupied, faulty, insufficient, or in an unconfirmed state, reduce the candidate priority of the corresponding task, or generate a candidate task scheme that includes at least one alternative path among alternative resources, simulation alternatives, and guided distribution. In cases where the AI ​​agent is unavailable, the response times out, or the candidate result field is abnormal, a rule engine is used to generate a rollback candidate task scheme, and the rollback candidate task scheme is sent to the hard constraint verification before task issuance.

8. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Synchronizing the resource status involved in the candidate task schemes includes: Maintain resource status data records for various training resources. The resource status data records include at least one of the following: resource number, resource type, resource location, health status, occupancy status, available time window, resource balance, associated learner identifier, associated task number, last heartbeat time, status update time, and status source. Before the candidate task scheme enters the hard constraint verification before task issuance, the key resources involved in the candidate task scheme are subject to forced resource synchronization. If the resource query returns a valid status, the result will be written to the resource status data record. If a resource query times out, fails to verify, or the source of the status is unreliable, the corresponding resource will be marked as having an unverifiable status and treated as an unavailable resource in subsequent verifications.

9. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Perform hard constraint verification on the candidate task schemes before task issuance, including: Perform resource availability verification to determine whether the resources required by the candidate task plan meet the execution conditions; Perform learner acceptance boundary verification to determine whether the learner’s current ability status matches the requirements of the candidate task; Perform a consistency check of teaching constraints to determine whether the candidate task schemes conform to the current course schedule and teaching execution order; If the necessary checks in resource availability verification, learner acceptance boundary verification, and teaching constraint consistency verification fail, no formal task issuance instruction will be generated.

10. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, After successful verification, the resource pre-occupancy status is written and a task issuance instruction is generated, including: Write the final task plan that has passed the hard constraint verification before task issuance into the resource pre-occupancy status; If the resource pre-occupancy status is successfully written, a task issuance instruction will be generated. If the learner's training terminal does not return a confirmation of receipt, release the pre-occupied resources that have been written and mark the corresponding task as unsuccessfully sent. During task execution, the task execution status is continuously received. The task execution status includes at least one of the following: task start status, resource handle valid status, procedural output submission status, stage progress completion status, number of errors, number of requests for help, terminal heartbeat, resource call status, and task end status.

11. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Perform exception degradation handling based on task execution status, including: The anomaly level is determined based on the anomaly type, scope of impact, duration, and task degradability flag; An exception handling instruction is generated based on the exception level. The exception handling instruction includes at least one of the following: retry, refresh resource handle, restart simulation image, replace resource, switch simulation, resume training from breakpoint, pause new task issuance, or manual takeover. The anomaly types include at least one of the following: learner status anomaly, resource status anomaly, communication anomaly, candidate task scheme anomaly, execution environment anomaly, teacher manual intervention conflict, or security incident.

12. The method for dynamic scheduling of training tasks based on AI intelligent agents according to claim 1, characterized in that, Update learner status data records based on task execution results, including: The task execution results include at least one of the following: task completion rate, stage completion order, final output, output score, cumulative time, effective operation time, number of errors, number of similar errors, number of requests for help, number of teacher interventions, degradation mode records, abnormal reason codes, and resource release records. The skill mastery field is updated incrementally based on task completion, output rating, and error recovery. Confirm changes in capability levels based on the results of consecutive tasks or the status of consecutive time windows; The fatigue level field is updated based on continuous operation duration, error recovery interval, help frequency, and rest time. The consecutive failure count field is updated based on whether the task fails, fails after being downgraded, repeats the same type of error, completes the same type of reinforcement task, or the teacher confirms the result. Before releasing resources, confirm the resource handle occupancy status, learner training terminal resource usage status, software license return status, simulation image closure status, and consumable verification status. If the release confirmation fails, mark the corresponding resource as pending review.

Images