A physical intelligent bounded round cycle execution method and system

Abstract

The application discloses a kind of body intelligence bounded round cycle execution method and system, method includes the following steps: S1, the initial setting of establishing task to the decomposition mapping of operation and session level budget;S2, round budget contract is built and loaded contract;S3, activate four cycle detectors collaborative work;S4, execute sliding window cross round repetition detection strategy;S5, recycle the round result of this round, merge to session level result set;If cumulative round number reaches the upper limit of session configuration preset, session is forced to terminate;S6, after session termination, system determines subsequent subsequent execution path according to the state field of each round result and the return decision of contract capability module.The determination boundary of polling and cycle is clearly defined by the four detector collaborative strategy, the misjudgment rate is reduced, and the system can actively intervene before the cycle mode is solidified as irreversible session failure, rather than being terminated passively after consuming the entire session round number.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and robotics, specifically to a bounded round-loop execution method and system for embodied intelligence. Background Technology

[0002] When a large language model drives an embodied intelligent agent to perform physical operations, the actuators such as the robotic arm, chassis, and gripper continuously interact with the physical environment according to the tool call instructions output by the large language model. These operations have a longer execution cycle than purely computational tasks. A single grasping or navigation action typically lasts from several seconds to several minutes, during which sensor data continuously floods in, and new task instructions may arrive at any time. The system needs to maintain the ability to respond to environmental changes and instruction switching while maintaining the current operation.

[0003] The general principle in this field is that agents plan and make decisions at fixed time intervals, while executors continuously run physical operations according to the planning results. When a large language model gets stuck in a loop of repeatedly calling the same tool and obtaining the same result each time without advancing the task, the system cannot rely on the model itself to perceive and stop. Instead, the framework needs to provide mandatory bounded execution guarantees to proactively terminate the current round when an abnormal loop is detected, thus avoiding the meaningless consumption of computing resources and interface budget. Tool calls refer to external function calls initiated by the large language model during inference. Each round of calls incurs interface fees and consumes computing budget. In a multi-agent collaborative environment, the operation of agents relies on the underlying computing budget allocation and runtime monitoring system. Faced with the hard constraint of the economic cost ceiling for each call by the large language model, a unified budget control capability needs to be established at both the single-round and complete-session levels.

[0004] The inventors are aware of the following prior art related to the technical solution of this invention: Chinese invention patent application CN122021703A, entitled "An Integrated Governance System and Method for Multi-Agent Contract Cost Assessment Based on Pattern Priority," discloses a multi-agent governance system for resource-constrained scenarios. This paper establishes a unified family of agent data patterns through a pattern definition component, models the multi-agent collaboration process as a constrained Markov decision process, and uses Lagrange relaxation techniques to integrate budget constraints at each level into the objective function for online adjustment. However, the budget mechanism in this paper only applies to optimization at the task allocation stage and model level selection, failing to extend into the round execution loop to form a double-nested budget contract. It also lacks an in-round loop detector operating at the tool invocation granularity. Furthermore, its overspending determination is based on periodic aggregation rather than real-time comparison at the checkpoint level, making it unable to provide immediate forced exit in scenarios where tools are repeatedly invoked within a single round.

[0005] The specification describes in detail its schema definition, multi-level budget aggregation and constraint optimization mechanism in paragraphs

[0021] to

[0025] and paragraphs

[0036] to

[0058] .

[0006] Chinese invention patent CN121125668B, entitled "Chat System for Executing Tasks Including Multiple Rounds," discloses a multi-round task execution system based on a state manager. This patent achieves structured management of task states through three levels of environment variable configuration: experimental, session, and round. The workflow drives each round's execution using a state machine approach, and the intervention component applies lock control to subtasks based on the completion status of preceding tasks. However, the state manager in this patent maintains business semantic variables such as decision results and settlement results, and does not embed a double-layered nested budget contract at the session and round levels within the round execution loop. Its intervention component only detects whether preceding tasks are completed and adds lock records accordingly, without involving loop pattern recognition and forced exit determination at the tool call granularity. Furthermore, it lacks cross-round tool call signature-level duplicate detection capabilities, failing to identify hidden loops where agents execute the same toolchain and obtain the same output across multiple rounds.

[0007] Paragraphs

[0008] to

[0025] and paragraphs

[0049] to

[0058] of this specification describe in detail its state manager, workflow state machine, intervention components, and environment variable configuration mechanism.

[0008] Chinese invention patent application CN122287696A, entitled "Task Execution Control Method Based on Execution Semantic Agent and Its Application," proposes a hierarchical task control scheme centered on an execution semantic agent. This scheme unifies execution semantic frames and execution semantic compilation chains to compile high-level task semantics into structured action contracts, achieving decoupling between interaction semantics and action control. The action contracts include skill sequences and execution constraints. However, the execution constraints of this scheme focus on the projection of safety boundaries and resource limits, rather than a two-layer budget control embedded in the round execution loop through real-time deduction. Its compilation chain handles the transformation from task semantics to action contracts, lacking the ability to perform multi-detector collaborative loop judgment at the tool call granularity. The constraints of the action contracts are mainly based on skill sequences and spatial safety, without addressing the sliding window repetition detection of cross-round tool call signature sequences, and thus failing to detect hidden loops of executing the same toolchain across multiple rounds.

[0009] Paragraphs

[0008] to

[0019] and paragraphs

[0024] to

[0032] of this specification describe in detail its unified execution semantic frame, execution semantic compilation chain and action contract assembly mechanism.

[0010] Based on the analysis of the aforementioned background technologies, embodied intelligence long-term operation faces the following technical challenges at the execution control level: Regarding budget control, existing solutions primarily focus on strategy optimization during the task allocation phase, failing to delve into the formation of a double-layered nested budget contract at both the session and round levels within the round execution loop. The lack of checkpoint-level real-time budget comparison and forced exit mechanisms for tool call rounds within a single round allows large language models to repeatedly generate homogeneous tool calls within a single round, consuming and eventually exhausting the entire session-level budget without constraint.

[0011] Regarding loop detection, most existing methods only react passively to exceeding the call limit, making it difficult to distinguish between legitimate queries and infinite loops when known polling tools return different results each time. Furthermore, the ABAB hidden loop pattern, where tool A and tool B are called alternately without producing substantial progress, also falls outside the detection scope, making it impossible to distinguish between legitimate polling and harmful loops.

[0012] In terms of session management, existing solutions lack the ability to identify repeated tool call sequences across rounds. They cannot detect hidden loops where agents execute the same toolchain and obtain the same output in multiple rounds, thus forming a continuous repetitive pattern within the sliding window. Before such loops solidify into irreversible session failures, the system has no way to actively intervene and can only passively wait for the number of session-level rounds to be exhausted before terminating the session. Summary of the Invention

[0013] To address the problems existing in the prior art, this invention proposes a bounded round-loop execution method and system for embodied intelligence. The technical solution of this invention is as follows.

[0014] This invention provides a bounded round-loop execution method for embodied intelligence, comprising the following steps: S1. Establish the task-to-operation decomposition mapping and initial settings for session-level budget; S2. Construct and load the round-budget contract; S3. Activate the four cyclic detectors to work together; S4. Execute the sliding window cross-round duplicate detection strategy; S5. Collect the results of this round and merge them into the session-level result set; if the cumulative number of rounds reaches the upper limit set by the session configuration, the session is forcibly terminated. S6. After the session terminates, the system determines the subsequent execution path based on the status fields of each round's results and the return decision from the contract capability module.

[0015] Preferably, step S1 specifically includes the following steps: S11. The upper-layer task orchestration module receives natural language instructions, performs semantic parsing and intent classification on the natural language instructions, orchestrates them into a composite task consisting of N operations, and assigns a unique identifier to the task and each operation. S12. Initialize the session configuration based on the task prediction complexity and write the session-level total budget parameters, including the maximum number of rounds and the thresholds for loop detection.

[0016] Preferably, step S2 specifically includes the following steps: S21. The operation management module creates a round budget contract before the start of each round, setting the maximum number of tool call rounds and the maximum number of model requests for this round. S22. After the round execution engine loads the contract, it decrements the remaining steps of the budget by one at each tool call completion checkpoint and atomically checks whether it has been reduced to zero. If the zero value is reached, the loop immediately exits and the round result status is set to "budget exhausted". If the upper limit has not been reached, the loop continues.

[0017] Preferably, the round result status also includes diagnostic fields such as the number of rounds consumed, the name of the last tool called, and a timestamp.

[0018] Preferably, step S3 specifically includes the following steps: S31. After each tool call is completed, the round execution engine sends the tool name, parameter hash value and result hash value of this call to the detector module. Each detector determines and generates a signal according to its independent triggering conditions. S32. After any detector generates a blocking signal, the engine immediately stops the round loop, sets the round result status to "loop blocking", and attaches the name of the triggering detector, the cumulative number of repetitions and the trigger timestamp in the return body; S33. When the detector outputs an alarm-level signal instead of a blocking-level signal, the engine transmits the signal to the contract capability module, which returns a decision of "continue" or "exit round" according to preset rules. S34. Before each call to the large language model, the engine checks whether the number of requests sent in this round has reached the contract limit; if the limit has been reached, the round loop is exited and the round status is marked as "budget exhausted".

[0019] Preferably, the four cyclic detectors are a fuse detector, a polling detector, an alternating detector, and a generalized detector.

[0020] Preferably, the circuit breaker's determination logic is as follows: ignoring the tool's type, a blocking signal is directly generated when the cumulative length of the historical call record reaches a preset upper limit; the polling detector's determination logic is as follows: for pre-registered polling tools, the no-progress count is increased only when the hash values ​​of the results returned by multiple consecutive calls are exactly the same, thus distinguishing between reasonable polling and infinite loops; the alternation detector's determination logic is as follows: caching the tool names of the two most recent rounds, a signal is triggered when an ABAB alternation pattern is identified and the parameters and results of each round do not change substantially, and the consecutive rounds of this pattern reach a threshold; the generalization detector's determination logic is as follows: for non-polling tools, the number of consecutive calls with the same tool name and parameter hash value is counted.

[0021] Preferably, step S4 specifically includes the following steps: S41. After each round, the system extracts the exit status and tool call signature from the round record and constructs a JSON payload: the tool name and parameter hash of each call in the tool call sequence are arranged into an array in chronological order, serialized by key sorting to obtain a JSON string, and then the deterministic digest value of the string is calculated as the round signature for this round. S42. The history queue is implemented as a double-ended queue with a fixed capacity. New signatures are appended to the tail. When the queue length exceeds the capacity limit, the oldest entry at the head is automatically removed to form a natural forget window. If no tool calls occur in this round and only natural language interaction is involved, the entire history queue is cleared before an empty signature is written. S43. Traverse from the latest item to the oldest item in the queue, and accumulate the number of items that are consecutively consistent with the latest signature. Stop traversing once the first inconsistent signature is encountered. S44. When the number of consecutive matches reaches the alarm threshold or blocking threshold, the strategy generates a loop signal and forwards it to the contract capability module. The contract capability module decides to reduce the frequency of tool calls, simplify operation parameters, or terminate the session early based on the signal level and the current session status.

[0022] On the other hand, the present invention provides an embodied intelligence bounded round-loop execution system, applied to the aforementioned embodied intelligence bounded round-loop execution method, characterized in that it comprises the following modules: The session and turn control module is deployed locally during robot runtime. It is used to receive natural language commands and upper-level scheduling events, maintain session and turn records, and perform session-level budget limit control according to session configuration. The round budget contract module is deployed on the robot's local runtime and is used to define and verify round execution constraints. The constraints it manages include the maximum number of tool calls and the maximum number of model requests in a single round, both of which are limited to strictly positive integers. The round execution engine module is deployed locally during robot runtime to drive bounded round loops. At each checkpoint, it compares the budget consumption with the upper limit, and forces the robot to exit if the limit is exceeded. It also concurrently triggers loop checks at each tool call completion checkpoint. The round-based loop detection module is deployed locally during robot runtime and is used to implement loop pattern recognition at the tool call granularity. It has four built-in strategies: global circuit breaker, detection of no progress of known polling tools, alternating detection, and generalized repetitive detection, and generates two-level judgment signals: alarm and blocking. The cross-round duplication detection module is deployed locally during robot runtime. It is used to detect cross-round duplication patterns of the signature sequence called by the tool at the round granularity by comparing the sliding window history queue and the tail continuous digest. The Contract Capability Module is deployed locally during robot runtime. It is used to interface with cyclic detection signals and execute custom processing strategies. It supports pluggable configuration. The processing path includes issuing cyclic alarms or blocking signals through the event bus, which allows external callers to decide on subsequent degradation processing.

[0023] Compared with the prior art, the beneficial effects of the present invention are mainly reflected in the following aspects: 1. This invention constrains the maximum number of rounds at the session layer through session configuration, and at the round layer through round budget contracts to constrain the number of tool call rounds and model request counts, forming a nested two-layer budget cap. The round execution engine interfaces with each checkpoint, reconciling real-time consumption with the cap value, and immediately forces an exit if the limit is exceeded. The maximum number of round steps has been transformed from an externally configured parameter into a mandatory semantic of the engine, and the possibility of infinite loops in tool calls within a single round is forcibly terminated by the engine.

[0024] 2. This invention employs a four-detector collaborative strategy that concurrently runs at checkpoints after each tool call in the main loop: For known polling tools, a no-progression repetition check is applied based on result consistency comparison; for non-polling tools, a generalized repetition check is applied based on tool name and parameter hashes. Alternating detectors cover typical hidden loops of ABAB repetitive calls without progress. A global circuit breaker acts as a fallback barrier to prevent new, unknown loops that may emerge in the future. The boundary between polling and loop checks is clearly defined by the four-detector collaborative strategy, reducing the false positive rate.

[0025] 3. This invention maintains a fixed-capacity historical signature queue using a sliding round-robin strategy. In each round, the tool calls a signature calculation digest and continuously compares it with the tail of the queue. Once the number of repeated rounds reaches a preset threshold, the contract capability module is activated. This module receives signals via an event bus and performs custom processing. The system can proactively intervene before the cyclical mode solidifies into an irreversible session failure, rather than passively terminating only after all session rounds have been consumed. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the overall architecture of a bounded round execution system provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of a two-layer budget contract and round-loop execution process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the collaborative workflow of the in-round loop detector provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of cross-round duplicate detection of a sliding window according to an embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. Example 1

[0028] This embodiment provides a bounded round-based loop execution method for embodied intelligence, which specifically includes the following steps: Step S1: The upper-layer task orchestration module receives natural language instructions, orchestrates them into a composite task consisting of N operations, and assigns a unique identifier to each task and operation; initializes the session configuration based on the predicted complexity of the task, and writes the session-level total budget parameters, including the maximum number of rounds and the thresholds for loop detection.

[0029] Step S2: The operation management module generates a round budget contract for the current round, setting the maximum number of tool call rounds and the maximum number of model requests for this round. Both are strictly positive integers, and the "no limit" flag must be explicitly passed by the caller. After the round execution engine loads the contract, it decrements the remaining steps by one at each tool call completion checkpoint and atomically checks whether it is zero. If the limit is reached, it forces an exit, and the round result status is set to "budget exhausted". If the limit is not reached, it continues to loop. This elevates the round execution step limit from external configuration to a mandatory constraint imposed by the engine kernel, forming a double nesting with the session-level round limit in Step S1. The possibility of an infinite loop of tool calls within a single round is forcibly terminated by the engine.

[0030] Step S3: The round execution engine concurrently activates four loop detectors at each tool call completion checkpoint, running them in descending order of priority: circuit breaker, polling detection, alternation detection, and generalization detection. The global circuit breaker triggers a block when the historical call record reaches a threshold, regardless of tool type. The known polling tool's no-progress detection only counts progress when multiple consecutive rounds of result hashes are identical, thus distinguishing between reasonable polling and infinite loops. The alternation detection captures ABAB patterns where tool A and tool B repeatedly call each other with unchanged parameters. The generalization repetition detection counts the number of consecutive calls where non-polling tools have the same tool name and parameter hash. A blocking signal forcibly exits the round, while an alarm signal calls the contract capability module and continues execution. Before each large language model request, the request count is also checked; if the count reaches the limit, the loop is exited.

[0031] Step S4: At the end of each round, a deterministic digest is constructed from the tool call signature sequence and appended to the tail of a fixed-capacity double-ended queue. Assistant text is not included in the signature calculation to avoid language repetition interfering with the judgment of the tool call pattern. If there are no tool calls in the current round, the queue is cleared before an empty signature is written to prevent pure language rounds from maintaining a false cross-round continuous window. A tail-end continuous matching algorithm is used to traverse and count from the latest end of the queue to the oldest end, stopping when a mismatch is encountered, ensuring that the detected object is the current continuous repetition rather than historical occasional similarities. When the number of continuous matches reaches the alarm or blocking threshold, a loop signal is output to the contract capability module. This allows for proactive intervention before the loop solidifies into a session failure.

[0032] Step S5: The round execution engine collects the round results of the current round and merges them into the session-level result set; if the cumulative number of rounds reaches the upper limit preset by the session configuration, the session is forcibly terminated.

[0033] Step S6: After the session terminates, the system determines the subsequent path based on the status field of each round's result and the return decision from the contract capability module: normal completion, entering the next round of the session, or reporting failure. Example 2

[0034] This embodiment provides an embodied intelligent bounded round-loop execution intelligent agent system for performing the above-described methods. The system consists of six core modules, and its overall architecture is as follows: Figure 1 As shown: Module 1: Session and Round Control Module, deployed locally during robot runtime, is used to receive natural language commands and upper-level scheduling events, maintain session and round records, and perform session-level budget cap control based on session configuration.

[0035] Module 2: Round Budget Contract Module, deployed on the robot's local runtime, is used to define and verify round execution constraints. The constraints it manages include the maximum number of tool calls per round and the maximum number of model requests per round, both of which are limited to strictly positive integers.

[0036] Module 3: Round Execution Engine Module, deployed locally during robot runtime, is used to drive bounded round loops. At each checkpoint, it compares the budget consumption with the upper limit, and forces the robot to exit if the limit is exceeded. It also concurrently triggers loop checks at each tool call completion checkpoint.

[0037] Module 4: Intra-round loop detection module, deployed locally during robot runtime, is used to implement loop pattern recognition at the tool call granularity. It has four built-in strategies: global circuit breaker, known polling tool no progress detection, alternating detection, and generalized repetitive detection, and generates two-level judgment signals: alarm and blocking.

[0038] Module 5: Cross-round duplication detection module, deployed locally during robot runtime, is used to detect cross-round duplication patterns of the signature sequence called by the tool at the round granularity by comparing the sliding window history queue and the tail continuous digest.

[0039] Module 6: Contract Capability Module, deployed locally during robot runtime, is used to interface with cyclic detection signals and execute custom processing strategies. It supports pluggable configuration, and the processing path includes issuing cyclic alarms or blocking signals through the event bus, allowing external callers to determine subsequent degradation processing based on this. Example 3

[0040] In this embodiment, the implementation process of the present invention is described in detail using the example of a logistics warehousing robot performing a long-sequence operation at a sorting station: "scanning the barcodes of goods on the shelf and grabbing the specified goods to place them on the outbound conveyor belt." The sorting station refers to the work area in the warehousing environment consisting of shelves, robotic arms, barcode scanners, and outbound conveyor belts. The intelligent agent needs to sequentially invoke tools such as barcode scanning, robotic arm movement, gripper control, and conveyor belt control to complete a complete sorting and handling operation. For example... Figure 1 As shown, this embodiment provides an embodied intelligent long-term operation bounded round loop and budget control system. After natural language instructions are parsed into complex operation sequences by the upper layer, during the execution phase, there may be risks of intra-round or cross-round loops due to the large language model outputting repeatedly similar tool call instructions. The complete execution process of this embodiment is described below in the order of steps S1 to S6.

[0041] Step S1: After receiving the natural language instruction, the upper-layer task orchestration module performs semantic parsing and intent classification. It then calls a pre-built operation template library to map the instruction into a composite task consisting of N operations, assigning a globally unique identifier to each task and operation. Simultaneously, it initializes the session configuration based on the predicted task complexity, writing session-level total budget parameters such as the maximum number of rounds and loop detection thresholds to persistent storage, providing a basis for subsequent engine loading and verification. This step establishes the decomposition mapping from task to operation and the initial setting of the session-level budget, marking the starting point of the two-layer budget contract.

[0042] Step S2: Before driving operation execution, the operation management module first constructs the round budget contract. (See also...) Figure 2 The specific implementation process of the two-tier budget contract and round-loop execution flow is as follows: S2-1: Round Budget Contract Generation. Before each round begins, the operation management module creates a round budget contract, setting the constraint boundaries for this round's execution—the maximum number of tool call rounds and the maximum number of model requests. Both parameters are forced to be non-zero positive integers; negative and zero values ​​are directly rejected by the interface layer. The disable flag, representing "no restrictions," can only be passed as an explicit argument by the caller. The module will not silently replace missing parameters with disable values ​​internally, thus preventing budget constraints from becoming ineffective due to configuration oversights.

[0043] S2-2: Checkpoint Reconciliation and Exit. At each tool call completion checkpoint, the round execution engine decrements the remaining budget steps by one and atomically checks if it has reached zero. Upon reaching zero, the loop immediately exits and the round result status is set to "Budget Exhausted," allowing the upper-level caller to directly distinguish between normal completion and budget exhaustion from the status field. In addition to the status identifier, the round result includes diagnostic fields such as the number of rounds consumed, the name of the last called tool, and a timestamp.

[0044] In a sorting station scenario, a single global counter can lead to the erroneous termination of legitimate long-running tasks due to excessive retries within a single round; counting independently by round fails to detect repeated consumption across rounds. Therefore, this invention employs a two-layer nested budget at the session and round levels: the session layer constrains the maximum number of rounds, while the round layer constrains the number of tool calls and model requests within a single round. The two layers are independently verified and complement each other.

[0045] Step S3 (Key Innovation Steps): Please refer to Figure 3 The implementation details of the round-based loop detector collaborative workflow are as follows: S3-1: Detector chaining. After each tool call, the engine sends the tool name, parameter hash, and result hash to the detector module. Each detector determines and generates a signal based on its independent triggering conditions. There is no strict priority order. The global circuit breaker independently checks the historical length. Known polling tool no-progress detection and generalized repetition detection share the pass condition for the same call. Alternating detection independently checks the ABAB pattern. The decision logic of each detector is as follows: Global Circuit Breaker: Ignoring the type of tool, it generates a blocking signal directly when the cumulative length of historical call records reaches a preset limit, serving as the ultimate barrier against future unknown loop patterns.

[0046] Known polling tool no-progress detection: For pre-registered polling tools, such as conveyor belt status query and robotic arm joint position reading, the no-progress count is only increased when the hash values ​​of the results returned by multiple consecutive calls are exactly the same; the same result hash means that the polling failed to obtain new information, the device status has not actually changed, or the query returned completely consistent results.

[0047] Alternating detection: The tool names of the two most recent rounds are cached. When an alternating ABAB pattern is detected and the parameters and results of each round do not change substantially, and the number of consecutive rounds of this pattern reaches a threshold, a signal is triggered.

[0048] Generalized duplicate detection: For non-polling tools, count the number of consecutive calls with the same tool name and parameter hash value; consistent parameter hash is a clear characteristic of an agent repeatedly calling the same tool with unchanged parameters, which is a typical sign of an infinite loop.

[0049] S3-2: Blocking Signal Processing. After any detector generates a blocking signal, the engine immediately terminates the round loop, sets the round result status to "Loop Blocking", and includes the name of the triggering detector, the cumulative number of repetitions, and the trigger timestamp in the return body.

[0050] S3-3: Alarm Signal Processing. When the detector outputs an alarm level signal instead of a blocking level signal, the engine transmits the signal to the contract capability module, which returns a decision of "continue" or "exit round" based on preset rules.

[0051] S3-4: Exit due to exhaustion of model request count. Before each call to the large language model, the engine checks whether the number of requests sent in this round has reached the contract limit; if the limit has been reached, the round loop is terminated, and the round status is marked as "budget exhausted". This check is independent of the tool call round count, preventing the model requests themselves from continuously consuming interface resources in an unconstrained state, even if no tool call is triggered.

[0052] The earliest version only deployed a generalized duplicate detector. During testing at the sorting station, the conveyor belt status query tool was frequently used. Under normal circumstances, each query returned a different ready status, and the generalized detection failed to recognize this normal behavior because the parameters and return values ​​were constantly changing. However, if the sensitivity was increased by lowering the threshold, reasonable status query operations would be marked as loops. To address this deficiency, a polling tool whitelist mechanism was introduced, applying differentiated judgment rules to tools within the whitelist. However, in scenarios where the equipment was stuck, the whitelist rules still had omissions. The polling operation was indeed performing a reasonable query, but the unchanged result meant that the equipment had malfunctioned and should be considered as no progress rather than normal polling. Based on this analysis, the judgment condition was changed from "same tool name" to "consistent result hash," introducing a no-progress duplicate detection: it is correctly triggered when an unchanged result is polled, and not triggered when a changed result is polled, which aligns with physical intuition. Subsequent research revealed that the ABAB alternating call pattern of "barcode scan failure → switch robotic arm to retry → scan again → retry again" is a typical hidden loop, which cannot be covered by the duplicate detection of a single tool. Therefore, an alternating detector was added. Finally, a global circuit breaker was added as a fallback to prevent the emergence of new, unknown loop patterns. The final priority strategy for the four-detector collaboration was determined, covering four scenarios: known polling, alternating, unknown, and global.

[0053] Step S4: Please refer to Figure 4 The specific operation of the sliding window cross-round duplicate detection strategy is as follows: S4-1: Round Signature Generation. At the end of each round, the system extracts the exit status and tool call signature from the round record and constructs a JSON payload: The tool names and parameter hashes of each call in the tool call sequence are arranged into an array in chronological order, serialized by key to obtain a JSON string, and then a deterministic digest value is calculated from this string as the round signature. Text responses generated by the large language model are excluded from signature calculation because expressions such as "Retrying..." appearing at the text level during the sorting task execution are normal interactions and should not interfere with the duplicate judgment of the tool call sequence.

[0054] S4-2: Sliding History Queue. The history queue is implemented as a fixed-capacity double-ended queue, with new signatures appended to the tail. When the queue length exceeds the capacity limit, the oldest entry at the head is automatically removed, forming a natural forgetting window. If no tool calls occur in the current round and only natural language interaction is involved, the entire history queue is cleared before writing an empty signature. This avoids pure language rounds "continuing" the history window of the tool loop mode, because pure language rounds do not generate tool call progress and should not participate in the continuity determination of the tool call loop.

[0055] S4-3: Tail Consecutive Match Counting. Traverse the queue from the latest item to the oldest item, accumulating the number of items that consecutively match the current latest signature. The traversal stops once the first inconsistent signature is encountered. The tail consecutive matching strategy ensures that it checks "whether it is currently in a repeating state" rather than "whether it has repeated at some point in history"—for example, if the signatures in round 1 and round 10 are the same but different signatures were inserted in between, this situation should not be considered as currently in a loop.

[0056] S4-4: Signal Output and Contract Capability Invocation. When the number of consecutive matches reaches the alarm threshold or blocking threshold, the policy generates a cyclic signal and forwards it to the contract capability module. This module determines, based on the signal level and the current session state, whether to reduce the frequency of tool invocation, simplify operating parameters, or terminate the session early.

[0057] Fixed-window counting methods count identical signatures at any position in the history as repetitions, failing to distinguish between occasional identical signatures and current continuous cycles; full-history counters grow linearly with session length and cannot naturally forget old patterns. This invention employs a fixed-capacity double-ended queue combined with tail-end continuous matching: new signatures overwrite old signatures to achieve a sliding window with forgetting capabilities, tail-end continuous matching focuses only on the current continuous repetition state, and empty tool signatures clear the queue to avoid maintaining false cross-round windows through pure language interaction.

[0058] Step S5: After the round execution is complete and cross-round checks are performed, the round execution engine collects the round results of this round and merges them into the session-level result set. The engine then checks whether the accumulated number of rounds has reached the upper limit preset in the session configuration. If it has, the session is forcibly terminated; otherwise, it proceeds to the next round's budget contract generation and execution process. This step transforms the session-level budget from a declarative parameter into a runtime hard termination condition, ensuring that the session does not extend indefinitely due to abnormal behavior in a single round.

[0059] Step S6: After the session terminates, the system summarizes the status fields of each round's results and the decision records returned by the contract capability module during the session, thereby determining the subsequent execution path. If all rounds complete normally and the contract capability module does not issue a downgrade or termination signal, the session is completed normally. If there are abnormal exits due to budget exhaustion or loop detection, the system selects a path such as entering the next round of the session or reporting a failure, based on the exit reason and the contract capability module's decision. This step unifies the status identifiers and module decisions generated in the previous steps, providing a clear attribution for session termination to the upper-level scheduling.

[0060] The embodiments of the present invention have been described above. However, these embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions, and variations to the embodiments of the present invention within the scope of the present invention. The above embodiments have been described in detail using a logistics warehousing robot for sorting and handling as an example. However, the technical solutions of the present invention are also applicable to other intelligent long-term operation scenarios such as home service robots, industrial inspection robots, and medical rehabilitation robots.

[0061] The core inventive points and protective points of this invention are as follows: (1) Two-layer budget contract and bounded round loop execution engine, corresponding to step S2. This scheme defines the maximum number of sessions at the session level by session configuration, and defines the maximum number of tool calls and the maximum number of model requests in a single round by the round budget contract. The two budget layers are nested to form an upper limit system. The round execution engine compares the current consumption with the preset upper limit in real time at each checkpoint. Once the limit is exceeded, it immediately forces the exit of the round and outputs the round result with a status mark, thus forcibly terminating the possibility of infinite loop within a single round at the engine level.

[0062] (2) Multi-detector collaborative round-based loop detection strategy, corresponding to step S3. This strategy uses a global circuit breaker as an unconditional trigger fallback, covers the polling scenario with no-progression repetitive detection of known polling tools, covers the hidden loop with ABAB alternating mode detection, and covers the general repetitive scenario of non-polling tools with generalized repetitive detection. The four detectors correspond to different trigger conditions. The global circuit breaker is unconditionally triggered to block when the length of the historical call record reaches the threshold. Each of the four detectors generates alarm or blocking signals according to its trigger condition, driving alarm notification and forced interruption respectively. This strategy covers four scenarios: known polling, alternating calls, unknown mode, and large-scale fallback.

[0063] (3) Sliding window cross-round duplicate detection and contract capability module, corresponding to steps S4 to S5. This strategy maintains a historical signature queue with a fixed capacity. After each round, the tool's signature is generated into a digest and compared with the tail of the queue. When the number of consecutive duplicate rounds reaches the alarm or blocking threshold, a loop signal is generated. The contract capability module receives the signal and decides on subsequent processing. The tail continuous matching is limited to detecting whether the current state is duplicated rather than whether it has been duplicated in the past. Empty tool signature rounds clear the queue to prevent pure language interaction from interfering with the detection.

[0064] While the invention has been described herein with reference to specific embodiments, it should be understood that these embodiments are merely examples of the principles and applications of the invention. Therefore, it should be understood that many modifications can be made to the exemplary embodiments, and other arrangements can be designed without departing from the spirit and scope of the invention as defined by the appended claims. It should be understood that different dependent claims and features described herein can be combined in ways different from those described in the original claims. It is also understood that features described in conjunction with individual embodiments can be used in other described embodiments.

Claims

1. A bounded round-loop execution method for embodied intelligence, characterized in that, Includes the following steps: S1. Establish the task-to-operation decomposition mapping and initial settings for session-level budget; S2. Construct and load the round-budget contract; S3. Activate the four cyclic detectors to work together; S4. Execute the sliding window cross-round duplicate detection strategy; S5. Collect the results of this round and merge them into the session-level result set; If the cumulative number of rounds reaches the maximum limit set in the session configuration, the session will be forcibly terminated; S6. After the session terminates, the system determines the subsequent execution path based on the status fields of each round's results and the return decision from the contract capability module.

2. The embodied intelligence bounded round-loop execution method according to claim 1, characterized in that, Step S1 specifically includes the following steps: S11. The upper-layer task orchestration module receives natural language instructions, performs semantic parsing and intent classification on the natural language instructions, orchestrates them into a composite task consisting of N operations, and assigns a unique identifier to the task and each operation. S12. Initialize the session configuration based on the task prediction complexity and write the session-level total budget parameters, including the maximum number of rounds and the thresholds for loop detection.

3. The embodied intelligence bounded round-loop execution method according to claim 2, characterized in that, Step S2 specifically includes the following steps: S21. The operation management module creates a round budget contract before the start of each round, setting the maximum number of tool call rounds and the maximum number of model requests for this round. S22. After the round execution engine loads the contract, it decrements the remaining steps of the budget by one at each tool call completion checkpoint and atomically checks whether it has been reduced to zero. If the zero value is reached, the loop immediately exits and the round result status is set to "budget exhausted". If the upper limit has not been reached, the loop continues.

4. The embodied intelligence bounded round-loop execution method according to claim 3, characterized in that, The round result status also includes diagnostic fields such as the number of rounds consumed, the name of the last tool called, and the timestamp.

5. The embodied intelligence bounded round-loop execution method according to claim 4, characterized in that, Step S3 specifically includes the following steps: S31. After each tool call is completed, the round execution engine sends the tool name, parameter hash value and result hash value of this call to the detector module. Each detector determines and generates a signal according to its independent triggering conditions. S32. After any detector generates a blocking signal, the engine immediately stops the round loop, sets the round result status to "loop blocking", and attaches the name of the triggering detector, the cumulative number of repetitions and the trigger timestamp in the return body; S33. When the detector outputs an alarm-level signal instead of a blocking-level signal, the engine transmits the signal to the contract capability module, which returns a decision of "continue" or "exit round" according to preset rules. S34. Before each call to the large language model, the engine checks whether the number of requests sent in this round has reached the contract limit; if the limit has been reached, the round loop is exited and the round status is marked as "budget exhausted".

6. The embodied intelligence bounded round-loop execution method according to claim 1, characterized in that, The four cyclic detectors are a fuse detector, a polling detector, an alternating detector, and a generalized detector.

7. The embodied intelligence bounded round-loop execution method according to claim 1, characterized in that, The circuit breaker's decision logic is as follows: ignoring the tool's type, a blocking signal is directly generated when the cumulative length of historical call records reaches a preset upper limit; the polling detector's decision logic is as follows: for pre-registered polling tools, the no-progress count is increased only when the hash values ​​of the results returned by multiple consecutive calls are exactly the same, thus distinguishing between reasonable polling and infinite loops; the alternation detector's decision logic is as follows: caching the tool names of the two most recent rounds, a signal is triggered when an ABAB alternation pattern is identified and the parameters and results of each round do not change substantially, and the consecutive rounds of this pattern reach a threshold; the generalization detector's decision logic is as follows: for non-polling tools, the number of consecutive calls with the same tool name and parameter hash value is counted.

8. The embodied intelligence bounded round-loop execution method according to claim 1, characterized in that, Step S4 specifically includes the following steps: S41. After each round, the system extracts the exit status and tool call signature from the round record and constructs a JSON payload: the tool name and parameter hash of each call in the tool call sequence are arranged into an array in chronological order, serialized by key sorting to obtain a JSON string, and then the deterministic digest value of the string is calculated as the round signature for this round. S42. The history queue is implemented as a double-ended queue with a fixed capacity. New signatures are appended to the tail. When the queue length exceeds the capacity limit, the oldest entry at the head is automatically removed to form a natural forget window. If no tool calls occur in this round and only natural language interaction is involved, the entire history queue is cleared before an empty signature is written. S43. Traverse from the latest item to the oldest item in the queue, and accumulate the number of items that are consecutively consistent with the latest signature. Stop traversing once the first inconsistent signature is encountered. S44. When the number of consecutive matches reaches the alarm threshold or blocking threshold, the strategy generates a loop signal and forwards it to the contract capability module. The contract capability module decides to reduce the frequency of tool calls, simplify operation parameters, or terminate the session early based on the signal level and the current session status.

9. An embodied intelligence bounded round-loop execution system, applied in the embodied intelligence bounded round-loop execution method as described in any one of claims 1-8, characterized in that, Includes the following modules: The session and turn control module is deployed locally during robot runtime. It is used to receive natural language commands and upper-level scheduling events, maintain session and turn records, and perform session-level budget limit control according to session configuration. The round budget contract module is deployed on the robot's local runtime and is used to define and verify round execution constraints. The constraints it manages include the maximum number of tool calls and the maximum number of model requests in a single round, both of which are limited to strictly positive integers. The round execution engine module is deployed locally during robot runtime to drive bounded round loops. At each checkpoint, it compares the budget consumption with the upper limit, and forces the robot to exit if the limit is exceeded. It also concurrently triggers loop checks at each tool call completion checkpoint. The round-based loop detection module is deployed locally during robot runtime and is used to implement loop pattern recognition at the tool call granularity. It has four built-in strategies: global circuit breaker, detection of no progress of known polling tools, alternating detection, and generalized repetitive detection, and generates two-level judgment signals: alarm and blocking. The cross-round duplication detection module is deployed locally during robot runtime. It is used to detect cross-round duplication patterns of the signature sequence called by the tool at the round granularity by comparing the sliding window history queue and the tail continuous digest. The Contract Capability Module is deployed locally during robot runtime. It is used to interface with cyclic detection signals and execute custom processing strategies. It supports pluggable configuration. The processing path includes issuing cyclic alarms or blocking signals through the event bus, which allows external callers to decide on subsequent degradation processing.

Images