An agent query loop control method and system based on a state machine

Abstract

This invention discloses a state machine-based intelligent agent query loop control method and system, belonging to the field of artificial intelligence. The method achieves fine-grained control of multi-turn dialogues by constructing a state object that includes dialogue state, resource management, and execution context. It employs a predictive state transition mechanism, parsing the token sequence in real-time during model output to predict the response structure and prepare resources in advance, transforming passive response into active prediction and significantly reducing waiting latency. A multi-layered recovery path mechanism is established, automatically attempting different error recovery strategies according to priority. A continuation type label is introduced, allowing assertions of recovery paths without checking message content. Interruption signal detection is supported to identify incomplete dialogue turns. This invention effectively solves the technical problems of existing AI agent systems, such as lack of fine-grained state management, imperfect recovery mechanisms, and low resource utilization when handling multi-turn dialogues, and can be widely applied in intelligent dialogue systems, automated task execution, and other fields.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, specifically to a state machine-based intelligent agent query loop control method and system, and more particularly to an intelligent dialogue system control method employing a predictive state transition mechanism. Background Technology

[0002] With the rapid development of artificial intelligence technology, intelligent agent systems based on large language models have been widely used in various fields. These systems typically need to handle complex multi-turn dialogues, interact with external tools, and complete tasks under various constraints. However, existing AI agent systems face numerous technical challenges when handling multi-turn dialogues.

[0003] First, existing systems typically employ simple loop structures, lacking fine-grained management of dialogue state. When encountering application interface errors, token expiration, or user interruption, the system often directly terminates the dialogue without graceful recovery or degradation. This crude error handling severely impacts user experience and system stability.

[0004] Secondly, existing systems lack effective mechanisms for tracking and limiting dialogue turns, which can easily lead to infinite loops or resource exhaustion. In multi-turn dialogue scenarios, contextual information grows continuously, and without effective compression and management mechanisms, it will quickly exceed the model's processing capacity.

[0005] Secondly, the existing system adopts a passive response mode when processing model output, that is, it waits for the model to be fully output before parsing and processing. This approach causes unnecessary waiting delays, especially when the model output includes operations that require additional preparation, such as tool calls, resulting in low utilization of system resources.

[0006] Furthermore, existing systems typically employ a variable state design for state management, with state transitions that are not explicit enough, making them difficult to track and debug. When system anomalies occur, the lack of a complete state transition history makes problem localization and recovery extremely difficult.

[0007] In summary, existing technologies have significant shortcomings in handling multi-turn dialogues, state management, error recovery, and resource utilization. There is an urgent need for a more refined, efficient, and reliable state machine-based intelligent agent query loop control method and system. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a state machine-based intelligent agent query loop control method and system. By introducing innovative technologies such as predictive state transition mechanisms, immutable state design, and multi-layer recovery paths, it effectively solves the technical problems existing in the current system. Technical solution

[0009] The method provided by this invention includes the following core steps: This invention provides a state machine-based intelligent agent query loop control method and system, belonging to the field of artificial intelligence technology, specifically involving state management and loop control technology for multi-turn dialogue systems. This invention achieves fine-grained control of multi-turn dialogues by constructing a state object that includes dialogue state, resource management, and execution context; it employs a predictive state transition mechanism to parse the token sequence in real time during model output, predict the response structure, and prepare resources in advance, transforming passive response into active prediction and significantly reducing waiting latency; it establishes a multi-layered recovery path mechanism to automatically try different error recovery strategies according to priority. This invention effectively solves the technical problems of existing AI agent systems in handling multi-turn dialogues, such as lack of fine-grained state management, imperfect recovery mechanisms, and low resource utilization, and can be widely applied in intelligent dialogue systems, automated task execution, intelligent customer service, and other fields.

[0010] I. Methods and Technical Solutions.

[0011] This invention provides a state machine-based intelligent agent query loop control method, comprising the following core steps: (a) Construction of state objects.

[0012] First, a state object is constructed, which is the core data structure for the entire query loop control. The state object contains the following key information: 1. Dialogue Context Information: Records the complete history of the current dialogue, including message sequences such as user input, model response, and tool call results, as well as metadata information for each message.

[0013] 2. Resource Usage Status: Track system resource usage in real time, including token consumption, memory usage, network connection status, number of file handles, etc., providing a data foundation for resource management and budget control.

[0014] 3. Execution Environment Configuration: Stores relevant configuration parameters of the current execution environment, including model parameters, tool definitions, permission settings, compression strategy configurations, etc., to ensure the consistency and recoverability of the execution environment.

[0015] 4. State Transition History: Records all transition paths from the initial state to the current state, including the triggering conditions, transition time, and transition result for each transition, supporting state backtracking and auditing.

[0016] The state objects employ an immutable design, a key architectural feature of this invention. During each iteration, the system creates new state objects by expanding operations, rather than modifying existing ones. This immutable design ensures the explicitness and integrity of state transitions, making every state change traceable and facilitating debugging, auditing, and rollback. The immutable design also simplifies state management in concurrent scenarios, avoiding state contention issues caused by multithreading or asynchronous operations.

[0017] (ii) Iterative processing execution.

[0018] Based on the constructed state object, the system executes an iterative processing flow. Iterative processing is the core execution link of the query loop, which includes four main stages.

[0019] 1. Preprocessing stage.

[0020] The preprocessing stage is the first step in each iteration, responsible for preparing the necessary environment and resources for subsequent processing. The specific tasks of the preprocessing stage include: State object deconstruction: Extract information about each component from the current state object, including dialogue context, resource status, environment configuration, etc., to provide data input for subsequent stages of processing.

[0021] Tracking mechanism initialization: Initialize the query tracking mechanism for this iteration, set parameters such as tracking identifier, timestamp, and tracking range to ensure that the entire process of this iteration can be recorded and traced.

[0022] Non-blocking prefetching operation initiation: Initiate data prefetching and function prefetching operations, which are executed asynchronously in a non-blocking manner. This allows for the rapid provision of required data in subsequent stages, reducing waiting time. Data prefetching may include preloading commonly used tool definitions and prefetching cached results of similar historical dialogues; function prefetching may include warming up the model inference engine and pre-establishing network connections.

[0023] Resource Budget Tracker Creation: Create the resource budget tracker for this iteration, set parameters such as resource consumption cap, warning threshold, and over-limit handling strategy, and monitor and manage the resource consumption of this iteration in real time.

[0024] 2. Context Management Phase.

[0025] The context management phase is responsible for managing and optimizing the dialogue context, ensuring that the context meets model requirements without exceeding resource limits. This phase performs the following five operations in a strict order: External operation result budget management: Manage the budget for the content generated by external operations such as tool execution results, assess its usage of the context window, and truncate or summarize results that exceed the budget.

[0026] Context fragment compression: Identify redundant fragments and low-value information in the context, and use compression algorithms to compress these fragments to reduce token usage while preserving key semantics.

[0027] Refined compression processing: Perform more refined compression processing on specific elements in the context, such as merging repeated similar content, summarizing excessively long tool outputs, etc.

[0028] Context folding: Folds and merges consecutive multi-turn dialogues according to semantic relevance to form a more compact context representation while retaining key dialogue context information.

[0029] Automatic compression trigger: Evaluate whether the current context size is close to the threshold. If it is, actively trigger the automatic compression mechanism to avoid failure due to context exceeding the limit when calling the model.

[0030] These five operations are executed in a strict order, with the output of the previous operation serving as the input for the next, forming a complete context optimization pipeline. This strict order is based on the dependencies between operations and optimization efficiency considerations, ensuring optimal context management.

[0031] 3. Constraint Check Phase.

[0032] The constraint checking phase is the last line of defense before model invocation, responsible for performing hard constraint checks to prevent context size from spiraling out of control. Specific checks include: Context length check: Verify whether the current context length is within the maximum range allowed by the model. If it exceeds the limit, trigger emergency compression or refuse execution.

[0033] Resource budget check: Verify whether the current resource consumption is within the preset budget range, including token budget, time budget, computing resource budget, etc.

[0034] Permission and configuration check: Verify whether the current execution environment meets the permission requirements and configuration conditions for model invocation.

[0035] The constraint check phase adopts a "failure to terminate" strategy. If any check fails, the model call will be blocked, ensuring that the system is always in a controllable state and avoiding system crashes or unpredictable behavior caused by resource overruns.

[0036] 4. Model interaction stage.

[0037] The model interaction phase is the core of the iterative process, responsible for interacting with the language model and processing responses. This phase introduces an innovative predictive state transition mechanism: (1) Output stream monitoring and real-time analysis During the model's streaming output, the system continuously monitors the output stream and parses the output token sequence in real time. This real-time parsing does not wait for the complete response before processing; instead, analysis and prediction begin as the response is gradually generated.

[0038] (2) Response structure prediction Based on the partially output content, the system predicts the complete response structure, including: Does it include external operation calls? This determines whether the model's response will trigger tool calls or other external operations. This determination can usually be made when the first token is output, with an accuracy rate of over 95%.

[0039] Operation type identification: If an external operation is predicted to be invoked, the specific type of operation is further identified, such as file read / write, network request, code execution, etc. This prediction can usually be completed within the first 3-5 token outputs, with an accuracy rate of over 90%.

[0040] (3) Resource preparation Before the model response is complete, the system prepares the corresponding resources in advance based on the prediction results: Operation definition loading: If it is predicted that a specific tool will be called, load the tool's definition, parameter mode, permission configuration and other information in advance.

[0041] Execution resource pre-allocation: Pre-allocate the computing resources, memory space, network connections, etc. required for tool execution to ensure that tool invocation can begin immediately.

[0042] Environment preparation: For operations that require a special execution environment, initialize the sandbox in advance, set permission boundaries, and prepare input data, etc.

[0043] (4) Prediction verification and rollback Once the model has completed its response, the system compares the predicted results with the actual response: Predictive hit: If the prediction is accurate, the prepared resources can be used directly, greatly reducing the delay time from response completion to tool execution.

[0044] Prediction failure: If the prediction does not match the actual situation, the system performs a fast rollback operation: releases pre-allocated but not actually needed resources; switches to the correct preparation process; records prediction failure information for optimizing the prediction model and adjusting the prediction strategy; the predictive state transition mechanism optimizes the traditional serial process of "waiting for a complete response → analyzing the response → preparing resources → executing operations" into a process of "parallel response generation and resource preparation", which significantly reduces the user's perceived waiting delay.

[0045] (III) Path decision-making and execution.

[0046] Based on the model's response, the system determines whether external operations need to be performed: 1. Tool execution path If the model response contains a tool invocation request, the system enters the tool execution path. The specific tasks of the tool execution path include: Tool call parsing: Parse the tool call request in the model response and extract information such as tool name, call parameters, and expected output.

[0047] Tool execution: Invokes the corresponding tool executor to perform external operations and obtains the execution results.

[0048] Additional message collection: Collects additional messages generated during the execution of the collection tool, including execution logs, status changes, exception information, etc.

[0049] Tool definition refresh: Refreshes the tool definition and availability status based on execution results and context changes.

[0050] Next state assembly: Integrate the tool execution results, additional messages, etc. into the state object to form the state object for the next iteration, and continue to execute the iteration process.

[0051] 2. Terminal Decision-Making Path If the model response does not contain a tool call request, the system enters the terminal decision path. At this point, the system attempts multiple state recovery schemes sequentially based on the preset recovery strategy priority.

[0052] This invention establishes a four-level recovery strategy priority, in descending order of priority: Level 1: Folding and Emptying Check if any temporary collapsed summaries exist. If so, commit these summaries and release the context space occupied by the collapsed content. Collapse emptying is the lightest recovery method and does not result in substantial loss of dialogue content.

[0053] Second stage: Reactive compression If folding and emptying fail to resolve the issue, reactive compression is triggered. Reactive compression applies a more aggressive compression process to the current context, including: Perform in-depth summarization of historical dialogues; merge similar dialogue fragments; remove low-value contextual information; and compress the detailed content of the tool's execution results.

[0054] Level 3: Limit Upgrade If reactive compression still fails to resolve the issue, try increasing the resource cap. This includes: Request a larger context window quota; switch to a model version that supports longer contexts; temporarily increase resource budget limits.

[0055] Level 4: Resource Recovery If none of the above strategies resolve the issue, perform resource recovery. This includes: Clear system cache and temporary resources; release unnecessary resource usage; reset part of the execution environment state; in extreme cases, it may be necessary to restart the dialog or roll back to a previous checkpoint.

[0056] The system attempts these strategies sequentially according to priority. Once a strategy successfully resolves the problem, it stops trying subsequent strategies. This priority-based trial mechanism ensures that the system always prioritizes the recovery solution with the lowest cost and least impact.

[0057] (iv) Terminal status generation.

[0058] Finally, the system generates a terminal state object, which contains the following key information: 1. Reason for termination: Describe the specific reason that caused the conversation to terminate, such as task completion, user interruption, resource exhaustion, error occurrence, etc.

[0059] 2. Status Classification: Classify the final status, such as normal completion, abnormal termination, interruption pending recovery, etc., to facilitate subsequent processing and statistical analysis.

[0060] 3. Triggering conditions: Record the specific conditions and thresholds for triggering termination, such as reaching the maximum number of rounds, exceeding the resource budget, receiving a termination signal, etc.

[0061] The terminal status object provides a complete status snapshot for system monitoring, logging, and user feedback.

[0062] (v) Continuation type label and interruption detection.

[0063] This invention also introduces two important auxiliary mechanisms: 1. Continuation type tag The system introduces a continuation type labeling mechanism, assigning a unique type label to each possible recovery path. Through continuation type labels, the system can assert the type of the recovery path without examining the message content. The advantages of this design include: Efficiency improvement: It avoids the overhead of parsing and inspecting message content, and directly determines the processing path through tags.

[0064] Enhanced reliability: It avoids errors that may occur during message content parsing and improves the accuracy of recovery path determination.

[0065] Code simplification: Makes the state transition logic clearer, easier to understand and maintain.

[0066] 2. Interrupt signal detection The system supports detecting "started but not completed" signals to identify interrupted dialogue rounds. This mechanism works by: Start Mark Record: Record the start mark and expected completion conditions at the beginning of each round of dialogue.

[0067] Completion Status Monitoring: Continuously monitor the completion status of each dialogue round and check whether the expected completion conditions are met.

[0068] Interruption identification: When a start marker is detected but the completion condition is not met, the dialogue round is identified as interrupted.

[0069] Interruption handling: Special handling is performed on interrupted dialogue rounds, such as saving intermediate states, generating interruption reports, and supporting subsequent recovery.

[0070] The interruption signal detection mechanism enables the system to identify and handle dialogue interruptions caused by various reasons, including user-initiated interruptions, system abnormal interruptions, and network interruptions, thus ensuring the continuity and recoverability of the dialogue.

[0071] II. System Technical Solution.

[0072] The present invention also provides a state machine-based intelligent agent query loop control system, which, in contrast to the method, includes the following core modules.

[0073] (a) Status Management Module.

[0074] The state management module is the core data management unit of the system, responsible for building and maintaining state objects. Its main functions include: Initialize the state object, setting the initial dialogue context, resource status, and environment configuration; Update the state object after each iteration and record the state transition history; Provides a status query interface to allow other modules to obtain status information; Implement state persistence, supporting the saving and restoration of state; The state management module adopts an immutable state design. Each iteration creates a new state through an expansion operation, ensuring the explicitness and completeness of state transitions.

[0075] (ii) Iterative processing module.

[0076] The iterative processing module is the core execution unit of the system, responsible for executing the iterative processing flow based on state objects. This module includes four sub-units: 1. Preprocessing Unit: Responsible for preprocessing tasks such as deconstructing state objects, initializing the tracing mechanism, starting prefetching operations, and creating the budget tracker.

[0077] 2. Context Management Unit: Responsible for executing the context optimization pipeline, including external operation result budget management, context fragment compression, fine-grained compression processing, context folding, and automatic compression triggering. This unit executes these five operations in a strict order.

[0078] 3. Constraint Checking Unit: Responsible for performing hard constraint checks before model invocation, verifying constraints such as context length, resource budget, and permission configuration to prevent context size from getting out of control.

[0079] 4. Model Interaction Unit: Responsible for interacting with the language model, sending requests and receiving responses, and processing streaming output.

[0080] (III) Prediction Module.

[0081] The prediction module is an innovative module in this system, responsible for implementing the predictive state transition mechanism. This module consists of four sub-units: 1. Parsing Unit: Parses the output sequence in real time during the model's streaming output process, extracting token-level response information.

[0082] 2. Prediction Unit: Predicts the complete response structure based on the output content, including whether it contains external operation calls and the operation type. This unit implements an efficient prediction algorithm that can accurately predict the response structure early in the output process.

[0083] 3. Preloading Unit: Loads operation definitions and pre-allocates execution resources, including tool definitions, computing resources, memory space, network connections, etc., before the model response is completed.

[0084] 4. Rollback Unit: Performs a fast rollback operation when the prediction does not match the actual result, releases pre-allocated resources, switches to the correct preparation process, and records prediction failure information for model optimization.

[0085] The prediction module uses a parallel processing mechanism to synchronize resource preparation with model response generation, which significantly reduces system response latency.

[0086] (iv) Path decision module.

[0087] The path decision module is responsible for determining the subsequent processing path based on the model's response content. The main functions of this module include: Analyze the model response content to identify whether it contains tool call requests; For responses containing tool calls, route to the tool execution path; For responses that do not contain tool calls, route to the terminal decision path; Handle edge cases, such as abnormal response formats or unavailable tools.

[0088] (v) Recovery module.

[0089] The recovery module is responsible for handling state recovery in the terminal decision path. Its main functions include: Implement a four-level recovery strategy: collapse and emptying, reactive compression, upper limit upgrade, and resource recovery; Try different recovery strategies in order of priority; Monitor the recovery results to decide whether to continue trying the next strategy; Record the recovery process and results to support auditing and optimization; The recovery strategy priorities of the recovery module are as follows: collapse and emptying, reactive compression, upper limit upgrade, and resource recovery. This priority setting ensures that the system always prioritizes the recovery method with the lowest cost and least impact.

[0090] (vi) Terminal status generation module.

[0091] The terminal state generation module is responsible for generating a terminal state object when the dialogue ends. The main functions of this module include: Collect relevant information about the termination of the conversation, including the reason for termination, status classification, and triggering conditions; Generate standardized terminal state objects; Provides interfaces for persisting and querying terminal states; It supports statistical analysis and visualization of terminal status. Attached Figure Description

[0092] Figure 1 This is a diagram of the overall system architecture, showing the complete architecture of the state machine control system, including core components such as the state management module, iterative processing module, and prediction module. It marks the data flow and interaction relationships between each module, and specifically marks the transmission path of state objects.

[0093] Figure 2 This is a flowchart of the state machine iterative processing, which details the execution flow of the preprocessing stage, context management stage, constraint checking stage, and model interaction stage. It marks the key operations and state transition conditions of each stage and provides examples of the immutable design implementation of state objects.

[0094] Figure 3 This diagram illustrates the predictive state transition mechanism, showcasing the real-time parsing and prediction process during the model's streaming output. It includes key steps such as token sequence parsing, response structure prediction, and resource pre-allocation, and highlights the fast rollback process when prediction fails.

[0095] Figure 4This is an execution sequence diagram for the context management phase, which details the execution order of external operation result budget management, context fragment compression, fine-grained compression processing, context folding, and automatic compression triggering, and marks the input and output relationships of each operation.

[0096] Figure 5 The recovery strategy priority state diagram shows the execution priority of four recovery strategies: collapse emptying, reactive compression, upper limit upgrade, and resource recovery, and marks the triggering conditions and transformation relationships of each strategy.

[0097] Figure 6 This is a flowchart of the terminal decision-making path, showing the complete decision-making process from model response to the generation of terminal state objects. It includes key steps such as external operation judgment, recovery strategy attempt, and terminal state generation, and marks the processing logic of interrupt signal detection.

[0098] Figure 7 This is a schematic diagram of the tool execution path, showing the entire process of external operation execution, including key steps such as operation definition refresh, additional message collection, and state object assembly, and marking the resource budget tracking mechanism.

[0099] Figure 8 This diagram illustrates the interaction relationships among components in the preprocessing stage, including the query tracing mechanism, non-blocking prefetching operations, and the resource budget tracker. It also marks key data extraction points from the state object deconstruction. Detailed Implementation

[0100] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0101] Example 1: Query loop control method based on predictive state transition.

[0102] This embodiment provides a specific implementation of a query loop control method based on predictive state transitions. This method transforms passive response into active prediction by parsing the sequence content and predicting subsequent processing paths in real time during model output, significantly reducing system latency.

[0103] Step S1: State object construction.

[0104] First, the system creates an initial state object. This state object adopts an immutable design and contains the following core components, illustrated in pseudocode (the same applies below): classSessionContext{ readonlyinteractionLog:InteractionEntry[]; readonlycapabilityRegistry:CapabilityRegistry; readonlycompactionHistory:CompactionRecord[]; readonlyrejuvenationTally:number; readonlyadaptiveCompactionFlag:boolean; readonlyquotaOverride:number|null; readonlypendingCapabilityDigest:string|null; readonlyterminationSignal:TerminationSignal|null; readonlycycleCounter:number; readonlymutationLog:MutationEntry[]; }

[0105] Among them, interactionLog stores all interaction records during the dialogue; capabilityRegistry records the definition and status of available functions; compactionHistory monitors the history of context compression operations; rejuvenationTally records the number of resource recovery operations; adaptiveCompactionFlag indicates whether adaptive compression is triggered; quotaOverride is used to temporarily adjust resource limits; pendingCapabilityDigest caches summary information of function execution results; terminationSignal records external interruption signals; cycleCounter tracks the current dialogue round; and mutationLog saves the complete state transition history.

[0106] Step S2: Preprocessing stage.

[0107] The following operations are performed during the preprocessing stage: asyncfunctionpreparePhase(ctx:SessionContext):Promise <prepareoutput>{ const{interactionLog,capabilityRegistry,compactionHistory}=ctx; constqueryTracer=initQueryTracer(); constprefetchTasks=launchPrefetchOps(interactionLog,capabilityRegistry); constquotaMonitor=createQuotaMonitor(ctx.quotaOverride); return{queryTracer,prefetchTasks,quotaMonitor}; }

[0108] Deconstruct the state object to obtain the current context information; initialize the query tracing mechanism; start non-blocking prefetch operations, including data prefetching and function prefetching; create a resource quota monitor.

[0109] Step S3: Context Management Phase.

[0110] The context management phase performs the following operations in a strict order: function contextMgmtPipeline( ctx:SessionContext, QuotationMonitor: QuotaMonitor ):SessionContext{ letprocessedCtx=applyCapabilityResultQuota(ctx,quotaMonitor); processedCtx=applySnippetCompaction(processedCtx); processedCtx=applyMicroCompaction(processedCtx); processedCtx=applyContextCollapse(processedCtx); processedCtx=applyAutoCompaction(processedCtx); returnprocessedCtx; }

[0111] Function result quota management: Check the size of function execution results and truncate or summarize them if they exceed the quota; Fragment compression: Compress long fragments in the interaction record to retain key information; Micro compression: Perform fine-grained compression operations; Context folding: Fold early multi-turn dialogues into summary form; Automatic compression: Trigger necessary automatic compression operations based on compression history.

[0112] Step S4: Constraint Check Phase.

[0113] Before invoking the model, the system performs hard constraint checks to prevent the context size from getting out of control. The constraint checks include: verifying that the number of units in the current context sequence is within the allowed range; checking that the round counter has exceeded the maximum limit; and verifying that the resource quota is sufficient.

[0114] functionenforceConstraintCheck( ctx:SessionContext, cfg:SystemConfig ):ConstraintOutcome{ constunitCount=estimateUnitCount(ctx.interactionLog); if(unitCount>cfg.maxUnitLimit){ return{passed:false,reason:'UNIT_LIMIT_EXCEEDED'}; } if(ctx.cycleCounter>cfg.maxCycles){ return{passed:false,reason:'CYCLE_LIMIT_EXCEEDED'}; } return {passed: true}; }

[0115] Step S5: Predictive model interaction phase.

[0116] The model interaction phase is the core innovation of this embodiment. The system not only calls the model to obtain responses, but more importantly, it analyzes and predicts in real time during the model output process, realizing predictive state transitions.

[0117] asyncfunctionpredictiveInteractionPhase( ctx:SessionContext, modelCfg:ModelConfig ):Promise <interactionoutcome>{ conststream=awaitinvokeModelStream(ctx.interactionLog,modelCfg); constforecaster=createForecaster(); constresourcePreparer=createResourcePreparer(); letcompleteResponse=''; forawait(const unitofstream){ completeResponse += unit; forecaster.ingestUnit(unit); if(forecaster.shouldPrepareResources()){ constpredictedCapabilities=forecaster.forecastCapabilityInvocations(); resourcePreparer.prepareForCapabilities(predictedCapabilities); } } return{ response:completeResponse, forecast:forecaster.getForecast(), preparedResources:resourcePreparer.getPreparedResources() }; }

[0118] Detailed implementation of the prediction engine.

[0119] The prediction engine is responsible for parsing sequence units in real time during the model's streaming output process and predicting the complete response structure based on the output content.

[0120] classForecaster{ privateunitBuffer:string[]=[]; privateforecastState:ForecastState='INITIAL'; privatepredictedCapabilities:string[]=[]; privateconfidenceLevel:number=0; ingestUnit(unit:string):void{ this.unitBuffer.push(unit); if(this.unitBuffer.length>50){ this.unitBuffer.shift(); } this.refreshForecast(); } privaterefreshForecast():void{ constbufferStr=this.unitBuffer.join(''); if(bufferStr.includes('<capability_invoke>')){ this.forecastState='CAPABILITY_DETECTED'; this.confidenceLevel=0.99; this.extractCapabilityName(bufferStr); }elseif(this.unitBuffer.length>=3){ constfirstThree=this.unitBuffer.slice(0,3).join(''); if(this.resemblesCapabilityCall(firstThree)){ this.forecastState='LIKELY_CAPABILITY'; this.confidenceLevel=0.90; } } } shouldPrepareResources():boolean{ returnthis.forecastState!=='INITIAL'&&this.confidenceLevel>0.85; } forecastCapabilityInvocations():string[]{ returnthis.predictedCapabilities; } }

[0121] Fast rollback mechanism.

[0122] When the predicted results do not match the actual results, the system executes a fast rollback mechanism to release pre-allocated resources and switch to the correct processing path.

[0123] classRollbackCoordinator{ privateresourcePreparer:ResourcePreparer; privateforecastLogger:ForecastLogger; asyncexecuteRollback( forecast: Forecast, actual: Actual Outcome ):Promise <rollbackoutcome>{ const startTime = Date.now(); awaitthis.releasePreallocatedResources(forecast); constcorrectPath=this.determineCorrectPath(actual); this.forecastLogger.logMismatch({ forecasted: forecast actual, rollbackDuration:Date.now()-startTime }); return{success:true,correctPath}; } }

[0124] Step S6: Multi-layer recovery path.

[0125] When entering the terminal decision path, the system attempts multiple state recovery schemes in order of priority.

[0126] classRecoveryScheduler{ privatestrategies:RecoveryApproach[]=[ newCollapseDrainApproach(), newAdaptiveCompactionApproach(), newLimitUpgradeApproach(), newResourceRejuvenationApproach() ]; asyncattemptRecovery(ctx:SessionContext):Promise <recoveryoutcome>{ for(constapproachofthis.strategies){ if(awaitapproach.isApplicable(ctx)){ constoutcome=awaitapproach.execute(ctx); if(outcome.success){ return{success:true,approach:approach.name,newCtx:outcome.ctx}; } } } return{success:false,reason:'ALL_APPROACHES_FAILED'}; } }

[0127] Example 2: Query loop control system based on immutable state design.

[0128] This embodiment provides a specific implementation of a query-based cyclic control system designed with immutable states. The system ensures explicit and complete state transitions through immutable state objects, providing full state traceability capabilities.

[0129] System Overall Architecture The system includes the following core modules: classAgentQueryControlSystem{ privatectxManager:ContextManager; privatecycleProcessor:CycleProcessor; privateforecasterModule:ForecasterModule; privatepathDecider:PathDecider; privaterejuvenationModule:RejuvenationModule; privatefinalStateGenerator:FinalStateGenerator; constructor(cfg:SystemConfig){ this.ctxManager=newContextManager(cfg); this.cycleProcessor=newCycleProcessor(cfg); this.forecasterModule=newForecasterModule(cfg); this.pathDecider=newPathDecider(cfg); this.rejuvenationModule=newRejuvenationModule(cfg); this.finalStateGenerator=newFinalStateGenerator(cfg); } }

[0130] Continue the type tagging mechanism.

[0131] This embodiment introduces a continuation type labeling mechanism, which can assert the type of recovery path without checking the message content.

[0132] typeContinuationLabel= |'INITIAL_QUERY' |'CAPABILITY_RESULT_PENDING' |'COMPACTION_APPLIED' |'COLLAPSE_DRAINED' |'RECOVERY_EXHAUSTED'; classLabeledContextextendsSessionContext{ readonlycontinuationLabel:ContinuationLabel; withLabel(label:ContinuationLabel):LabeledContext{ returnnewLabeledContext({...this,continuationLabel:label}); } getRecoveryPathType():RecoveryPathType{ switch(this.continuationLabel){ case'CAPABILITY_RESULT_PENDING': return'AWAITING_CAPABILITY_COMPLETION'; case'COMPACTION_APPLIED': return'POST_COMPACTION_RECOVERY'; case'COLLAPSE_DRAINED': return'POST_COLLAPSE_RECOVERY'; default: return 'STANDARD_RECOVERY'; } } }

[0133] Interruption detection mechanism.

[0134] This embodiment supports the detection of signals that have started but not yet completed, which can be used to identify interrupted dialogue rounds.

[0135] interfaceTerminationSignal{ kind:'USER_INTERRUPT'|'TIMEOUT'|'ERROR'; timestamp:number; partialOutcome?:unknown; } classInterruptionMonitor{ privateactiveOperations:Map<string,OperationStatus> =newMap(); markOperationStarted(operationId:string):void{ this.activeOperations.set(operationId,{ status:'IN_PROGRESS' startedAt:Date.now() }); } markOperationCompleted(operationId:string):void{ this.activeOperations.delete(operationId); } detectIncompleteOperations():IncompleteOperation[]{ constincomplete:IncompleteOperation[]=[]; for(const[id,status]ofthis.activeOperations){ if(status.status==='IN_PROGRESS'){ incomplete.push({id,startedAt:status.startedAt}); } } return incomplete; } }

[0136] Main execution process.

[0137] The following is the implementation of the system's main execution flow: asyncfunctionexecuteQueryLoop( system:AgentQueryControlSystem, initialInput:UserInput ):Promise <finalstate>{ letctx=system.ctxManager.createInitialContext(initialInput); while(!shouldTerminate(ctx)){ constcycleOutcome=awaitsystem.cycleProcessor.process(ctx); if(cycleOutcome.requiresCapabilityExecution){ ctx=awaitexecuteCapabilityPath(system,ctx,cycleOutcome); }else{ constrecoveryOutcome=awaitsystem.rejuvenationModule.attemptRecovery(ctx); if(recoveryOutcome.success){ ctx = recoveryOutcome.newCtx; }else{ break } } } returnsystem.finalStateGenerator.generate(ctx); } functionshouldTerminate(ctx:SessionContext):boolean{ returnctx.terminationSignal!==null||ctx.cycleCounter>=MAX_CYCLES; }

[0138] This embodiment employs an immutable state design, creating a new context object for each state change to ensure explicit and complete state transitions. This design offers the following advantages: State traceability: Because a new object is created for each state transition, the system can completely record the state transition history, facilitating problem localization and auditing. Concurrency safety: Immutable objects are inherently thread-safe, requiring no additional synchronization mechanisms. Debugging convenience: Developers can capture state snapshots at any time for offline analysis and problem reproduction.

[0139] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / finalstate> < / recoveryoutcome> < / rollbackoutcome> < / interactionoutcome> < / prepareoutput>

Claims

1. A state machine-based intelligent agent query loop control method, characterized in that, Includes the following steps: Construct a state object, which includes dialogue context information, resource usage status, execution environment configuration, and state transition history; Iterative processing is performed based on the state object, and the iterative processing includes a preprocessing stage, a context management stage, a constraint checking stage, and a model interaction stage. During the model interaction phase, the model output stream is monitored, the subsequent processing path is predicted based on a portion of the output content, and corresponding resources are prepared in advance. Determine whether external operations need to be performed based on the model's response. If so, proceed to the tool execution path; otherwise, proceed to the terminal decision path. When entering the terminal decision path, multiple state recovery schemes are tried sequentially based on the preset recovery strategy priority; Generate a terminal state object containing the termination reason, state category, and triggering conditions.

2. The method according to claim 1, characterized in that, The prediction of subsequent processing paths based on partial output content includes: During the model streaming output process, the output sequence is parsed in real time; Predict the complete response structure based on the output content, including whether it contains external operation calls and the operation type; Before the model response is complete, load the operation definitions and pre-allocate execution resources. If the prediction does not match the actual result, perform a fast rollback, including releasing pre-allocated resources, switching to the correct preparation process, and logging prediction failure information for model optimization.

3. The method according to claim 1, characterized in that, The state object adopts an immutable design, and a new state is created in each iteration through an expansion operation, ensuring that state transitions are explicit and complete.

4. The method according to claim 1, characterized in that, The context management phase performs the following operations in a strict sequence: external operation result budget management; context fragment compression; fine-grained compression processing; context folding; and automatic compression triggering.

5. The method according to claim 1, characterized in that, The constraint checking phase performs hard constraint checks before model invocation to prevent context size from getting out of control.

6. The method according to claim 1, characterized in that, The recovery strategies are prioritized as follows: folding and emptying, reactive compression, upper limit upgrade, and resource recovery.

7. The method according to claim 1, characterized in that, Introducing continuation type tags allows assertions about the type of recovery path without inspecting message content; supports detecting "started but not completed" signals to identify interrupted conversation rounds.

8. A state machine-based intelligent agent query loop control system, characterized in that, include: The state management module is used to build and maintain state objects, which include dialogue context information, resource usage status, execution environment configuration, and state transition history. The iterative processing module is used to perform iterative processing based on the state object, including a preprocessing unit, a context management unit, a constraint checking unit, and a model interaction unit; The prediction module is used to monitor the output stream during the model output process, predict the subsequent processing path based on part of the output content, and prepare the corresponding resources in advance. The path decision module is used to determine whether an external operation needs to be executed based on the model's response content. If so, it enters the tool execution path; otherwise, it enters the terminal decision path. The recovery module is used to attempt multiple state recovery schemes sequentially based on the preset recovery strategy priority when entering the terminal decision path; The terminal status generation module is used to generate terminal status objects that include termination reasons, status classifications, and triggering conditions.

9. The system according to claim 8, characterized in that, The prediction module includes: The parsing unit is used to parse the output sequence in real time during the model streaming output process; The prediction unit is used to predict the complete response structure based on the output content; The preloading unit is used to load operation definitions and pre-allocate execution resources before the model response is completed; The rollback unit is used to perform a fast rollback and switch to the correct path when the prediction does not match the actual result.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images