Embodied intelligence oriented long-time operation execution control method and system

Abstract

The application discloses a long-time operation execution control method and system for embodied intelligence, adopts tree-shaped cancellation token construction time mirror image, immediately checks back and locks the parent state in the sub-token construction stage, makes the parent cancellation signal reliably reach any sub-coroutine with zero additional runtime overhead, designs a reverse rollback stack to pop out and execute reverse actions in the order of last in first out, each rollback callback is independently executed by a failure isolation invoker, so that the side effect cancellation order is automatically guaranteed by the data structure, the rollback process achieves the side effect clearance capability, and the resource locks under the normal path and the abnormal path can be correctly released; a bounded emptying design is adopted to wait with a time limit under the condition of shielding external cancellation interference; through recording and comparing the caller cancellation count before and after waiting, three situations of caller cascade cancellation, sub-task cooperation completion and grace period expiration are distinguished, so that the stopping path has a determined time upper limit.

Description

Technical Field

[0001] This invention relates to the fields of artificial intelligence and robotics, specifically to a long-term operation execution control method and system for embodied intelligence. Background Technology

[0002] In embodied intelligence applications, agents driven by large language models need to interact with the physical environment in real time through actuators such as robotic arms, chassis, and grippers to complete long-duration operations such as grasping and navigation. Unlike the instantaneous response of pure software agents, these physical operations, once initiated, can last from several seconds to several minutes. During this time, the system still needs to continuously receive data from sensors such as vision and force sensors and respond to new task instructions at any time.

[0003] The general principle in this field is that the intelligent agent performs task planning and decision-making at fixed time intervals, and the executor continuously runs physical operations according to the planning results. When it is necessary to cancel or preempt the current operation, the system cannot simply terminate the entire task. Instead, it needs to save the intermediate state of the operation execution, return the occupied hardware resources, and continue execution from the precise position where it was interrupted when it resumes, rather than going back to the task start point or subtask boundary to try again.

[0004] The inventors are aware of the following prior art related to the technical solution of this invention: One of the closest prior art known to the inventors is a Chinese invention patent application with publication number "CN121447643A," entitled "A Human-Machine Interaction System for an Embossed Intelligent Robotic Arm." This patent document discloses an interruptible execution and recovery scheme for long-sequence tasks of a robotic arm. It uses visual detection to determine the priority of temporary tasks and triggers the generation of interrupt instructions. During interruption, it captures snapshots of joint angles and end-effector poses. Upon recovery, it generates transitional subtasks using a large language model, verifies them, and then continues execution. However, the interruption propagation in this document relies on application-layer visual detection strategies and does not involve the automatic propagation of cancellation signals between runtime coroutines. Its recovery path uses local replanning as its core method, relies on a large language model to generate transitional subtasks online, and incurs significant computational overhead. It does not provide deterministic incremental continuation capabilities based on stage-level checkpoints and lacks a consistent undo mechanism for hardware side effects.

[0005] The patent specification describes in detail its interruption decision-making, state snapshot acquisition, local replanning and constraint verification mechanisms in paragraphs

[0017] to

[0022] ,

[0051] to

[0057] ,

[0023] to

[0027] and

[0125] to

[0169] .

[0006] The closest prior art known to the inventor is a Chinese invention patent application with publication number "CN122332218A", entitled "A Multi-Agent Cooperative Operating System Based on Microkernel and Intelligent Drivers". This patent document discloses a process-level anomaly isolation and breakpoint recovery scheme in a multi-agent cooperative scenario. After identifying cognitive drift and unauthorized access anomalies by calculating a dynamic inference offset index, it locks a memory sandbox, erases the memory data of the abnormal stage, and injects a recovery prompt vector, ultimately waking up the process to resume inference from the breakpoint. However, this document focuses on process scheduling and isolation at the operating system level, and the recovery mode is re-injection after erasing the erroneous context. It only targets two specific anomalies: cognitive drift and unauthorized access, and does not cover proactive interruptions triggered by external events or incremental resumption capabilities at stage-level checkpoints.

[0007] The patent specification describes in detail its anomaly isolation, context replacement and breakpoint wake-up mechanisms in paragraphs

[0005] to

[0012] and paragraphs

[0073] to

[0080] .

[0008] The third closest prior art known to the inventor is a Chinese invention patent application with publication number "CN122387634A," entitled "Multi-Agent Long-Cycle Task Orchestration System Based on Directed Acyclic Graph and State Machine." This patent document discloses a scheme for loop circuit breaking and breakpoint resumption for long-cycle task orchestration of large language models. After determining the blocking timing through Snell envelope value, the execution stack is sliced ​​and cleaned to generate summary checkpoints. Finally, static rule nodes are inserted to load checkpoints and complete the resumption. However, this document mainly targets the specific anomaly of implicit loops in large language models. The resumption method replaces uncertain reasoning paths with deterministic rule nodes, which is a fallback strategy rather than a context-aware, precise recovery, and does not involve active interruption scenarios.

[0009] The patent specification describes in detail its envelope blocking decision, runtime stack slicing cleaning, and breakpoint resume mechanism in paragraphs

[0010] to

[0013] ,

[0080] to

[0092] , and

[0106] to

[0114] .

[0010] Based on the analysis of the above background technologies, the following technical challenges exist in the execution of embodied intelligence long-term operations: The cancellation mechanism of existing collaborative concurrency models is essentially flat. After the parent coroutine is cancelled, the dynamically constructed child coroutine cannot perceive the cancellation event because it has not yet been registered to the parent scope, forming a time window gap of parent cancellation - late construction of child - child unawareness.

[0011] Existing breakpoint resumption solutions generally adopt coarse-grained checkpoint strategies, such as data batch replay, runtime stack slicing takeover, or context erasure and re-injection, which lack stage-level fine-grained checkpoint mechanisms. Therefore, when recovering from an interruption, it is impossible to accurately resume from the intermediate state point within the operation.

[0012] On the other hand, embodied intelligent operations can produce irreversible hardware side effects and occupy exclusive resources. The interrupt handling logic of existing technical solutions revolves around the saving and restoration of computing state, and lacks built-in conventions for hardware instruction cancellation and resource return. In summary, there is currently a lack of a method that can simultaneously achieve the following effects in scenarios where embodied intelligent long-sequential operation tasks face active interruption triggered by high-priority external events: hierarchical reliable propagation of cancellation signals in the scope of coroutines with parent-child nesting relationships, incremental state continuation based on stage-level fine-grained checkpoints, and atomic reversal of hardware side effects and exclusive resources. Summary of the Invention

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

[0014] This invention provides a long-term operation execution control method for embodied intelligence, comprising the following steps: S1. Receive natural language instructions, arrange them into a composite task consisting of N operations, and assign a unique identifier to the task and each operation. S2. Register the operation identifier and activity status, read the resource set declared in the operation specification, and prepare to cancel the token from the runtime root-derived child. S3. Construct a tree-shaped child cancellation token and mirror the parent token state during construction; S4, the forward logic that drives the physical execution engine to start executing operations; S5. After cancellation is detected, the operation enters the unified rollback path and executes the last-in-first-out and failure isolation combination of the reverse rollback stack. S6. If cancellation or other exceptions are caught, the corresponding hook is invoked, the termination result is persisted, the handle and activity state are cleaned up, and the child cancellation token is unbound from the token tree. S7. Use a bounded emptying method to wait for canceled subtasks to stop cooperating, to prevent non-cooperating operations from blocking the stop path indefinitely. S8. Upon receiving the recovery command, the task orchestration module loads the most recently successful checkpoint, derives a new uncancelled child token from the runtime root, and continues execution from the corresponding stage entry point.

[0015] Preferably, step S3 specifically includes the following steps: S31. Read the current state of the parent token and determine whether the parent token has been cancelled; S32. Perform branch processing based on the current state of the parent token.

[0016] Preferably, step S32 specifically involves: if the parent token has been cancelled, the child token cancellation method is immediately called during the child token construction phase to mark the child token as cancelled, so that the subsequent cancellation check is terminated directly; if the parent token has not been cancelled, the child token is added to the token tree, and the parent token recursively propagates the structured cancellation reason to each live child token in the cancellation method in a depth-first manner.

[0017] Preferably, step S4 specifically includes the following steps: S41. Request leases for various resources in accordance with the operating procedures and record the order of acquisition; S42. Then, the forward logic is executed according to the explicit phase division. The entry point of each phase is set with a nested waiting point for the sub-cancellation token status polling. S43. For each stage, hardware side effects are generated and the corresponding reverse action is registered in the forward rollback stack. S44. After each stage is completed, the execution result of that stage is persisted as a session record entry using the session storage append method. S45. When the waiting point detects a cancellation signal, proceed to step S5.

[0018] Preferably, the session record entry includes fields such as operation identifier, stage number, result summary, and timestamp.

[0019] Preferably, step S5 specifically includes the following steps: S51. The operation checks for a cancellation token at the waiting point. If cancellation is detected, the cancellation hook is invoked and the forward action is stopped. S52. Pop items one by one in the last-in-first-out order and execute the reverse action in the rollback stack so that the side effects generated later are canceled first. S53. Each rollback callback is executed independently by the failure isolation caller. If a single callback fails, only the exception is recorded, without blocking the rollback of other callbacks. S54. In the final branch, release all leases in reverse order of resource lock acquisition to ensure that no resource locks are left behind in either the normal or abnormal path.

[0020] Preferably, step S7 specifically includes the following steps: S71. Record the caller's cancellation count before the wait begins; S72. Send a cancellation signal to the subtask and wait with a time limit while shielding it from external cancellation interference; S73. If the subtask ends within the grace period, return as either completed collaboratively or completed abnormally; if it does not end before the grace period expires, stop waiting and install the subsequent exception watch callback for the subtask. S74. Compare the caller's cancellation count before and after the wait; if the count increases, propagate the cascading cancellation of the caller itself; otherwise, return the empty result of the subtask.

[0021] On the other hand, the present invention provides a long-term operation execution control system for embodied intelligence, applied to the aforementioned long-term operation execution control method for embodied intelligence, characterized in that it includes the following modules: The session and round control module is used to receive natural language commands and upper-level scheduling events, and to maintain session and round bookkeeping. The operation management module is used to encapsulate the complete lifecycle of an operation, maintain memory state storage, and map cancellation signals to session record persistence, rollback, and resource release.

[0022] The resource lock management module is used to implement deterministic acquisition of ordered keys, unordered release, and automatic rollback in case of mid-process exceptions; it returns the lease handle, and the lease release operation is idempotent.

[0023] The tree-structured cancellation token module is used to implement the parent / child / unbinding protocol. It immediately mirrors the parent state during construction and propagates the structured reason in depth first during cancellation.

[0024] The bounded emptying module is used to distinguish between three types of cancellation sources: caller cascading, collaborative completion, and grace period expiration. It works in conjunction with the default grace window to ensure that the operation management module is not blocked by non-collaborative operation entities.

[0025] The Embodied Action Primitives module is used to organize each operation within a three-piece set of stages, rollback callbacks, and checkpoints, covering embodied action primitives such as navigation, grabbing, placing, and voice.

[0026] Compared with the prior art, the beneficial effects of the present invention are mainly reflected in the following aspects: 1. Reliable propagation of cancellation signals and precise session-level recovery, corresponding to steps S3 and S4. Addressing the time window gaps in the cooperative cancellation model—parent cancellation—child late construction—child unawareness—and the difficulty in resuming from intermediate states after interruption, a tree-structured cancellation token construction mirroring is adopted. During the child token construction phase, the parent state is immediately checked and locked, ensuring the parent cancellation signal reliably reaches any child coroutine with zero additional runtime overhead. Therefore, cancellation detection changes from a decentralized obligation of the developer to a runtime mandatory requirement, completely eliminating time window gaps; after long-term operation interruptions, resumption can begin from the boundary of the most recently successful round in the session record, reducing the average recovery time compared to a full graph rerun solution.

[0027] 2. Automatic completion of reverse rollback for side effects and resource locks, corresponding to step S5. Addressing the issue that cancellation only involves exception propagation and lacks built-in conventions for reversing issued hardware instructions or returning acquired exclusive resources at this stage, this invention designs a reverse rollback stack that pops items sequentially in a last-in-first-out (LIFO) order and executes the reverse action. Each rollback callback is executed independently by the failure isolation caller. Effectively, the order of side effect reversal is automatically guaranteed by the data structure, the rollback process achieves side effect cleanup, and resource locks are correctly released in both normal and abnormal paths.

[0028] 3. Hard time limit and transaction-level guarantee for the stop path, corresponding to step S7. To address the issue of no hard time limit for the stop path and the possibility of the operation management module being infinitely blocked by uncooperative sub-operations, a bounded queuing design is adopted. Under the condition of shielding external cancellation interference, a default 50-millisecond time limit is implemented, and the three types of cases are distinguished by comparing the cancellation count of the caller. In effect, the stop path obtains a definite time limit, and the end-to-end latency of the robotic arm's hard cancellation signal is reduced to the order of 50 milliseconds. The integrated mechanism provides database transaction-level guarantees for complete execution, complete rollback, or checkpoint recovery for long-duration operations. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the overall architecture of the embodied intelligence long-term operation execution stack provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the tree-shaped cancellation token creation, propagation, and unbinding process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the operation execution and rollback process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a bounded evacuation process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a resource lock management process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the recovery process provided in an embodiment of the present invention. Detailed Implementation

[0030] 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

[0031] This embodiment provides a long-term operation execution control method for embodied intelligence, including the following steps: Step S1: The upper-level 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 each operation.

[0032] Step S2: The operation management module registers the operation identifier and activity status, reads the resource set declared in the operation specification, and prepares to derive the cancellation token from the runtime root.

[0033] Step S3 (Key Innovation Step): The operation management module constructs a tree-structured sub-cancellation token and mirrors the parent token's state during construction. Specifically: First, read the current state of the parent cancellation token to determine whether the parent token has been cancelled.

[0034] Secondly, if the parent token has been cancelled, the child token cancellation method is called immediately during the child token construction phase to mark the child token as cancelled, so that the subsequent cancellation check will terminate the operation directly.

[0035] Finally, if the parent token is not cancelled, the child token is added to the token tree (maintaining a backreference through the parent token). Subsequently, the parent token recursively propagates the structured cancellation reason to each live child token in a depth-first manner within the cancellation method.

[0036] This construction-time mirroring moves the parent state check forward to the child token construction time, eliminating the time window gap of "parent canceled - child constructed late - child unaware" without adding periodic polling overhead.

[0037] Step S4: After the resource lock manager acquires the lease of the resources required for the operation, the operation is executed in explicit phases. Before any hardware side effects occur, a reverse action is registered on the rollback stack. After each phase is completed, the execution result of that phase is persisted as a session record entry through the session storage append method.

[0038] Step S5 (Key Innovation Step): Upon detection of cancellation, the operation enters a unified rollback path and executes a reverse rollback stack combining last-in-first-out (LIFO) and failure isolation. Specifically: First, the operation checks for a cancellation token at the waiting point. Once cancellation is detected, the cancellation hook is invoked and the forward action is stopped.

[0039] Secondly, pop items one by one in the last-in-first-out (LIFO) order and execute the reverse action in the rollback stack so that the side effects generated later are undone first.

[0040] Furthermore, each rollback callback is executed independently by the failure isolation caller; the failure of a single callback only records the exception and does not prevent other callbacks from continuing to roll back.

[0041] Finally, in the final branch, all leases are released in reverse order of resource lock acquisition, ensuring that no resource locks are left behind in either the normal or abnormal path.

[0042] This combination ensures both the correctness of the side effect reversal order and that the rollback process is not blocked by a single point of failure.

[0043] Step S6: The operation management module captures cancellation or other exceptions, calls the corresponding hook, persists the termination result, cleans up the handle and activity state, and unbinds the child cancellation token from the token tree.

[0044] Step S7 (Key Innovation Step): The operation management module uses a bounded queuing method to wait for canceled subtasks to stop collaboratively, preventing non-collaborating operations from indefinitely blocking the stop path. Specifically: First, record the cancellation count of the caller before the wait begins.

[0045] Secondly, a cancellation signal is sent to the subtask, and a timed wait is performed while shielding against external cancellation interference; the grace window is set to 50 ms by default and can be configured according to specific operation characteristics.

[0046] Secondly, if the subtask ends within the grace period, return as either completed collaboratively or completed abnormally; if it does not end by the end of the grace period, stop waiting and install subsequent exception watch callbacks for the subtask.

[0047] Finally, compare the caller's cancellation count before and after the wait; if the count increases, propagate the cascading cancellation of the caller itself; otherwise, return the empty result of the subtask.

[0048] This distinguishes between three scenarios: caller-side cascading cancellation, subtask collaborative completion, and expiration of the grace period, thus giving the stopping path a definite time limit.

[0049] Step S8: Upon receiving the recovery instruction, the task orchestration module loads the most recently successful checkpoint, derives a new uncancelled child token from the runtime root, and continues execution from the corresponding stage entry point. Example 2

[0050] This embodiment provides a long-term operation execution control system for embodied intelligence. The system consists of six core modules, and its overall architecture is as follows: Figure 1 As shown: Module 1: Session and Turn Control Module, deployed locally during robot runtime, is used to receive natural language commands and upper-level scheduling events, and maintain session and turn records. Module 2: Operation Management Module, deployed locally during robot runtime, is used to encapsulate the complete lifecycle of operations, maintain memory state storage, and map cancellation signals to persistent session records, rollback, and resource release.

[0051] Module 3: Resource Lock Management Module, deployed locally during robot runtime, is used to achieve deterministic acquisition of ordered keys, unordered release, and automatic rollback in case of mid-process exceptions; it returns the lease handle, and the lease release operation is idempotent.

[0052] Module 4: Tree-structured cancellation token module, deployed locally during robot runtime, is used to implement the parent / child / unbinding protocol. The parent state is mirrored immediately during construction, and cancellation is performed by depth-first propagation of structured reasons.

[0053] Module 5: Bounded Cancellation Module, deployed locally during robot runtime, is used to distinguish between three types of cancellation sources: caller cascading, collaborative completion, and grace period expiration. It works with the default grace window to ensure that the operation management module is not blocked by non-collaborating operation entities.

[0054] Module 6: Embodied Action Primitives Module, deployed during robot runtime, is used to organize each operation within a three-piece set of stages, rollback callbacks, and checkpoints, covering embodied action primitives such as navigation, grasping, placement, and voice. Example 3

[0055] In this embodiment, the implementation process of the present invention is described in detail using the example of a home service robot performing a long-sequence operation of "grabbing a red cup and placing it on the dining table" in a kitchen environment. Figure 1 As shown, this embodiment provides an intelligent long-term operation interruptible recovery and incremental continuation system. Natural language commands are decomposed into a composite task of six operations after being arranged by the upper layer. During the execution process, there may be a need for active interruption due to external events such as the user issuing a higher priority stop command or the sensor detecting an obstacle intrusion.

[0056] Step S1: The upper-layer task orchestration module receives the natural language instructions input by the user, calls the large language model interface to perform semantic parsing and intent recognition, and orchestrates them into a composite task consisting of N operations according to the preset operation template library. In this embodiment, N is 6. After assigning a globally unique identifier to the task and each operation and forming a directed acyclic topology, it is submitted to the operation management module.

[0057] Step S2: After receiving the task description body from Step S1, the operation management module registers each operation identifier and initial activity status, reads the resource set declared in the operation specification and pre-checks availability; obtains the root cancellation token handle from the runtime environment as the parent token source for subsequent construction of child tokens; and creates a blank rollback stack instance and session record buffer for each operation.

[0058] Step S3 (Key Innovation Step): Before the operation is formally executed, the operation management module first constructs a unique tree-structured child cancellation token for it, and executes the core semantics of mirroring the parent token's state during the construction process. Please refer to [link / reference]. Figure 2The specific implementation process of creating and propagating tree-structured cancellation tokens is as follows: S3-1: Read the parent token status. The operation management module calls the status query interface of the parent cancellation token to obtain its current cancellation flag value. This atomic read operation returns a boolean result: true indicates that the parent token has been cancelled, and false indicates that it has not been cancelled.

[0059] S3-2: Conditional Branching – Case where the parent token has been cancelled. If the parent token has been cancelled, the child token cancellation method is immediately called within the child token constructor, setting the cancellation event within the child token, synchronously triggering registered callback notifications, and recursively propagating the cancellation signal along the subtree. Subsequent queries to this child token will always return true. Even if the parent token's state changes or the child token is reconnected to another subtree, the child token's cancellation state is frozen and will not change.

[0060] S3-3: Conditional Branching – Case where the parent token is not cancelled. If the parent token is not cancelled, the new child token is attached to the list of child nodes of the parent token to establish a parent-child hierarchical relationship; thereafter, if the parent token is cancelled, a structured cancellation reason object carrying the three elements of source identifier, timestamp and reason classification will be recursively propagated to each live child token in a depth-first traversal manner.

[0061] The core of the above mechanism lies in advancing the propagation timing to the construction timing. In traditional cooperative concurrency models, after a parent coroutine is canceled, the cancellation event is only broadcast to registered child coroutines. Subsequent dynamically constructed child coroutines miss the broadcast opportunity and cannot perceive that they should be canceled, forming a time window gap of parent cancellation—late child construction—child unawareness. This invention eliminates the aforementioned time window gap by forcibly inserting a lookup of the parent token's state into the code path of child token construction. No matter how late the child token is constructed after the parent cancellation, a parent state lookup will inevitably be performed as long as the constructor is executed, thus eliminating the aforementioned time window gap with zero additional runtime overhead.

[0062] The initial design used a global broadcast protocol to propagate the cancellation signal. However, technical evaluation revealed that it was impossible to finely control the cancellation scope; any coroutine receiving the broadcast would be cancelled, which contradicted the semantics that the cancellation scope should converge along the session tree. The drawback of the pure callback chain approach was that if the child token was constructed after the parent was cancelled, it would miss the callback registration opportunity and remain unaware of the cancellation event. After the above two trials and errors, it was determined that a parent state backtracking should be inserted into the child token constructor, moving the propagation timing forward to the construction timing, thereby covering the blind spot of late-constructed child tokens.

[0063] Step S4: The operation management module drives the physical execution engine to begin executing the forward logic of the operation. For example... Figure 5As shown, the resource lock manager first requests leases for various resources according to the operation protocol and records the acquisition order. Then, it executes forward logic according to explicit phases, with each phase's entry point containing a nested waiting point for the sub-cancellation token status polling. Each phase generates hardware side effects and registers the corresponding reverse action on the forward rollback stack. After each phase is successfully completed, the execution result is serialized into a session record entry containing fields such as operation identifier, phase number, result summary, and timestamp, and appended to the storage medium. Adjacent records are linked together to form a singly linked list structure, with the tail pointer of the list indicating the round boundary. When a cancellation signal is detected at the waiting point, the process jumps to step S5. After all phases are completed, the lease is released, the sub-token is unbound, and the lifecycle ends.

[0064] Step S5 (Key Innovation Step): When a cancellation signal is detected at the waiting point, the operation enters a unified rollback path. For example... Figure 3 As shown, the phase checkpoint registration and rollback path in the operation execution phase implement a hardware side effect reversal mechanism that combines last-in-first-out (LIFO) and failure isolation. The specific implementation process is as follows: S5-1: Cancellation of response and abortion of forward action. Upon detecting that the cancellation flag is true, the cancellation hook function is immediately called to stop scheduling subsequent forward stages, record the stage number and timestamp of the cancellation, update the operation status to cancelled - pending rollback, and allow currently incomplete stage actions to stop naturally after reaching the atomic operation boundary.

[0065] S5-2: Reverse actions are executed by popping items from the stack in a Last-In-First-Out (LIFO) order. The operation management module pops and executes the reverse actions from the rollback stack item by item in LIFO order. Taking the gripping action as an example, if cancellation occurs during the application of closing torque, the popping and cancellation order is as follows: open the gripper to cancel the closure, retreat to a safe distance to cancel the approach, and reset the gripper opening to cancel the opening. This order is exactly the reverse of the causal relationship in the physical world, i.e., the first to close opens first, and the first to approach retreats last, avoiding residual side effects caused by the reversal of causal relationships during cancellation. Developers do not need to manually specify the cancellation order; the data structure automatically ensures correctness.

[0066] S5-3: Failure Isolation Execution. Each reverse action is independently wrapped by a failure isolation caller, which internally employs an item-by-item exception handling mechanism. When an exception occurs during the execution of a callback, the exception information is appended to the error list but does not prevent other callbacks from continuing to roll back, ensuring that even if a certain undo step fails, other side effects that have already occurred can still be undone.

[0067] S5-4: Resource release in the final branch. After all reverse actions have popped the stack, the final branch is entered. All leases are released one by one in reverse order of acquisition order recorded in the resource lock tracking table, ensuring that no resource locks are left in either the normal or abnormal path.

[0068] Last-In-First-Out (LIFO) addresses the issue of correct reversal order—hardware side effects occur according to causal sequence, and reversal must proceed in reverse causal order to ensure the consistency of the physical world's state. Failure isolation addresses the issue of reversal robustness—hardware device communication is unstable, and a single reversal failure should not become a bottleneck preventing the execution of subsequent reversals. These two approaches complement each other: correct order is automatically guaranteed by the data structure, single-point failures are absorbed by the isolated caller, and the overall rollback process has deterministic termination conditions and a certain degree of side effect cleanup capability.

[0069] Early versions involved developers manually writing cleanup code before each waiting point, and reviews revealed two common problems: the undo order varied from person to person, and single-point failures blocked subsequent cleanup. Subsequently, attempts were made to execute undo in reverse order of registration, but tests revealed that the causal timing of hardware side effects was inconsistent with the registration timing, resulting in a reverse-order residue where undoing occurred before side effects occurred. Ultimately, a combination of Last-In-First-Out (LIFO) and failure isolation semantics was selected, with the order automatically guaranteed by the data structure and single-point failures absorbed by the isolation caller, the two complementing each other.

[0070] Step S6: After the rollback path is completed or other non-cancellation exceptions are detected in Step S4, the operation management module performs unified cleanup processing. Based on the exception type, the corresponding hook is scheduled: for cancellation exceptions, the cancellation hook is called to record the reason; for timeout exceptions, the timeout hook is called to determine retry; and for fault exceptions, the fault hook is called to report an alarm. The termination result is then serialized into a special session record entry and written to storage. This termination result includes the termination status, reason details, and the sequence number of the last valid stage completed. Afterwards, the operating system-level handle is released, the activity state is removed from the tracking data structure, and the child cancellation token is unbound from the token tree.

[0071] Step S7 (Key Innovation Step): The operation management module needs to perform bounded emptying waits on all cancelled subtasks dispatched by the operation to prevent uncooperative subtasks from indefinitely blocking the stop path. Please refer to [link to relevant documentation]. Figure 4 The complete semantic implementation process of bounded empty is as follows: S7-1: Caller Cancellation Count Snapshot. Before starting, read and record the caller's current cancellation count value (monotonically increasing integer), as a benchmark for subsequent sub-tasks to complete on their own and for the caller itself to be cascaded canceled.

[0072] S7-2: Timed Wait with Shielding Protection. After sending a cancellation signal to the subtask, it enters a timed wait loop, temporarily shielding the transmission of cancellation signals from the superior to avoid interfering with the emptying judgment. The time limit uses a default empirical grace window of 50 milliseconds, which is sufficient to distinguish between two situations: rapid collaborative completion and timeout indicating device deadlock or computational deadlock.

[0073] S7-3: Collaboration Completed and Returned. Subtasks that have completed cleanup within the window, regardless of success or failure, are categorized as either Collaboration Completed or Collaboration Abnormally Completed.

[0074] S7-4: Grace period expiration handling. Stop waiting after timeout, trigger log recording when the subtask finally ends for post-event diagnosis; do not forcibly kill the underlying thread or process, but let the runtime environment reclaim it naturally.

[0075] S7-5: Cancellation Count Comparison and Case Classification. After the wait is complete, read the caller's cancellation count again and compare it with the baseline value: if the count increases, it indicates that the caller itself has received a cascading cancellation, and immediately throws an exception that propagates upwards; otherwise, return within the window and classify it as a collaboration completed or timeout expired.

[0076] The above process constitutes the complete execution logic of canceling and emptying the function: the entry snapshot implements the caller snapshot, the timed waiting shield implements shielding protection, the return within the window corresponds to the completion of collaboration or abnormal completion, the timeout background callback corresponds to the timeout observation, and the exit count comparison is used to distinguish between the caller cascading and the final return.

[0077] A fixed window of 500 milliseconds causes noticeable lag in scenarios where the robotic arm cancels. Removing the window and proceeding directly leads to resource lock contention between unfinished sub-coroutines and the new stage, resulting in a degradation in collaboration capabilities. Qualitative tests in the 100 to 200 millisecond range show that the collaboration completion rate has not improved significantly, and the uncontrollable window has actually been extended. Finally, a default grace period of 50 milliseconds was adopted, and a caller cancellation count comparison was introduced to cover the missed cases of cascading cancellations.

[0078] Step S8: Upon receiving the recovery command, the orchestration module calls the replay method of the agent's session state. For example... Figure 6 As shown, the complete session record linked list of the target operation is loaded into the session storage. The most recently successfully completed stage record is located by traversing the tail pointer as the round boundary. All intermediate state parameters when the stage is completed are extracted from it and injected into the new operation execution context. The child cancellation token is re-derived from the currently valid root cancellation token and the construction mirror initialization process of step S3 is repeated to resume execution from the next stage of the round boundary.

[0079] The core inventive points and protective points of this invention are as follows: (1) The "construction-time mirroring" algorithm for tree-structured cancellation tokens corresponds to step S3. This algorithm immediately checks the parent token state during the child token construction phase. If the parent token has been cancelled, it marks itself as cancelled during construction, causing the subsequent cancellation check to terminate directly. By moving the "parent state check" from the cancellation time to the construction time, the time window gap of parent cancellation - child late construction - child unaware is eliminated with zero additional runtime overhead.

[0080] (2) The combination of the last-in-first-out (LIFO) order of the reverse rollback stack and failure isolation corresponds to step S5. When cancellation is detected, the rollback stack is popped item by item in LIFO order and the reverse action is executed, so that the side effects generated later are undone first; each rollback callback is executed independently by the failure isolation caller, and the failure of a single callback is only recorded as an exception, without blocking the rollback of other callbacks. This combination scheme ensures both the correct order of side effect cancellation and the maximum possible completion of the rollback process.

[0081] (3) Bounded emptying method, corresponding to step S7. After sending a cancellation signal to the subtask, instead of waiting indefinitely for its collaboration to stop, it performs a time-limited wait under the condition of shielding external cancellation interference; by recording and comparing the caller cancellation count before and after the wait, it distinguishes between three types of situations: caller cascading cancellation, subtask collaboration completion, and grace period expiration, so that the stopping path has a definite time limit.

[0082] To verify the beneficial effects of this invention, the inventors conducted experimental tests. The test environment is shown in the table below: Table 1 Test Environment

[0083] Experiment 1: Interrupt Propagation Delay vs. Number of Processors To simulate a common scenario in embodied intelligent agents where a single operation triggers multi-processor collaboration, N processors are registered in the frame pipeline. After an interrupt is triggered, the end-to-end interrupt propagation time is measured. The number of processors N is taken in five orders of magnitude: 1, 5, 10, 20, and 50. Each order of magnitude is measured independently 1000 times and the average is taken.

[0084] Experiment 2: Mirroring during construction vs. mirroring during cancellation The end-to-end time consumption of the two cancellation propagation strategies was compared. The proposed solution immediately checks the parent state and freezes the cancellation bit during child token construction; the contrasting solution simulates an industry-standard token tree cancellation model, where the parent state is not checked during child token construction, and the child state is only set via a callback chain when the parent cancellation event is triggered. The total time consumption for concurrently constructing 1000 child tokens under a parent-child token nesting depth of 3 levels was measured.

[0085] Experiment 3: Collaboration Completion Rate under Bounded Empty Window Simulate typical embodied operations, set a grace window of 50 milliseconds, and statistically analyze the collaborative completion rate of subtasks under different grace windows.

[0086] The quantitative data comparison is shown in the table below.

[0087] Table 2: Interruption Propagation Delay Table

[0088] Regarding interrupt propagation latency, the time consumed by a single interrupt in a single-processor scenario is 0.38 microseconds, with an increment of approximately 0.26 to 0.28 microseconds for each additional processor; in a scenario with 50 processors, the total time is 13.37 microseconds, showing an approximately linear increase without a centralized lock contention bottleneck, and the complexity remains at a linear level of O(n). The table below shows the comparison results between this invention and existing solutions.

[0089] Table 3. Comparison Results of the Invention and Existing Solutions

[0090] Note 1: Existing real-time operating systems measure the physical time from a hardware interrupt to the execution of an ISR, which is different from the pure software layer interrupt propagation time measured in this invention, but the units are the same. Compared with existing solutions in the following dimensions: Regarding interrupt propagation latency, the literature value for hard interrupt response in existing real-time operating systems is approximately 225 microseconds, while the measured value of this invention is 13.37 microseconds, a significant improvement. Regarding propagation complexity, existing solutions typically involve centralized lock contention; this invention employs a lock-free failure isolation model, resulting in a superior structure. Regarding child tokens' perception of parent cancellation, existing industry-standard token schemes cannot detect parent cancellation when child tokens are constructed late, leading to time window gaps. This invention achieves zero-gap semantic guarantees through construction-time mirroring. Regarding reverse rollback order, existing solutions mostly use manual or distributed cleanup modes; this invention automatically ensures order consistency through last-in-first-out (LIFO). Regarding rollback failure propagation, existing solutions often encounter situations where a single failure blocks all cleanup; this invention achieves side-effect removal capabilities through failure isolation. Regarding the upper limit of stop path time, most existing solutions lack a hard upper limit; this invention provides deterministic constraints through a 50-millisecond grace window. Regarding the interrupt recovery starting point, existing solutions mostly involve rerunning the entire graph or recovering at the subtask entry level; this invention supports precise continuation at the stage entry point.

[0091] Table 4. Tree-structured Cancellation Tokens: Mirror Comparison Results of Construction Time Mirror vs. Cancellation Timing

[0092] Note: The specific milliseconds in Table 4 vary depending on the hardware runtime, and the latest data will be output during the test runtime; the core difference of this invention lies in the semantic level.

[0093] In comparing the mirroring during construction and the mirroring during cancellation, in a test scenario with a nesting depth of 3 levels and 1000 concurrent constructions of child tokens, the proposed solution requires only one check with constant overhead, while the callback chain propagation time of the control solution increases with nesting depth. A more crucial difference lies in the semantic level: when the parent token is cancelled but the child token is constructed late, the child token of the proposed solution immediately enters the cancelled state, while the child token of the control solution is unaware of this and continues to execute according to the non-cancelled logic.

[0094] The above tests were conducted under standard conditions, with at least 1000 iterations and the average value taken. The results were stable and reproducible. Compared with existing solutions, this invention improves long-running operations in four dimensions—interruption reliability, recovery accuracy, stop path controllability, and side effect undoing completeness—by integrating cancellation, stage saving, rollback, resource lifecycle, and bounded stopping into the same atomic semantics.

[0095] 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 long-term operation execution control method for embodied intelligence, characterized in that, Includes the following steps: S1. Receive natural language instructions, arrange them into a composite task consisting of N operations, and assign a unique identifier to the task and each operation. S2. Register the operation identifier and activity status, read the resource set declared in the operation specification, and prepare to cancel the token from the runtime root-derived child. S3. Construct a tree-shaped child cancellation token and mirror the parent token state during construction; S4, the forward logic that drives the physical execution engine to start executing operations; S5. After cancellation is detected, the operation enters the unified rollback path and executes the last-in-first-out and failure isolation combination of the reverse rollback stack. S6. If cancellation or other exceptions are caught, the corresponding hook is invoked, the termination result is persisted, the handle and activity state are cleaned up, and the child cancellation token is unbound from the token tree. S7. Use a bounded emptying method to wait for canceled subtasks to stop cooperating, to prevent non-cooperating operations from blocking the stop path indefinitely. S8. Upon receiving the recovery command, the task orchestration module loads the most recently successful checkpoint, derives a new uncancelled child token from the runtime root, and continues execution from the corresponding stage entry point.

2. The long-term operation execution control method for embodied intelligence according to claim 1, characterized in that, Step S3 specifically includes the following steps: S31. Read the current state of the parent token and determine whether the parent token has been cancelled; S32. Perform branch processing based on the current state of the parent token.

3. The long-term operation execution control method for embodied intelligence according to claim 2, characterized in that, Step S32 specifically involves: if the parent token has been cancelled, the child token cancellation method is immediately called during the child token construction phase to mark the child token as cancelled, causing the subsequent cancellation check to terminate the operation directly; if the parent token has not been cancelled, the child token is added to the token tree, and the parent token recursively propagates the structured cancellation reason to each live child token in the cancellation method in a depth-first manner.

4. The long-term operation execution control method for embodied intelligence according to claim 1, characterized in that, Step S4 specifically includes the following steps: S41. Request leases for various resources in accordance with the operating procedures and record the order of acquisition; S42. Then, the forward logic is executed according to the explicit phase division. The entry point of each phase is set with a nested waiting point for the sub-cancellation token status polling. S43. For each stage, hardware side effects are generated and the corresponding reverse action is registered in the forward rollback stack. S44. After each stage is completed, the execution result of that stage is persisted as a session record entry using the session storage append method. S45. When the waiting point detects a cancellation signal, proceed to step S5.

5. A long-term operation execution control method for embodied intelligence according to claim 4, characterized in that, The session record entries include fields such as operation identifier, stage number, result summary, and timestamp.

6. The long-term operation execution control method for embodied intelligence according to claim 1, characterized in that, Step S5 specifically includes the following steps: S51. The operation checks for a cancellation token at the waiting point. If cancellation is detected, the cancellation hook is invoked and the forward action is stopped. S52. Pop items one by one in the last-in-first-out order and execute the reverse action in the rollback stack so that the side effects generated later are canceled first. S53. Each rollback callback is executed independently by the failure isolation caller. If a single callback fails, only the exception is recorded, without blocking the rollback of other callbacks. S54. In the final branch, release all leases in reverse order of resource lock acquisition to ensure that no resource locks are left behind in either the normal or abnormal path.

7. The long-term operation execution control method for embodied intelligence according to claim 1, characterized in that, Step S7 specifically includes the following steps: S71. Record the caller's cancellation count before the wait begins; S72. Send a cancellation signal to the subtask and wait with a time limit while shielding it from external cancellation interference; S73. If the subtask ends within the grace period, return as either completed collaboratively or completed abnormally; if it does not end before the grace period expires, stop waiting and install the subsequent exception watch callback for the subtask. S74. Compare the caller's cancellation count before and after the wait; if the count increases, propagate the cascading cancellation of the caller itself; otherwise, return the empty result of the subtask.

8. A long-term operation execution control system for embodied intelligence, applied in the long-term operation execution control method for embodied intelligence as described in any one of claims 1-7, characterized in that, Includes the following modules: The session and round control module is used to receive natural language commands and upper-level scheduling events, and to maintain session and round bookkeeping. The operation management module is used to encapsulate the complete lifecycle of an operation, maintain memory state storage, and map cancellation signals to session record persistence, rollback, and resource release. The resource lock management module is used to implement deterministic acquisition of ordered keys, reversal release, and automatic rollback in case of mid-process exceptions; Returns the lease handle; the lease release operation is idempotent. The tree-structured cancellation token module is used to implement the parent / child / unbinding protocol. During construction, the parent state is immediately mirrored, and during cancellation, the structured reasons are propagated in depth first. The bounded emptying module is used to distinguish between three types of cancellation sources: caller cascading, collaborative completion, and grace period expiration. It works in conjunction with the default grace window to ensure that the operation management module is not blocked by non-collaborative operation bodies. The Embodied Action Primitives module is used to organize each operation within a three-piece set of stages, rollback callbacks, and checkpoints, covering embodied action primitives such as navigation, grabbing, placing, and voice.

Images