Context-aware multi-phase task scheduling system and method

Abstract

The application provides a context-aware multi-stage task scheduling system and method, which comprises an input layer, a scheduling layer and a core engine layer; the input layer acquires and analyzes a task object; the core engine layer comprises a plurality of execution engines combined and connected in series on demand, the execution engines being separated from engine instances; the scheduling layer undertakes two-stage scheduling: first-stage adaptive scheduling, which decides an execution engine list and sequence to be enabled according to context information before the task starts; and second-stage callback scheduling, which receives a state data packet, matches an output scheduling decision instruction according to an initialization configuration and a fixed threshold rule that does not change, and performs a life cycle management operation; the two stages form a closed-loop control loop of execution, state feedback, rule matching and instruction issuing; the scheduling decision instruction comprises a push, a return, a jump and an end instruction, which respectively trigger switching, reinitialization, switching to a target instance and destruction operations; the jump instruction is used for suspending a current instance and activating an upstream engine instance.

Description

Technical Field

[0001] This invention belongs to the field of computer scheduling technology, specifically relating to a context-aware multi-stage task scheduling system and method. Background Technology

[0002] With the popularization of artificial intelligence technology, interactive systems based on large language models and intelligent agents are widely used in the automated processing of various complex tasks. Existing interactive systems, when handling multi-stage, long-cycle nonlinear tasks, typically employ a fixed linear execution flow. Functional modules advance solely through simple sequential connections, lacking the ability to dynamically schedule and adjust paths based on input context information. When abnormal states or consecutive errors occur during task processing, existing systems often fail to automatically switch processing strategies or safely exit and reclaim resources when ineffective attempts reach their limit, easily leading to system loops or resource exhaustion.

[0003] Furthermore, the scheduling logic of existing systems is typically tightly coupled with specific application business logic, with process control hard-coded into the system's core code. This makes it difficult to dynamically configure scheduling strategies, and when a new processing stage needs to be introduced or the execution logic adjusted, the underlying system code must be modified, resulting in a lack of scalability and cross-platform reusability. Simultaneously, when handling multi-round interactive tasks, existing technologies lack mechanisms for effective lifecycle management of running instances, making it difficult to achieve precise and controllable transitions between different running states of instances. This leads to insufficient robustness of the system when facing non-deterministic interactive inputs.

[0004] Some existing solutions attempt to introduce dynamic routing mechanisms based on large model inference, where a large language model directly generates the next scheduling decision based on the current context. However, these solutions have inherent drawbacks: the scheduling decision itself relies on large model inference, introducing additional non-determinism, resulting in unpredictable and unreproducible processes; each scheduling decision consumes significant computational resources and inference overhead, with scheduling costs increasing with task complexity; and the scheduling logic is embedded in the model inference process, making it difficult to debug, verify, and maintain independently.

[0005] Therefore, how to achieve flexible, controllable and scalable task flow scheduling in multi-stage long-cycle interactive tasks, and overcome the problems of rigid processes, coupling of scheduling and execution logic and lack of state feedback control in existing technologies, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0006] To address the shortcomings and deficiencies of existing technologies, this invention provides a context-aware multi-stage task scheduling system and method. The system comprises an input layer, a scheduling layer, and a core engine layer. The scheduling layer performs two-stage scheduling functions: the first stage is adaptive scheduling, which determines the list of execution engines to be used and their execution order based on context information before the task begins; the second stage is callback scheduling, which receives status data packets from each execution engine during task execution, matches and outputs scheduling decision instructions according to fixed threshold rules configured once during system initialization and remaining unchanged during operation, and performs lifecycle management operations on running engine instances. The core engine layer contains multiple execution engines that are combined on demand and sequentially connected. Execution engines are separated from engine instances; the same execution engine can create multiple independently running engine instances for different inputs. The scheduling layer and the core engine layer form a closed-loop control circuit encompassing execution, status feedback, rule matching, and instruction issuance to execution. Scheduling decision instructions include advance instructions, return instructions, jump instructions, and termination instructions, which respectively trigger engine instance switching, re-initialization, switching to the target instance, and destruction operations. The jump instruction suspends the current engine instance and initializes / activates a specified upstream engine instance, enabling cross-engine non-sequential error recovery. This invention combines a deterministic scheduling mechanism driven by fixed threshold rules with engine instance-level lifecycle management, establishing a deterministic control foundation in non-deterministic interaction scenarios, achieving precise and controllable scheduling of multi-stage nonlinear interaction tasks.

[0007] The specific technical solution adopted by this invention to solve its technical problem is as follows:

[0008] This invention aims to solve the technical problems existing in the automated scheduling and processing of multi-stage, long-cycle interactive tasks, such as linear and rigid processes, coupling of scheduling logic and execution logic, lack of state feedback control, and the high degree of uncertainty, large scheduling overhead, and difficulty in debugging and maintenance of dynamic routing schemes based on large model reasoning.

[0009] To address the aforementioned technical problems, this invention provides a context-aware multi-stage task scheduling system, comprising an input layer, a scheduling layer, and a core engine layer.

[0010] The input layer is used to acquire and parse task objects, converting task objects from different sources and in different forms into a unified structured data format that can be directly processed by the execution engine.

[0011] The core engine layer comprises multiple execution engines that are combined on demand and sequentially connected. Execution engines and engine instances are separated; a single execution engine can create multiple independently running engine instances for different inputs. This separation means that the execution engine is a static logical definition and code implementation within the system, unchanged by different input data or calling contexts; while the engine instance is a dynamic runtime state carrier created and maintained by the execution engine in a specific task, recording the execution progress and running status for a specific input. Through this separation mechanism, the same execution engine can concurrently serve multiple tasks, with data isolation and no mutual interference between engine instances. The scheduling layer can also perform independent lifecycle management for each instance.

[0012] The scheduling layer performs two-stage scheduling functions: the first stage is adaptive scheduling, which determines the list of execution engines and their execution order to be used for the task based on context information before the task begins; the second stage is callback scheduling, which receives status data packets from each execution engine during task execution, matches and outputs scheduling decision instructions according to fixed threshold rules configured once during system initialization and unchanged during operation, and performs lifecycle management operations on running engine instances. The fixed thresholds are configured once during system initialization and remain unchanged during operation, ensuring that scheduling decisions do not change dynamically during operation, guaranteeing the predictability and reproducibility of scheduling results.

[0013] The scheduling layer and the core engine layer form a closed-loop control loop of execution, status feedback, rule matching, instruction issuance and execution: when the core engine executes a task and runs to a critical node, it triggers status feedback and reports the status data packet to the scheduling layer; the scheduling layer matches and outputs scheduling decision instructions according to fixed threshold rules and issues them; after the execution engine executes the corresponding instance operation, it enters the next round of execution, and so on.

[0014] The scheduling decision instructions include advance instructions, return instructions, jump instructions, and end instructions, which respectively trigger engine instance switching operations, re-initialization operations, switch to target instance operations, and destruction operations. The jump instruction is used to suspend the current engine instance and initialize and activate a specified upstream engine instance. Here, the upstream engine instance refers to the instance corresponding to the engine that precedes the current engine in the execution sequence; by jumping to the upstream engine instance, the task flow can revert from the current stage to an earlier stage for supplementary processing, achieving error recovery path reconstruction and avoiding getting stuck in an invalid loop at the current stage.

[0015] Furthermore, the fixed threshold rules include an accuracy threshold, a maximum number of attempts threshold, and a consecutive error threshold. When the accuracy reaches the accuracy threshold and all attempts are completed, a progress instruction is output; when the accuracy is lower than the accuracy threshold and the number of attempts is less than the maximum number of attempts threshold, a return instruction is output; when the number of consecutive errors reaches the consecutive error threshold, a jump instruction is output; and when the number of attempts reaches the maximum number of attempts threshold or all attempts are completed, a termination instruction is output. These three thresholds quantify the task execution status from three dimensions: result quality, attempt cost, and error persistence. Together, they constitute a complete scheduling decision basis, enabling scheduling decisions to be made based on deterministic numerical comparisons without relying on semantic understanding of the interaction content.

[0016] Furthermore, the scheduling layer performs a secondary verification before executing the scheduling decision instruction: after receiving the status data packet, the scheduling layer first performs preliminary matching to obtain candidate scheduling decision instructions, then queries the current running status of the target engine instance to verify the conditions, and only formally issues the instruction after confirming that the conditions are met. This secondary verification mechanism can prevent scheduling race conditions caused by out-of-order or delayed arrival of status messages, and ensure the consistency between the scheduling decision and the actual instance status.

[0017] Furthermore, the scheduling logic and each execution engine of the scheduling layer are independently encapsulated as standardized capability units. These standardized capability units are stored in independent folders, containing core definition files and optional script, reference document, and resource file directories; the core definition files consist of metadata and instruction portions. These standardized capability units adhere to a unified interface specification, supporting dynamic registration and hot-swapping. By encapsulating the scheduling and execution logic into independently loadable and unloadable standardized units, the system can dynamically expand and replace scheduling strategies and processing modules without modifying the core code.

[0018] Furthermore, the standardized capability unit adopts a progressive information loading mechanism, with its invocation process divided into three stages: Discovery stage, where only the metadata portion is loaded, and this loading is persistent when the external caller starts the system; Activation stage, where the complete instruction portion is loaded when the description field in the metadata portion successfully matches the semantics of the current task; and Execution stage, where resources in subdirectories are loaded as needed during instruction execution when external tools or reference documents need to be called. After execution, the system starts an idle timer, releasing the resources loaded in the execution stage when a preset idle timeout threshold is reached, retaining only the metadata portion. Through phased on-demand loading and idle release, the system loads resources at the corresponding level only when needed, reducing runtime memory usage and context overhead.

[0019] Furthermore, each engine instance contains three types of data: task data, running status, and lifecycle information. The task data is static data determined at instantiation, including task content, a list of processing units, and configuration parameters. The running status is dynamic data continuously updated during execution, including progress index, accuracy, number of attempts, and number of consecutive errors. The lifecycle information records instance state transitions, including instance identifier, current state, creation time, activation time, and last update time. The engine instance lifecycle includes four core states: executing, suspended, completed, and terminated. The transitions between these states are driven by scheduling decision instructions, thus forming a traceable and controllable complete management loop for each running instance.

[0020] Furthermore, the status data packets returned by each execution engine adopt a unified data structure, including engine identifier, execution status, accuracy, number of attempts, number of consecutive errors, progress description, timestamp, and load business data. Horizontal data transfer occurs between execution engines via load business data, with the output data of the preceding engine serving as the input data for the subsequent engine; status data packets are also sent up to the scheduling layer as input for rule matching. The unified data structure ensures that the scheduling layer can parse the status information returned by different engines in a consistent format, while the horizontal transfer of load business data enables the connection and reuse of processing results between engines.

[0021] Furthermore, the adaptive scheduling selects the engine sequence based on a preset mapping decision table. This mapping decision table takes difficulty level and processing objective as input dimensions and the enabled engine sequence as output. The scheduling layer reads the context information and looks up the table to determine the engine sequence for the current task at task startup. Here, "on-demand combination" means selecting a corresponding range of engine sequences from a preset multi-stage task processing chain based on context information, rather than arbitrarily arbitrarily combining engines. By determining the engine sequence through a lookup table, adjustments to the scheduling strategy do not require modification of the core code; only the mapping decision table needs to be updated.

[0022] Furthermore, the standardized capability units support both explicit and implicit invocation modes, with explicit invocation having higher priority than implicit invocation. In explicit invocation mode, the identifier name of the standardized capability unit is directly specified through an instruction, and the system directly activates the corresponding standardized capability unit and skips semantic matching. In implicit invocation mode, the system performs semantic matching between the natural language input and the description field in the metadata section, automatically selecting the standardized capability unit with the highest matching degree to execute the task. This design balances the determinism of explicit specification with the flexibility of automatic discovery, prioritizing the administrator's explicit intent over the system's automatic discovery results.

[0023] Accordingly, the present invention also provides a context-aware multi-stage task scheduling method, comprising the following steps: acquiring and parsing a task object; performing adaptive scheduling before the task begins, and determining the list of execution engines and execution order to be activated for this task based on context information; sequentially activating the engine instances corresponding to each execution engine to perform task processing, with each execution engine sending back status data packets during execution; matching the sent-back status data packets according to a fixed threshold rule configured once during system initialization and remaining unchanged during operation, outputting scheduling decision instructions and performing lifecycle management operations on the running engine instances; the scheduling decision instructions include advance instructions, return instructions, jump instructions, and end instructions, which respectively trigger engine instance switching operations, re-initialization operations, switching to target instance operations, and destruction operations; the jump instruction is used to suspend the current engine instance and initialize and activate a specified upstream engine instance; repeating the above matching output and lifecycle management operations until an end instruction is output, terminating all engine instances and releasing resources; forming a closed-loop control loop of execution, status feedback, rule matching, and instruction issuance to execution.

[0024] Compared with existing technologies, this invention and its preferred solution decouple scheduling decisions from large-scale model semantic understanding through a two-stage scheduling mechanism and deterministic scheduling decisions driven by fixed threshold rules. This establishes a deterministic control foundation in non-deterministic interaction scenarios that heavily rely on large-scale model generation. The scheduling results are predictable, reproducible, and debuggable, while keeping the resource overhead of scheduling decisions low. Through an architecture that separates the execution engine from engine instances and instance-level lifecycle management operations corresponding to four types of scheduling instructions (advance, return, jump, and terminate), precise state transitions and effective resource reclamation for long-cycle interactive task execution instances are achieved, avoiding invalid processes from consuming computing resources. In particular, the cross-engine protective return mechanism implemented through jump instructions can, when consecutive errors reach a threshold, non-sequentially jump the processing flow to a specified upstream engine instance, accompanied by the suspension of the current instance and the reconstruction and initialization of the target instance, thereby achieving automatic rollback and path reconstruction for error recovery. The scheduling layer's secondary verification mechanism before instruction execution effectively prevents scheduling race conditions caused by out-of-order or delayed status messages, enhancing stability in concurrent scenarios. The scheduling logic and each execution engine are encapsulated into standardized capability units that follow a unified interface specification and support dynamic registration, hot-plugging, and progressive loading. This decouples business logic from the technical architecture, enabling dynamic expansion and cross-platform reuse of functional modules without modifying the core code, reducing system resource overhead and maintenance costs. The unified structured parsing and end-to-end data reuse in the input layer eliminate computational redundancy caused by repeated parsing by multiple engines, improving the consistency and accuracy of cross-module data transmission. Attached Figure Description

[0025] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0026] Figure 1 This is a diagram illustrating the overall system architecture of an embodiment of the present invention.

[0027] Figure 2 This is a schematic diagram of the data flow between engines in an embodiment of the present invention. Detailed Implementation

[0028] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. The following embodiments are used to illustrate the present invention, but are not intended to limit the scope of protection of the present invention.

[0029] The context-aware multi-stage task scheduling system of this invention adopts a four-layer architecture, consisting of an input layer, a scheduling layer, a core engine layer, and a data recording layer from top to bottom, forming a complete data link of acquisition, planning, execution, and recording. The input layer is responsible for acquiring and structuring multimodal task data, converting raw input into structured task objects for downstream use. The scheduling layer, as the control core of the entire system, undertakes the dual functions of task orchestration and runtime control. The core engine layer consists of multiple functionally independent execution engines responsible for specific task processing logic. The data recording layer, located at the bottom layer of the system, collects behavioral data throughout the process for post-event traceability and statistical analysis, but does not participate in the real-time control loop.

[0030] The system's core scheduling mechanism consists of two phases. The first phase is adaptive scheduling. Before a task begins, based on contextual information such as difficulty level, task type, processing objective, and user status, the system determines the list of execution engines to be used and their execution order from a pre-defined multi-stage task model, achieving context-aware task orchestration. The second phase is callback scheduling. During task execution, each execution engine sends status data packets back to the scheduling layer at key nodes. The scheduling layer matches these data packets according to fixed threshold rules configured once during system initialization, outputting scheduling decision instructions such as advance, return, jump, or terminate, and performing corresponding lifecycle management operations on running engine instances. This forms a closed-loop control loop between the scheduling layer and the core engine layer, encompassing execution, status feedback, rule matching, and instruction issuance. The design of fixed threshold rules completely decouples scheduling decisions from large-model reasoning, establishing a deterministic control foundation on top of a non-deterministic interactive system that heavily relies on large-model generation, effectively ensuring the predictability and debuggability of business processes.

[0031] To further decouple scheduling logic from execution logic, the scheduling logic of the scheduling layer and each execution engine of the core engine layer are independently encapsulated as standardized capability units, supporting dynamic registration, hot-plugging, and progressive loading mechanisms. Each execution engine follows unified output constraints; the system only outputs data and heuristic interactive questions to the terminal, without outputting conclusive data. User input is collected and structured by the system. This constraint confines the non-deterministic nature of the interaction's input within a structured collection framework, avoiding process control failures and unpredictable states caused by open interactions, thus ensuring the determinism of state machine transitions and the compatibility of scheduling rules.

[0032] 1. System Overall Architecture

[0033] like Figure 1 As shown, the context-aware multi-stage task scheduling system of the present invention adopts a four-layer architecture design, consisting of an input layer, a scheduling layer, a core engine layer, and a data recording layer from top to bottom, forming a complete data link of acquisition, planning, execution, and recording. Among them, the scheduling layer and the core engine layer form a closed-loop control loop. The scheduling layer performs rule matching and issues scheduling decision instructions based on the status data returned by each execution engine, realizing real-time feedback and dynamic control during task execution.

[0034] The input layer is responsible for the acquisition and structured parsing of multimodal task data. This layer acquires raw task objects through various data acquisition methods such as text editing input, image recognition, speech acquisition, and handwriting recognition. After lexical and syntactic analysis by the parser, it generates an abstract syntax tree representing the structural hierarchy of mathematical expressions or task objects. Based on the type of syntax tree nodes, it outputs structured task objects, including sequence objects, function objects, equation objects, and structured relation objects, for use by the downstream scheduling layer. As a globally unified data format, structured task objects are passed and reused across all engines. Each engine does not need to parse the raw input again; it can directly perform logical processing based on the structured data, thereby eliminating computational redundancy caused by repeated parsing by multiple engines, reducing overall system computing power consumption, and improving the consistency and accuracy of cross-module data transmission.

[0035] The difficulty level parameter is built into the system and is automatically populated by the system based on the user's registration information; the processing target is actively input by the user or set by the administrator through the configuration interface; and the user status is automatically identified and judged by the system based on historical interaction records. The parameters of the above three dimensions, together with the structured task object, serve as the input data for the scheduling layer.

[0036] The scheduling layer, as the context-aware scheduling hub, undertakes two-stage scheduling functions and is the control core of the entire system. Adaptive scheduling determines the list of engines to activate and their execution order based on difficulty level parameters, task type, processing objectives, and user status before the task begins. Callback scheduling receives status data packets from each execution engine during task execution, outputs advance, return, jump, and end instructions according to fixed threshold rules, and performs suspend, switch, reinitialize, and destroy operations on running instances, forming a closed-loop control loop with the core engine layer, encompassing execution, status feedback, and instruction issuance. All thresholds are fixed parameters configured once during system initialization and remain unchanged during operation without dynamic parameter adjustments.

[0037] The core engine layer contains multiple execution engines that can be independently activated, combined on demand, and executed sequentially. Each engine receives instructions from the scheduling layer and processes specific types of input data; its operational logic is stored in a computer-readable storage medium in the form of a program instruction set. During execution, each engine continuously generates status data and transmits it back to the scheduling layer at critical nodes.

[0038] The data recording layer is located at the bottom layer of the system. It collects behavioral data such as accuracy rate, number of attempts, time consumption of each stage, and quality of processing results throughout the process. It is only used for post-event traceability and statistical analysis and does not participate in the real-time control loop. It also provides a standardized query interface to support the retrieval of historical data by user, time, engine, and other dimensions.

[0039] 2. Decoupled architecture between scheduling layer and core engine layer

[0040] The decoupling of the scheduling layer and the core engine layer is the core of the technical implementation of this invention. To support complex nonlinear process control, this invention strictly defines the concepts of execution engine and engine instance.

[0041] The execution engine is a static logical definition and code implementation within the system, which does not change due to different input data or calling context. Each execution engine encapsulates the processing logic, state generation rules, and completion conditions for a specific type of task, and is a functional unit that can be invoked by the scheduling layer.

[0042] An engine instance is a dynamic runtime state carrier created and maintained by the engine in a specific task. An instance contains three types of data: task data, which is static data determined at the time of instantiation, including task content, processing unit list, and configuration parameters; runtime state, which is dynamic data that is continuously updated during execution, including progress index, accuracy, number of attempts, and number of consecutive errors; and lifecycle information, which records the changes in the instance's state, including instance identifier, current state, creation time, activation time, and last update time.

[0043] The same engine can create multiple instances that run independently of each other for different input data. The data between each instance is completely isolated, supporting concurrent execution by multiple users and multiple tasks. The engine defines what function to execute, and the instance records what input data it is for and what stage of execution it is currently at.

[0044] 3. Adaptive Scheduling Mechanism

[0045] The adaptive scheduling of the scheduling layer is triggered once before the task starts. Based on four dimensions, namely difficulty level parameter, task type, processing goal and user status, it comprehensively decides the list of engines to be used and the execution order for this task, so as to realize context-aware task orchestration.

[0046] The system has a pre-defined reference model for task phase division, which divides multi-stage tasks into multiple progressive processing stages. As a preferred implementation, using an inductive logical reasoning path as the reference model, the multi-stage task is divided into six stages: case observation, pattern induction, conjecture generation, verification and reflection, cross-domain expansion, and autonomous creation. This reference model serves as the basis for task phase division in this invention; that is, the system schedules the complete processing chain composed of the aforementioned multiple task stages.

[0047] The scheduling layer, based on the input context parameters, extracts the corresponding task stage range from the reference model to determine the list of engines to be activated for this task. The engines have a fixed execution order, sequentially chained from lowest to highest processing difficulty; they cannot be executed in reverse or skipped order. Low-difficulty tasks only utilize the first-stage engines, while high-difficulty tasks utilize all engines. This on-demand combination reflects differences in the scope of extraction, not arbitrary permutations or combinations. Engines are linked through data transfer and triggering mechanisms; the output data of a preceding engine serves as the input data for subsequent engines, and the completion of a preceding engine triggers the startup of the next.

[0048] As a concrete implementation of adaptive scheduling, the system is configured with a decision mapping table. An application example is a mathematical thinking training scenario:

[0049]

[0050] When a task starts, the scheduling layer reads the difficulty level and processing objective from the context parameters, looks up the table to determine the engine sequence for this task, and initializes and activates them sequentially.

[0051] 4. Callback Scheduling and Closed-Loop Control Mechanism

[0052] During task execution, the callback scheduling mechanism of the scheduling layer is responsible for managing the instance lifecycle. When the core engine reaches a critical node, it triggers a status backhaul, reporting the status data packet to the scheduling layer. The scheduling layer matches and outputs scheduling decision instructions according to fixed threshold rules and sends them to the corresponding execution engine for execution. After the engine executes the instructions, it updates its running status, continues processing, and sends back the status again at the next critical node. This forms a closed-loop control loop of execution, status backhaul, rule matching, and instruction delivery to execution.

[0053] 4.1 Status feedback trigger node

[0054] The core engine triggers state postback at the following key nodes:

[0055] Task completion node: When the engine completes all processing steps and meets the completion conditions, it sends back the final status data packet.

[0056] Continuous error threshold node: When the engine detects that the number of consecutive errors has reached a preset threshold, it immediately sends back a status flag;

[0057] Timeout Node: When the engine waits for the user's input for more than the preset timeout duration, it sends out a timeout status.

[0058] Trial Limit Node: When the total number of attempts by the engine reaches the maximum attempt threshold, the status is returned.

[0059] User-initiated node termination: When a user triggers an active termination command, the engine sends back the termination status and reports the current progress.

[0060] 4.2 State Data Packet Structure

[0061] The status data packets returned by each execution engine use a unified JSON data structure, with the following field definitions:

[0062]

[0063] Uplink messages are sent by the execution engine and targeted at the scheduling layer. They include message identifier, message type, timestamp, source engine identifier, and status data. Downlink messages are sent by the scheduling layer and targeted at the execution engine. They include message identifier, message type, timestamp, target engine identifier, scheduling decision instruction, and triggering reason. This enables remote control of the lifecycle of engine instances.

[0064] 4.3 Fixed Threshold Rule

[0065] The scheduling layer matches and outputs four scheduling decision instructions based on fixed threshold rules. Fixed thresholds are a set of parameters configured once during system initialization and remain unchanged during operation, including three core threshold categories:

[0066] Accuracy threshold The default value is 0.6, used to determine whether the current engine task meets the target. A push command is triggered when the accuracy is greater than or equal to the threshold; if the accuracy is less than the threshold, a decision to return and retry is made based on the number of attempts.

[0067] Maximum number of attempts The default value is 5, used to prevent infinite loops. If the target number of attempts is not reached after this number, a termination command is triggered and a backtracking state is marked.

[0068] Continuous error threshold The default value is 3. When this number is reached, a jump instruction is triggered to jump to the specified upstream engine for supplementary processing.

[0069] The threshold read / write logic is as follows: At system startup, threshold parameters are read from the configuration file and loaded into a global configuration object in memory. During initialization, each execution engine retrieves its required threshold parameters from the global configuration object and caches them locally. During execution, each engine reads the threshold from its local cache for comparison; if the threshold is reached, a status postback is triggered. Thresholds are only manually modified by the administrator in the configuration file before system initialization; the system does not perform any write operations or dynamic parameter adjustments during runtime.

[0070] When the scheduling layer receives the status data packet, it matches the corresponding rule according to the event type:

[0071] If satisfied Once all operations are completed, a propulsion command will be output.

[0072] If satisfied and If so, then output the return instruction;

[0073] If satisfied If so, then a jump instruction will be output;

[0074] If satisfied If all operations are completed, then the end command will be output.

[0075] As a preferred implementation, the scheduling layer performs secondary verification before executing instructions: after receiving a status data packet, the scheduling layer first performs preliminary matching based on the status field in the data packet to obtain candidate instructions, and then queries the current running status of the target instance again to verify the conditions. Only after confirming that the conditions are met will the instruction be formally issued. This secondary verification mechanism can effectively prevent state race conditions caused by out-of-order or delayed arrival of status messages, ensuring the accuracy and consistency of scheduling decisions.

[0076] 4.4 Mapping relationship between the four types of instructions and instance operations

[0077] The mapping relationship between the four scheduling decision instructions and engine execution instance operations is as follows:

[0078] The advance command triggers a switching operation: suspend the current instance, initialize and activate the next engine instance, and make the task flow proceed sequentially;

[0079] The return command triggers a re-initialization operation: destroy the current instance, create a new instance with the same engine, change the task data, and reactivate it, allowing the current engine to retry;

[0080] The jump command triggers a switch to the target instance operation: suspend the current instance, initialize and activate the specified target engine instance, enabling non-sequential jumps in the task flow;

[0081] The termination command triggers a destruction operation: terminating all running instances and releasing resources, thus ending the task flow.

[0082] 4.5 Data Flow

[0083] like Figure 2 As shown, the status data packets generated by each engine at key nodes follow the following three-channel flow specification:

[0084] Uplink to the scheduling layer: Status data packets are sent back to the scheduling layer as input for rule matching. The scheduling layer compares three core fields—accuracy rate, number of attempts, and number of consecutive errors—with preset thresholds and outputs instructions to advance, return, jump, or terminate.

[0085] Laterally, data is passed to subsequent engines: user input in the payload serves as input data for those engines. Each engine passes data through a shared context; the specific transmission path is as follows:

[0086]

[0087] Downstream to the data recording layer: All status data packets are written to the data recording layer after the task is completed for post-event traceability and statistical analysis, and do not participate in real-time control.

[0088] The aforementioned data flow enables the scheduling layer to obtain the complete execution status, while standardizing the data transmission format between engines, thus forming the data foundation for the closed-loop control loop.

[0089] 5. State Machine Transition Rules

[0090] The four scheduling decision instructions correspond to strict state machine transition rules. The lifecycle of an engine instance includes four core states: executing, suspended, completed, and terminated. The transitions between these states are driven by scheduling decision instructions.

[0091]

[0092] The aforementioned state transition rules are uniformly maintained by the scheduling layer. After receiving instructions, the execution engine performs the corresponding state transition based on the current instance state. This deterministic state machine transition rule replaces the non-deterministic decision-making of dynamic routing in large models, reducing the context window occupied by scheduling decisions by approximately 90%, while ensuring the reproducibility and debuggability of the process.

[0093] 6. Standardized Capability Unit Packaging Mechanism

[0094] To further decouple the scheduling logic from the execution logic, the scheduling logic of the scheduling module and each execution engine are independently encapsulated as standardized capability units. This encapsulation follows the Agent Skills open standard, is stored in an independent folder, and contains the core definition file SKILL.md as well as optional scripts, references, and assets subdirectories.

[0095] The SKILL.md file consists of a metadata section in YAML format and a directive section in Markdown format.

[0096] The metadata section includes the following fields:

[0097]

[0098] The metadata portion is permanently loaded when the external caller starts up, and is used to complete the discovery and matching of capability units; the instruction portion is only fully loaded and executed after the external caller successfully matches the metadata.

[0099] The instruction section follows the metadata section and contains the complete execution logic for that capability unit.

[0100] As a preferred embodiment, the metadata portion of the SKILL.md file of the scheduling module is defined as follows:

[0101] name: multi-stage-task-dispatcher

[0102] Description: A context-aware scheduling hub for multi-stage tasks. Based on difficulty level, task type, processing objective, and user status, it determines the list of engines to use and their execution order for the current task. Simultaneously, during task execution, it outputs advance, return, jump, and termination commands according to fixed threshold rules based on status data such as accuracy and number of attempts returned by each execution engine. It is triggered when users request multi-stage task scheduling, status-aware orchestration, or engine lifecycle management.

[0103] allowed-tools: python3

[0104] Compatibility: Intelligent agent systems compatible with the Agent Skills standard

[0105] 6.1 Unified Interface Specification

[0106] The unified interface specification for capability units defines five core interfaces:

[0107]

[0108] 6.2 Dynamic Registration and Hot-Swapping

[0109] The execution logic for dynamic registration and hot-plugging includes a registration process and an unloading process.

[0110] Registration process: The system listens to the specified directory, detects a new capability unit definition file, parses the metadata and verifies its integrity. After successful verification, it registers the file to the capability unit registry and broadcasts the change event.

[0111] Uninstallation process: After the external caller sends the uninstallation command, the system checks whether the capability unit is being executed. If it is being executed, the system waits for it to complete, then removes it from the registry and releases the corresponding resources.

[0112] 6.3 Progressive Information Loading Mechanism

[0113] The standardized capability unit adopts a progressive information loading mechanism, and its invocation process is divided into three stages:

[0114]

[0115] After execution, the system starts an idle timer. When the preset idle timeout threshold is reached, the resources loaded during the execution phase are released, retaining only the metadata. These metadata are then reloaded upon subsequent calls, effectively reducing system memory consumption. Compared to the full loading mechanism, the three-level progressive loading reduces context window usage by approximately 90%.

[0116] 6.4 Invocation Mode

[0117] Capability units support both explicit and implicit invocation modes.

[0118] Explicit Invocation: Users directly specify the name of a capability unit via command, forcing the system to invoke that capability unit to execute the task. This method is suitable for scenarios where administrators explicitly specify the use of a certain scheduling logic, the same scheduled tasks need to be executed repeatedly, or there are fixed scheduling requirements for specific difficulty levels or task types. In explicit invocation mode, the system directly activates the corresponding capability unit, skipping the semantic matching process.

[0119] Implicit invocation: The external caller semantically matches the user's natural language input with the description field in the metadata of each capability unit, and automatically selects the capability unit with the highest matching degree to execute the task. This method is suitable for scenarios where the user does not explicitly know which capability unit is needed; the system automatically completes capability discovery and routing.

[0120] The two invocation methods can coexist, and the system processes them according to the following priority: when the user explicitly specifies the capability unit through a command, an explicit invocation is used; when the user does not explicitly specify it, an implicit invocation is used for semantic matching. This priority design ensures that the administrator's explicit intent takes precedence over the system's automatic discovery results.

[0121] The standardized capability units can be dynamically loaded or unloaded without modifying the core system code, and can be automatically discovered and invoked by any external caller that is compatible with the Agent Skills open standard through semantic matching.

[0122] 7. Core Engine Layer and Data Flow

[0123] Based on the aforementioned scheduling architecture and engine encapsulation mechanism, the core engine layer contains multiple execution engines that are combined on demand and executed sequentially. Each engine follows the same output constraints: the system only outputs data, heuristic interactive questions, and descriptions of cognitive conflicts to the user terminal, without outputting conclusive data; the content of user input is collected and structured by the system, and the system does not judge the correctness of the user input.

[0124] The following uses five exemplary execution engines as examples to illustrate the specific implementation of the core engine layer. It should be understood that the scope of protection of this invention is not limited to the specific content of the following five engines; any execution engine that conforms to the unified interface specification can be connected to this scheduling system.

[0125] 7.1 First Engine: Multi-Example Induction Engine

[0126] Functional Positioning: By automatically generating multiple sets of numerical or logical special cases, this engine guides users to summarize general rules from specific examples, corresponding to the special case observation and rule summarization stages in the task processing chain. This engine is independently packaged as standardized capability units, which can be dynamically discovered and invoked by external intelligent agent systems, possessing cross-platform reusability.

[0127] Input: Structured task objects, configuration parameters, including difficulty level, number of special cases, boundary cases (referring to the endpoints of the parameter value range, special values, or degenerate situations, used to verify the universality of the pattern), etc.

[0128] Workflow:

[0129] The first step is to parse the task object and determine the type of pattern. The engine receives the structured task object from the input layer, identifies the specific type of pattern to which the object belongs, such as sequence summation, algebraic expansion, function properties, or structured relationship patterns, and determines the core pattern that the engine needs to guide the discovery of.

[0130] The second step is to generate a sequence of special cases. Based on the determined pattern type and configuration parameters, the engine automatically generates at least three sets of numerical special cases. These special cases exhibit observable patterns of change and include at least one set of boundary cases. The difficulty-adaptive mechanism is as follows: the initial stage uses a small range of integers, presented in concrete numerical form; the intermediate stage expands to integers, decimals, and negative numbers, presented in algebraic expressions with letters; the advanced stage uses real numbers and parameters, presented in abstract expressions with parameters.

[0131] The third step is step-by-step presentation and data collection. The engine presents each special case to the user terminal one by one. After each special case is presented, it pauses and waits for the user to input the calculation result. Once the result is completed, it automatically presents the next special case until all special cases have been processed.

[0132] The fourth step is to summarize and compare the results. After all special cases have been processed, the engine summarizes the inputs and calculation results of each special case into a comparison table.

[0133] The fifth step is to guide questions in a tiered manner. Based on the summary table, the engine retrieves the corresponding level of guided questions from the preset template library according to the configuration parameters and outputs them to the user's terminal. The question levels include the perception layer, which observes data change trends; the correlation layer, which analyzes the correspondence between changes; and the abstraction layer, which summarizes a unified expression. Each level of question uses a preset output template, and the system collects the user's responses to each question.

[0134] Step 6: Summary Statement Collection. The engine outputs guiding dialogue and collects the summary statement content input by the user as structured data storage, without judging the correctness of the statement content. This summary statement content is stored in the payload as the student_induction field, serving as input data for the structure capture engine.

[0135] Accuracy definition: Correct completion means that the user's calculation result for this specific case is consistent with the system's expected value.

[0136] Completion conditions: The following three conditions must be met simultaneously: the system has collected the calculation results of all special cases; the system has collected the response content of all guided questions; the system has collected the user's summary statement content and the content is not empty.

[0137] Status feedback: During engine execution, the engine continuously sends back data packets that conform to the general structure of status data packets to the scheduling layer. The attempts field records the total number of attempts that the current engine has made, and the consequent_errors field is only used for data recording in this engine and does not trigger scheduling decisions.

[0138] 7.2 Second Engine: Structure Capture Engine

[0139] Functional positioning: By automatically identifying and visually annotating the deep structure of task objects, this engine guides users to understand the essential characteristics of objects from a structural perspective, corresponding to the structural insight stage in the task processing chain. This engine is independently packaged in the form of standardized capability units.

[0140] Input: The inductive statement `student_induction` passed from the upstream engine, the original structured task object, and configuration parameters. This engine will not start if the upstream engine has not completed.

[0141] Workflow:

[0142] The first step is to obtain the inductive results. The engine receives user-summarized statements and original task objects from multiple upstream inductive engines as input data for this engine.

[0143] The second step is to identify deep structure types. The engine parses the input task object and automatically identifies the deep structure types it contains, including symmetric structures (objects retain their form after element swapping); cyclical structures (objects retain their form after multiple element permutations); recursive structures (adjacent items have a fixed pattern of change); invariant structures (attributes that remain unchanged during transformation); and hidden equivalence relationships (relationships that are different in appearance but essentially equivalent).

[0144] The third step is to generate visual annotations. Based on the identified deep structure type, the engine automatically generates corresponding visual annotation schemes, marking the specific locations of structural features in the task object in different ways. Specifically, symmetrical structures are marked with the same color for corresponding symmetrical items; cyclical structures are marked with cyclic arrows to indicate substitution paths; recursive structures are marked with underlines for key recursive units; and invariant structures are marked with highlighted boxes for the unchanged parts. The engine only marks the location, not the structure name.

[0145] The fourth step is layered guided observation. Based on the configuration parameters and the identified structure types, the engine retrieves the corresponding layer of guided questions from the preset template library and outputs them to the user's terminal. The questions focus on the labeled visual areas. The engine does not output structure names, but only descriptive questions pointing to the labeled areas.

[0146] Step 5: Structured Statement Acquisition. The engine outputs guiding dialogue to collect the user's input structured statement content as structured data storage, without judging the correctness of the statement content. This structured statement content is stored in the payload as the student_statement field, serving as input data for the bidirectional inference engine.

[0147] Accuracy definition: .

[0148] Completion conditions: Both of the following conditions must be met simultaneously: The system has collected all responses to guided questions; The system has collected the user's structural characteristic statements and the content is not empty.

[0149] Status postback: Consecutive_errors is used only for data logging in this engine.

[0150] 7.3 Third Engine: Two-Way Inference Engine

[0151] Functional positioning: This function guides users to propose hypotheses and verify them using various strategies, forming an iterative closed loop of hypothesis generation, verification, correction, and re-hypothesis, corresponding to the hypothesis generation and verification / reflection stages in the task processing chain. This engine is the core module of this invention and is independently encapsulated as a standardized capability unit.

[0152] Input: The inductive statement `student_induction` and the structural feature statement `student_statement` passed from the preceding engine, and configuration parameters. This engine will not start if the upstream engine has not completed.

[0153] Workflow:

[0154] The first step is to obtain inductive observation results. The engine receives inductive statements from multiple upstream inductive engines and structural feature statements from the structure capture engine as input data for this engine.

[0155] The second step is to guide the generation of hypotheses. Based on the acquired inductive results and structural features, the engine retrieves hypothetical guidance statements from a preset template library and outputs them to the user's terminal, collecting the hypothetical content input by the user. The engine does not judge the correctness of the user's input hypotheses; it only stores the hypotheses as structured data. If the user indicates that they cannot generate a hypothesis, the engine outputs auxiliary guidance statements.

[0156] The third step is hypothesis recording and structuring. The engine stores the user's hypotheses in a structured manner, marks the hypothesis status as pending verification, and breaks down the hypothesis into a conditional part, namely the scope and preconditions of the hypothesis, and a conclusion part, namely the expression or rule description of the hypothesis, providing structured data for subsequent verification. If the hypothesis is incomplete, the engine outputs clarification questions and collects the user's improved hypothesis.

[0157] The fourth step is guided verification and iteration. The engine automatically matches verification strategies based on the hypothesis type and outputs them to the user terminal, collecting user data on the execution results of each verification strategy:

[0158] Additional special case verification: The engine generates no fewer than 3 new sets of special case data, exceeding the range of special cases used in the original induction. Each set is presented, and the results after the user's calculations are collected. The calculation results are compared with the hypothesized predicted values, and the verification results are recorded. If all new special cases are valid, the next verification strategy is implemented.

[0159] Counterexample search: After the additional special case verification is successful, the engine guides the user to try to find counterexamples that may refute the conjecture. If the user finds a counterexample, the engine guides them to revise their conjecture; if no counterexample is found, the engine records the absence of a counterexample as supporting information.

[0160] Analogical reasoning: The engine guides users to think about whether the conjecture also holds true in other similar situations, and collects the user's analogical reasoning results.

[0161] The fifth step is correction and re-guessing. When a special case is found to be invalid or a counterexample is found during the verification process, the engine outputs a correction prompt, collects the user's corrected guess, and re-enters the verification loop.

[0162] Step 6: Verification Conclusion Collection. The engine outputs a guiding dialogue to collect the verification conclusion input by the user. This conjecture is stored in the payload as the `conjecture_content` field, serving as the engine's final output.

[0163] Built-in protective return mechanism: The engine has a built-in continuous error detection mechanism. When the consecutive_errors field, i.e., the number of consecutive errors, reaches a threshold... By default, after 3 attempts, the engine automatically sends a status flag indicating that the continuous error threshold has been triggered back to the scheduling layer, which then executes a jump instruction to guide the task path back to the structure capture engine to supplement the structure observation training.

[0164] Accuracy definition: Each complete hypothesis verification loop is counted as one iteration.

[0165] Completion conditions: One of the following conditions must be met: verification passes and the user confirms that the conjecture is true; verification fails but the user proposes a revised conjecture and completes the verification.

[0166] Status feedback: `attempts` records the total number of validation attempts, and `consecutive_errors` records the number of consecutive incorrect guesses; the number is reset to zero when consecutive correct guesses occur. The scheduling layer makes a decision based on the feedback data: accuracy is greater than or equal to... Advance in time; consecutive_errors greater than or equal to A jump instruction is triggered when the attempt is greater than or equal to 1. The process ends and the backtracking state is marked.

[0167] 7.4 The Fourth Engine: Cross-Domain Association Engine

[0168] Functional Positioning: Based on the built-in concept mapping knowledge graph, it guides users to discover isomorphic relationships between different knowledge branches, enabling cross-domain transfer and integration of knowledge, corresponding to the cross-domain expansion stage in the task processing chain. This engine is independently encapsulated in the form of standardized capability units.

[0169] Input: The conjecture content (conjecture_content) passed from the upstream engine, along with the complete structure information and configuration parameters of the current task object. This engine will not start if the upstream engine has not completed.

[0170] Workflow:

[0171] The first step is to verify the completion status of the preceding engine. The engine receives the verification conclusions output by the upstream bidirectional inference engine and the complete structural information of the current task object as input data for this engine.

[0172] The second step is to construct a concept mapping network. The engine has a built-in cross-branch concept mapping knowledge base, which contains isomorphic structural correspondences between different knowledge branches. Based on the structural type of the current task object, the engine automatically retrieves other branch objects in the knowledge base that have isomorphic relationships with it, generating a cross-domain association candidate list. Each association candidate includes source branch and target branch identifiers, a description of the correspondence between the source structure and the target structure, and a list of attributes that the mapping can be transferred.

[0173] The third step is to determine the feasibility of association. The engine evaluates the search results: if there is at least one association candidate and the cross-domain mapping relationship is clear, it is determined that cross-domain association is feasible and proceeds to the next step; if there are no available association candidates, the engine determines that there is no space for cross-domain association, sends a status flag back to the scheduling layer, and actively skips the engine through the skip interface.

[0174] The fourth step is to generate the association guidance sequence. The engine generates cross-domain association guidance questions based on the candidate association list. All guidance questions only point to the association direction and do not display the cross-domain mapping results. The guidance questions are arranged in order from concrete to abstract: the first layer is scene-aware association, the second layer is structural comparison association, and the third layer is transfer application association. The engine does not directly output the mapping results, only the guidance questions.

[0175] Step 5: Association Result Collection. The engine outputs guiding dialogue and collects the user's input association statements as structured data. This association statement content is stored in the payload as the student_association field, serving as input data for the self-generating question engine.

[0176] Step 6: Concept Mapping Network Expansion. After the user completes their associative statement, the engine automatically adds the user's association results to the concept mapping network knowledge base, marking them as the user's personalized concept mapping path for reference and reuse in subsequent tasks.

[0177] Accuracy definition: .

[0178] Completion conditions: One of the following conditions must be met: The system has collected all responses to guided questions and has collected the user's associative statements; The engine determines that the current input has no cross-domain associative space and automatically skips it.

[0179] Status postback: Consecutive_errors is only used for data logging in this engine. If the current task object has no cross-domain association space, a jump instruction is executed to skip this engine and directly proceed to the next engine or terminate the task.

[0180] 7.5 Fifth Engine: Self-Generated Question Engine

[0181] Functional positioning: To guide users to autonomously construct and solve new tasks based on a given task structure, realizing the role transformation from passive processor to active constructor, corresponding to the autonomous creation stage in the task processing chain. This engine is independently packaged in the form of standardized capability units.

[0182] Input: The associative statement `student_association` passed from the preceding engine, the complete structure information of the current task object, and configuration parameters. If the preceding engine is incomplete, the user can directly enter this engine through administrator configuration or by actively selecting it; the system will then mark it as an autonomous exploration mode.

[0183] Workflow:

[0184] The first step is to verify the completion status of the preceding engine. The engine receives the user's association statement and the complete structural information of the current task object from the upstream cross-domain association engine as input data for this engine.

[0185] The second step is an optional skip check. Upon startup, the engine first determines whether the user has chosen to skip this step. If the user actively chooses to skip, the engine immediately sends a user-initiated skip status flag back to the scheduling layer, triggering a jump instruction and directly entering the task termination process.

[0186] The third step is to guide the direction of the variation. Based on the structure of the current task object, the engine retrieves variation guidance questions from the preset template library and outputs them to the user terminal. These guidance questions include three types: condition modification direction, question transformation direction, and structure migration direction. The engine does not provide specific variation solutions, but only outputs directional guidance.

[0187] The fourth step is variation construction and solution. The engine collects the new task content constructed by the user, guides the user to attempt to solve the constructed new task, and collects data from the solution process. If the new task constructed by the user has no solution or is meaningless, the engine outputs adjustment prompts and collects the user's revised content.

[0188] The fifth step is iterative optimization. The engine outputs iterative optimization guidance questions based on three dimensions: the rationality of the variation, the appropriateness of the difficulty, and the existence of the solution. It also collects the user's corrected content and the solution process.

[0189] Step 6: Results Recording. The engine stores the final version of the new task, solution process, and answer constructed by the user in a structured manner. The content of the new task is stored in the payload as the new_problem field, serving as the final output of this engine. At the same time, the complete record is stored in the data recording layer for later traceability.

[0190] Accuracy definition: .

[0191] Completion conditions: One of the following conditions must be met: The system has collected at least one new task content and corresponding solution process constructed by the user, and the new task has a solution; The system has collected the user's instruction to skip this step.

[0192] Optional skip mechanism: If this engine is marked as optional in the configuration parameters, and the current task's processing objective does not include the autonomous creation stage, then this engine can be skipped.

[0193] Status feedback: Consecutive_errors is only used for data recording in this engine. The variants_solved field in the payload records the number of valid variants. The scheduling layer makes decisions based on the feedback data: normal termination when variants_solved is greater than or equal to 1; termination when the user actively skips the process and executes a jump instruction; termination when attempts is greater than or equal to 3 and no valid variants have been completed.

[0194] 8 Specific Application Examples

[0195] The following uses three mathematical thinking training scenarios of different difficulty levels as specific application examples to describe the workflow of this invention in detail. It should be understood that this embodiment is merely to illustrate one application of the invention and does not constitute a limitation on the scope of protection of this invention.

[0196] 8.1 Example 1: Beginner Level – Exploring the Pattern of the Sum of Consecutive Odd Numbers

[0197] Task input: The user inputs a mathematical exploration object 1+3+5+…, with a difficulty level of beginner and a processing objective of routine processing.

[0198] System execution flow:

[0199] The input layer collects the input through text editing, which is then identified as a sequence summation type by the mathematical expression parser, and outputs a structured task object. The scheduling layer adaptively schedules tasks based on the difficulty level (beginner), task type (sequence summation), processing objective (routine processing), and user status (novice). It uses a table to decide whether to use the multi-example induction engine or the structure capture engine for this task, with the execution order being from the multi-example induction engine to the structure capture engine.

[0200] Once the multi-example inductive engine is activated, it automatically generates four sets of special cases, guiding the user through the calculations one by one: Special Case 1: 1+3=?, Special Case 2: 1+3+5=?, Special Case 3: 1+3+5+7=?, Special Case 4: 1+3+5+7+9=?. The user inputs the calculation results 4, 9, 16, and 25, all of which are correct.

[0201] The engine summarizes the results in a table and outputs a question to the perception layer: Observe these results, what kind of numbers are they squares? After the user answers, the engine continues to ask: What is the relationship between the base and the number of addends in the results? The user observes and answers the correspondence.

[0202] The engine outputs an inductive statement as guidance, and the user answers: The sum of the first n odd numbers equals the square of n. The engine records this inductive conclusion. With 100% accuracy, all special cases are completed, and the state is propagated back to the scheduling layer.

[0203] After the scheduling layer receives the completion status of multiple induction engines, it performs secondary verification, outputs a propulsion command, and switches to the structure capture engine.

[0204] The structure capture engine receives the conclusions and original expressions summarized by the user, automatically identifies and generates visual annotations: it annotates the odd number sequence in 1+3+5+…+(2n-1) and marks the correspondence between odd numbers and sequence numbers.

[0205] The engine outputs a guiding question. After the user answers, the engine outputs a structured statement guiding the user's response: "The number of odd numbers is the same as the square root of the result." The engine completes all observations and questions with an accuracy rate of 1.0, and the status is then posted back to the scheduling layer.

[0206] After the scheduling layer receives the completion status of the capture engine, it determines that there are no subsequent engines, outputs a termination command, destroys all instances, and writes all behavioral data to the data recording layer.

[0207] 8.2 Example 2: Intermediate Difficulty - Exploration The unfolding pattern (including closed-loop control triggering)

[0208] Task Input: User Input What does it equal after being expanded? The difficulty level is intermediate, and the processing target is standard processing.

[0209] System execution flow:

[0210] The input layer collects and parses the data. The scheduling layer adaptively schedules data based on the difficulty level (medium), task type (algebraic expansion), and processing target criteria. The table lookup decision utilizes three engines: a multi-example induction engine, a structure capture engine, and a bidirectional reasoning engine.

[0211] The multi-case induction engine generates special cases: substituting a=2 and b=3 into... The calculation yields 25. Substituting a=3 and b=4, we get 49. Substituting a=4 and b=5, we get 81. After the user completes the calculations step by step, the engine guides them to compare the bit examples and discovers... Not equal to The difference was found to be equal to 2ab. After collecting and summarizing the data, a completion status was returned.

[0212] The scheduling layer proceeds to the structure capture engine. The engine then... Visual annotation is performed using an expanded format, with different colors used to highlight each annotation. Item, 2ab item and The position of the item. The engine asks questions to guide the user to identify coefficient features, and the user identifies the coefficient structure. The structural feature description is collected and returned.

[0213] The scheduling layer proceeds to the bidirectional inference engine. The engine outputs a hypothesis guide, and the user proposes a hypothesis: .

[0214] The engine enters the verification phase. The first step involves adding special cases for verification. The engine generates multiple new sets of special cases, which the user substitutes into the calculations, and all pass verification. The second step is analogical reasoning, where the engine guides the user to make inferences. The user guesses the form of the hypothesis by analogy and verifies it by substituting specific examples. The third step involves searching for counterexamples; after trying multiple sets of values, the user confirms the hypothesis is correct and no counterexamples are found.

[0215] The engine outputs a verification conclusion to guide the user's confirmation that the hypothesis is correct. The engine completes the entire verification process, and the status is returned to the scheduling layer, which then proceeds to the end.

[0216] Closed-loop control triggering process: During the above verification process, if the user's conjecture is false by the new feature three times consecutively, and consequent_errors reaches the threshold of 3, the engine's consecutive error detection mechanism is triggered, and the consecutive error threshold trigger status is returned to the scheduling layer. The scheduling layer performs a second verification to confirm that consequent_errors is greater than or equal to... The system outputs a jump command, redirecting to the structure capture engine, initializing and activating its instance, and performing supplementary observation training from a different perspective. After completing the supplementary observation, the scheduling layer proceeds back to the bidirectional inference engine, allowing the user to revise their conjecture and propose the correct formula. The scheduling layer records the entire return and recovery process, and all data is written to the data recording layer.

[0217] 8.3 Example 3: Advanced Difficulty - Exploring the Complete Link of Natural Number Squares (Including Closed-Loop Control Triggering)

[0218] Task Input: User Input The difficulty level is high, and the processing target is deep processing.

[0219] System execution flow:

[0220] The scheduling layer adaptively schedules tasks based on difficulty level (high), task type sequence summation, and processing target depth. It then uses a table lookup decision to activate all five engines in the following order: multi-example induction engine, structure capture engine, bidirectional reasoning engine, cross-domain association engine, and self-generated question engine.

[0221] The multi-example induction engine generates special cases: the result is 1 when n=1, 5 when n=2, 14 when n=3, 30 when n=4, and 55 when n=5. This guides users to observe the correspondence between these results and n, and users initially conclude that the results seem to be related to n, n+1, and 2n+1.

[0222] The structure capture engine visualizes and annotates the result sequence, highlighting the difference relationships 4, 9, 16, and 25 between 1, 5, 14, 30, and 55, guiding the user to discover that the differences are consecutive squares. Further observation reveals that the second-order differences are consecutive odd numbers, identifying it as a cubic polynomial structure.

[0223] A two-way reasoning engine guides users to formulate hypotheses. Users then formulate... The engine guides users to verify the data by adding special cases and using analogical reasoning, that is, by comparing the structure with the formula for the sum of natural numbers. The user then verifies the data.

[0224] Closed-loop control triggering process: During training, the user makes three consecutive incorrect guesses in the bidirectional inference engine, successively proposing incorrect formulas such as n(n+1) / 2 and n(2n+1) / 3, all of which are disproven by new specific examples. The engine's continuous error detection mechanism is triggered, and the continuous error threshold is returned to the scheduling layer. The scheduling layer executes a jump instruction, jumping to the structure capture engine, changing the observation angle to focus on observing the difference structure, and conducting supplementary observation training. After completing the supplementary observation, the scheduling layer advances back to the bidirectional inference engine, allowing the user to correct their conjecture and propose the correct formula. The scheduling layer records the entire return and recovery process. The closed-loop path is: multi-example induction engine → structure capture engine → bidirectional inference engine makes 3 incorrect guesses → return to structure capture engine for supplementary observation → bidirectional inference engine corrects conjecture and passes verification → cross-domain association engine → autonomous question generation engine → end.

[0225] The cross-domain association engine is activated, retrieving the formula for the sum of squares from the knowledge base and finding a correspondence between it and the concept of pyramidal numbers. The engine guides the user through cross-domain association in three layers: the scene awareness layer guides the user to associate with corresponding geometric models; the structural comparison layer guides the user to compare the structural similarity of the formula for the sum of triangle numbers; and the transfer application layer guides the user to consider the unified form of the sum of cubes. The user associates the formula for the sum of cubes of natural numbers. The engine then supplements the user's association results into the concept mapping knowledge graph.

[0226] The self-generating question engine guides users to construct variations. The engine suggests directions for variation: what happens if the square is changed to a higher power? Users then construct new questions. What is the summation formula? Try to discover the pattern through inductive reasoning and complete the solution. The engine records this variation and stores it in the data recording layer.

[0227] Once all engines are complete, the scheduling layer outputs a termination command, terminating all instances and releasing resources. Complete behavioral data is then written to the data recording layer.

[0228] 9 System-level Adaptation Examples

[0229] The scheduling system of this invention can adapt to different task phase division schemes. The following uses three typical schemes as examples:

[0230] 9.1 Inductive Solution

[0231] The scheduling layer prioritizes activating the multi-example induction engine, bidirectional reasoning engine, and cross-domain association engine, making it suitable for tasks emphasizing specific case observation and pattern discovery. This approach uses inductive reasoning as its main thread, gradually abstracting general rules from specific examples, and then expanding the applicability of these rules through cross-domain mapping. The task flow is: multi-example induction → structure capture → bidirectional reasoning → cross-domain association → autonomous question generation. This approach is suitable for task domains requiring significant numerical computation and pattern discovery capabilities.

[0232] 9.2 Structural Scheme

[0233] The scheduling layer does not utilize the multi-induction engine, but directly uses the structure capture engine as the task starting point, making it suitable for tasks that emphasize structural insight and rigorous deduction. This approach uses structural deduction as the main thread, starting from the object's internal structure and deriving properties and patterns through structural feature analysis. The task flow is: structure capture → bidirectional reasoning → cross-domain association → self-generated questions. In callback scheduling, the jump target is the structure capture engine. This approach is suitable for task domains requiring rigorous structure and logical deduction.

[0234] 9.3 Associative Solution

[0235] The scheduling layer uses a cross-domain association engine as the starting point for tasks, suitable for tasks emphasizing cross-domain association and comprehensive thinking. This approach uses analogical transfer as its main thread, starting from the structure of a known domain and transferring methods to a new domain through isomorphic mapping. The task flow is: cross-domain association → structure capture → bidirectional reasoning → self-generated questions. In the callback scheduling, when the system detects that the user's proposed generalization directions lack basis or contain obvious errors three consecutive times, it jumps to the cross-domain association engine to redirect the association direction. This approach is suitable for task domains requiring cross-domain association and comprehensive thinking.

[0236] The adaptation of the above three schemes requires no modification to the core system code; it can be achieved simply by adjusting the decision configuration table of the adaptive scheduling, fully demonstrating the versatility and scalability of the scheduling architecture of this invention. In another implementation, the different task stage division schemes can also be replaced with a specially designed set of engines, which can be connected to this scheduling system as long as they follow a unified interface specification.

[0237] 10. Pseudocode Example of Core Scheduling Logic

[0238] The following is a pseudocode example of the core scheduling logic for multi-engine collaboration, used to further illustrate the technical implementation of this invention:

[0239] def execute_task(task_input, difficulty, goal):

[0240] # First stage: Adaptive scheduling engines_to_use = dispatcher.decide_engines(difficulty=difficulty, problem_type=parse_input(task_input), goal=goal, user_status=get_user_status(user_id))# Prepare shared context context = { "task_object": task_input, "difficulty": difficulty, "examples": [], "student_induction": "", "student_statement": "", "conjecture_content":"", "validation_results": [], "student_association": "", "new_problems": []}# Second stage: Callback scheduling loop current_index = 0 while current_index < len(engines_to_use): engine_name = engines_to_use[current_index] # Activate the current engine instance instance = create_instance(engine_name, context) activate_instance(instance) # Wait for status callback status_packet = wait_for_status(instance) # Scheduling layer secondary verification if not second_verify(instance, status_packet): continue # Threshold rule matching instruction = match_threshold(status_packet, threshold_config) if instruction == "advance": suspend_instance(instance) current_index += 1 elif instruction == "return": destroy_instance(instance) instance = create_instance(engine_name, context,new_data=True) activate_instance(instance)elif instruction == "jump": suspend_instance(instance) target =get_jump_target(engine_name) current_index = engines_to_use.index(target) elif instruction == "end": destroy_all_instances()write_to_record_layer(context) breaksave_to_data_layer(context)returncontext,

[0241] This example demonstrates the engine decision-making in the first phase of the scheduling layer, the on-demand activation of each engine, the data transfer of shared context among engines, the return triggering mechanism of closed-loop control, and the secondary verification logic of the scheduling layer. Each engine call points to an independent SKILL.md file, which is dynamically loaded and executed by the external intelligent agent system.

[0242] 11. Summary of Technical Effects

[0243] This invention, through a four-layer architecture and a two-stage scheduling mechanism, transforms the complex nonlinear interactive task processing flow into a precisely controllable state machine transition, significantly improving the system's robustness and resource management efficiency. This invention replaces large-model dynamic routing with a deterministic threshold state machine as the scheduling decision mechanism, and uses reaching a threshold number of consecutive errors as the trigger condition for cross-engine jumps to a specific upstream engine instance. Combined with refined lifecycle management of engine instances, this forms a closed-loop control circuit from state feedback to instruction issuance.

[0244] Specifically, compared to existing mechanisms that rely on large model inference for dynamic routing, this invention drives scheduling decisions with fixed threshold rules configured once during system initialization. This minimizes the context overhead of scheduling decisions and avoids introducing nondeterminism into the scheduling logic itself. This mechanism establishes a deterministic control foundation in nondeterministic interactive systems that heavily rely on large model generation, effectively ensuring the predictability and debuggability of business processes. It overcomes the process control issues that are prone to occur in pure model applications and guarantees the convergence and stability of business processes.

[0245] Meanwhile, through a cross-engine protective return mechanism, when the number of consecutive errors reaches a threshold, the system will jump the processing flow non-sequentially to a specific upstream engine instance, accompanied by the suspension of the current instance and the reconstruction and initialization of the target instance. This enables automatic rollback and path reconstruction for error recovery in long-link interactive tasks, ensuring that the system can automatically recover the execution path and exit safely in abnormal states.

[0246] Furthermore, by triggering instance operations such as suspension, switching, reinitialization, and destruction corresponding to four types of scheduling decision instructions (advance, return, jump, and terminate), this system achieves precise state transitions and effective resource reclamation for running instances in long-cycle interactive tasks, avoiding invalid processes occupying computing resources. The secondary verification mechanism before execution at the scheduling layer effectively prevents scheduling race conditions caused by out-of-order or delayed arrival of status messages, further enhancing the system's stability in concurrent scenarios.

[0247] Furthermore, by encapsulating scheduling and execution logic into standardized capability units that conform to a unified interface specification, this invention achieves complete decoupling of business logic and technical architecture. The system supports dynamic registration, hot-plugging, and a three-level progressive loading mechanism, enabling dynamic expansion and cross-platform reuse of functional modules without modifying the core code, significantly reducing system maintenance costs and improving code modularity.

[0248] The unified structured parsing of the input layer and the full-link data reuse eliminate the computational redundancy of repeated parsing by multiple engines, reduce the overall computing power consumption of the system, and improve the consistency and accuracy of cross-module data transmission.

[0249] The aforementioned architecture and mechanisms work together to achieve precise orchestration and dynamic control of multi-stage task flows with extremely low resource overhead in non-deterministic interaction scenarios, thus resolving the technical contradiction in existing technologies where process flexibility and system controllability are difficult to balance.

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

Claims

1. A context-aware, multi-stage task scheduling system, characterized in that, It includes the input layer, scheduling layer, and core engine layer; The input layer is used to obtain and parse task objects; The core engine layer contains multiple execution engines that can be combined on demand and connected in sequence. The execution engine is separate from the engine instance, and the same execution engine can create multiple independently running engine instances for different inputs. The scheduling layer undertakes a two-stage scheduling function: the first stage is adaptive scheduling, which determines the list of execution engines to be used and the execution order of the task based on context information before the task starts; the second stage is callback scheduling, which receives the status data packets returned by each execution engine during the task execution, matches and outputs scheduling decision instructions according to the fixed threshold rules that are configured once during system initialization and remain unchanged during operation, and performs lifecycle management operations on the running engine instances. The scheduling layer and the core engine layer form a closed-loop control loop of execution, status feedback, rule matching, instruction issuance and execution; The scheduling decision instructions include advance instructions, return instructions, jump instructions, and end instructions, which respectively trigger engine instance switching operations, re-initialization operations, switching to target instance operations, and destruction operations; the jump instruction is used to suspend the current engine instance and initialize and activate the specified upstream engine instance.

2. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: The fixed threshold rules include an accuracy threshold, a maximum number of attempts threshold, and a consecutive error threshold; When the accuracy rate reaches the accuracy rate threshold and all tasks are completed, a push command is output; When the accuracy rate is lower than the accuracy rate threshold and the number of attempts is less than the maximum number of attempts threshold, a return command is output. When the number of consecutive errors reaches the consecutive error threshold, a jump instruction is output; When the number of attempts reaches the maximum attempt threshold or all attempts are completed, an end command is output.

3. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: The scheduling layer performs secondary verification before executing scheduling decision instructions: after receiving the status data packet, the scheduling layer first performs preliminary matching to obtain candidate scheduling decision instructions, then queries the current running status of the target engine instance to verify the conditions, and only issues the instruction after confirming that the conditions are met.

4. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: The scheduling logic of the scheduling layer and each execution engine are independently encapsulated in the form of standardized capability units; The standardized capability units are stored in an independent folder structure, containing core definition files as well as optional script directories, reference document directories, and resource file directories; the core definition files consist of metadata and instruction parts. The standardized capability units follow a unified interface specification and support dynamic registration and hot-plugging.

5. The context-aware multi-stage task scheduling system according to claim 4, characterized in that: The standardized capability unit adopts a progressive information loading mechanism, and its invocation process is divided into three stages: During the discovery phase, only the metadata portion is loaded, and it remains loaded persistently when the external caller starts up. During the activation phase, when the description field in the metadata section successfully matches the semantics of the current task, the complete instruction section is loaded. During the execution phase, when external tools or reference documents need to be called during the execution of instructions, resources in subdirectories are loaded as needed. After execution is complete, the system starts an idle timer. When the preset idle timeout threshold is reached, the resources loaded during the execution phase are released, and only the metadata portion is retained.

6. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: Each engine instance contains three types of data: task data, running status, and lifecycle information. The task data is static data determined at the time of instantiation, including task content, a list of processing units, and configuration parameters; The running status is dynamic data that is continuously updated during the execution process, including progress index, accuracy, number of attempts, and number of consecutive errors; The lifecycle information is used to record instance state transitions, including instance identifier, current state, creation time, activation time, and last update time. The lifecycle of an engine instance includes four core states: running, suspended, completed, and terminated. The transition between these states is driven by scheduling decision instructions.

7. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: The status data packets returned by each execution engine adopt a unified data structure, including engine identifier, execution status, accuracy, number of attempts, number of consecutive errors, progress description, timestamp, and load business data; The execution engines communicate horizontally via load business data, with the output data of the preceding engine serving as the input data for the subsequent engine; status data packets are sent up to the scheduling layer as input for rule matching.

8. The context-aware multi-stage task scheduling system according to claim 1, characterized in that: The adaptive scheduling selects the engine sequence based on a preset mapping decision table. The mapping decision table takes the difficulty level and processing target as input dimensions and the activated engine sequence as output. The scheduling layer reads the context information and looks up the table to determine the engine sequence for this task when the task starts.

9. The context-aware multi-stage task scheduling system according to claim 4, characterized in that, The standardized capability unit supports both explicit and implicit invocation modes, with explicit invocation having higher priority than implicit invocation. In explicit invocation mode, the identifier name of the standardized capability unit can be directly specified through the command, and the system will directly activate the corresponding standardized capability unit and skip semantic matching; In implicit invocation mode, the system performs semantic matching between the natural language input and the description field in the metadata section, and automatically selects the standardized capability unit with the highest matching degree to execute the task.

10. A context-aware multi-stage task scheduling method, characterized in that, Includes the following steps: Get and parse the task object; Before the task begins, adaptive scheduling is performed, and the list of execution engines to be used and the execution order are determined based on the context information. Each execution engine instance is activated sequentially to perform task processing, and each execution engine sends back status data packets during the execution process; Based on the fixed threshold rules that are configured once during system initialization and remain unchanged during operation, the returned status data packets are matched, scheduling decision instructions are output, and lifecycle management operations are performed on the running engine instances. The scheduling decision instructions include advance instructions, return instructions, jump instructions, and end instructions, which respectively trigger engine instance switching operations, re-initialization operations, switching to target instance operations, and destruction operations; the jump instruction is used to suspend the current engine instance and initialize and activate the specified upstream engine instance; Repeat the above matching output and lifecycle management operations until the output ends, then terminate all engine instances and release resources. This forms a closed-loop control system encompassing execution, status feedback, rule matching, and instruction issuance for execution.

Images