Intelligent agent multi-task planning method and device, intelligent agent and storage medium
By parsing task statements into task instruction sequences and generating behavior trees, combined with a skill library and scheduler, the deterministic execution problem of multi-objective tasks is solved, enabling flexible multi-task planning and deterministic execution, reducing modeling costs and improving the system's adaptability and reliability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-14
AI Technical Summary
In existing technologies, the sequential control of a single task is difficult to meet the comprehensive task requirements of multiple objectives, multiple constraints, and long time domains. The uncertainty of end-to-end large language model (LLM) execution and the rigidity of pure behavior tree (BT) lead to the problem of task combination explosion and high maintenance costs when the scenario changes.
By inputting task statements into a large language model for parsing and generating task instruction sequences, a skill library is loaded using a subscription mechanism and a behavior tree is created. Deterministic execution and concurrent processing of tasks are achieved by combining mutex locks and a scheduler, and the behavior tree is dynamically reconstructed to adapt to environmental changes.
It achieves deterministic and interpretable execution of multi-task planning, reduces modeling costs, improves the flexibility and reliability of task execution, supports rapid expansion of new tasks, and ensures the stability and reproducibility of the system in complex environments.
Smart Images

Figure CN121858236A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of intelligent agent control technology, specifically to an intelligent agent multi-task planning method, apparatus, intelligent agent, and storage medium. Background Technology
[0002] With the widespread adoption of unmanned systems, service robots, and industrial automation, sequential control of single tasks is no longer sufficient to meet the demands of comprehensive tasks involving multiple objectives, multiple constraints, and long time domains. Behavior Trees (BTs) are widely used in the task execution layer due to their modularity, reusability, and ease of verification; however, BT design typically relies on manual modeling by experts, resulting in high maintenance costs when facing open environments and task changes. Large Language Models (LLMs), which have emerged in recent years, possess strong language understanding and knowledge retrieval capabilities, enabling them to transform natural language task descriptions into high-level steps or tool invocation suggestions, providing new possibilities for the automated planning of complex tasks.
[0003] In scenarios such as drone inspection, multi-task execution by indoor service robots, and collaborative operations by mobile manipulators, systems often need to: parse targets from natural language / instructions, decompose and map tasks and constraints, arrange sub-tasks in parallel / serial order according to priority, perceive and provide feedback in real time during execution and adaptively replan, while ensuring safety, explainability, and traceability. How to integrate the flexible intelligence of LLM with the deterministic execution of BT to form a unified planning and execution framework for multi-task applications has become a focus of industry attention.
[0004] Existing technologies suffer from the following main shortcomings: 1. Uncertainty in end-to-end LLM direct execution: The steps and tool calls generated by the LLM are susceptible to prompt word drift and context truncation, resulting in "illusion," unstable output, and difficulty in reproducing issues; the lack of formal verification of preconditions / postconditions and security constraints makes it difficult to meet reliability and authentication requirements. 2. Rigidity of pure BT / state machine solutions: Behavior tree structures are mostly manually written, with fixed rules, requiring extensive refactoring when facing task combinatorial explosion and scenario changes; poor cross-task reusability makes it difficult to quickly extend to new tasks using a language. Summary of the Invention
[0005] In view of the above problems, the present invention is proposed to provide an agent multitasking planning method, apparatus, agent, and storage medium that overcomes or at least partially solves the above problems.
[0006] According to one aspect of the present invention, an agent multi-task planning method is provided, the method comprising: The task statement is input into the language model, and the language model is used to parse the statement to generate an ordered sequence of task instructions. The task instruction sequence is received using a subscription mechanism, and the skill library is scanned according to a predefined loading path and loaded through a dynamic interface. Create the root node of the behavior tree, parse the task description item by item according to the execution order of the task instruction sequence, instantiate the task instructions using the registered functions in the loaded skill library, generate the corresponding behavior tree nodes, and attach them to the root node to form a behavior tree; Based on the behavior tree, the task execution scheduling and / or concurrent processing are performed using the invocation mechanism.
[0007] In some implementations, receiving the task instruction sequence using a subscription mechanism includes: The task instruction sequence is locked by invoking the locking operation of the mutex object in the mutex lock; The locked sequence of task instructions is saved to the action cache; The mutex object's unlock operation is invoked, and the action token in the task instruction sequence is obtained from the action cache as needed, thereby avoiding data races and cache pollution caused by different threads accessing the task instruction sequence at the same time.
[0008] In some implementations, the root node of the behavior tree is created by parsing the task description item by item according to the execution order of the task instruction sequence, instantiating the task instructions using the registered functions in the loaded skill library, generating corresponding behavior tree nodes, and attaching them to the root node, thereby forming a behavior tree including at least one of the following: Find the predefined action node template in the skill library based on the task name, instantiate the task into an atomic behavior node based on the action node template, and add the atomic behavior node to the current parent node; First, the pre-created condition judgment node is used to determine whether the subtask meets the condition. If it does, the corresponding subtree structure is generated. Then, the subtree structure is used as a selector branch and attached to the parent node. Create a parallel control node and write the fault tolerance parameters and exit parameters of the parallel control node into the node configuration; recursively generate the corresponding parallel subtree for each subtask under the parallel control node and attach it to the parallel node, and then attach the entire parallel subtree to the parent node. The behavior tree is generated using a top-down parsing approach based on the task description. It is constructed by uniformly instantiating and recursively building a tree-like hierarchical structure through the node factory in the skill library. During the construction process, control logic, execution interfaces, and status return mechanisms are automatically associated according to the node type, thereby realizing the automatic generation and assembly of the behavior tree.
[0009] In some embodiments, the method further includes: During behavior tree scheduling, the scheduler will call each parallel node under the root node in sequence. Each parallel node will execute the corresponding function after being triggered and return the execution status according to the task execution result, including success, running or failure. The behavior tree automatically decides whether to continue executing the next node based on the return status of the node; When the sequence reaches a condition node, the scheduler first determines whether the condition is met. If the condition is met, the sub-task subtree is executed recursively. If the condition is not met, failure or skipping is returned directly. The control flow is determined by the upper-level control node. Through the above mechanism, it is possible to dynamically select whether to execute a certain sub-task. When executing a parallel node, the scheduler will simultaneously trigger all subtasks when the parallel fault-tolerant node is triggered, resulting in concurrent execution. When the number of failed subtasks exceeds M, the parallel node returns failure; when the number of successful subtasks reaches N, the parallel node returns success early; if neither condition is met, the running state continues. The above mechanism ensures that the task still has controllable success / failure conditions under multi-branch concurrent execution.
[0010] In some implementations, receiving the task instruction sequence using a subscription mechanism further includes: The task instruction sequence is semantically validated to check the integrity of the action name and / or parameters. If the validation passes, the process proceeds to the next step. If the validation fails, the process returns to the step of parsing the statement using a language model.
[0011] In some implementations, scheduling and / or concurrent processing of task execution using a calling mechanism, based on the behavior tree, includes: The main loop thread calls the root node of the behavior tree at a fixed frequency, and performs behavior tree scheduling and message queue based on the updated processing status to generate topic messages; After receiving a topic message, the invocation mechanism automatically distributes the message to behavior tree nodes using the communication layer, calls the pre-bound functions within the behavior tree nodes, parses, caches, and updates the status of the received data, and writes it to the shared storage area.
[0012] In some embodiments, the method further includes at least one of the following: When forming the behavior tree, the target point, threshold or strategy of each task in the task sequence is written into the blackboard, and then each node port is used to read from the blackboard. The following scheduling rules are executed in the scheduling process: if the return is successful, proceed to the next node; if the return is in progress, continue execution; if the return is failure or timeout, roll back, retry, or reconstruct the behavior tree online. During behavior tree execution, sensor status, task execution results, and external feedback are continuously monitored. When a preset trigger condition such as task failure, path infeasibility, or external instruction change is detected, the behavior tree reconstruction process is triggered. The scheduler pauses the trigger call of the current behavior tree at a safe point, freezes the behavior tree structure using a mutex lock, and extracts the current execution node, node execution status, and / or blackboard variables so that execution can continue after reconstruction. The corresponding reconstruction strategy is selected according to the trigger type. Reconstruction strategies include node replacement strategy, path replanning strategy, task expansion strategy, and fault tolerance enhancement strategy. The system then dynamically generates a new subtree structure based on the strategy. After reconstruction is completed, the entire behavior tree execution structure is verified, including node connectivity, consistency of status return type, and / or legality of parallel node parameters. After verification, the mutex lock is released, and the updated behavior tree is reassembled into the scheduler. Publish the node execution results for diagnostics and / or logging.
[0013] According to another aspect of the present invention, an intelligent agent multi-task planning device is provided, the device comprising: The task parsing module is suitable for inputting task statements into the language model, using the language model to parse the statements and generate an ordered sequence of task instructions; The skill loading module is adapted to receive the task instruction sequence using a subscription mechanism, and simultaneously scan the skill library according to a predefined loading path and load the skill library through a dynamic interface. The behavior tree forming module is suitable for creating the root node of the behavior tree. It parses the task description item by item according to the execution order of the task instruction sequence, instantiates the task instructions using the registered functions in the loaded skill library, generates the corresponding behavior tree nodes, and attaches them to the root node to form the behavior tree. The task execution module, based on the behavior tree, uses a calling mechanism to schedule and / or concurrently process task execution.
[0014] According to another aspect of the present invention, an intelligent agent is provided, comprising: a processor and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the intelligent agent multitasking planning method according to any one of the above embodiments.
[0015] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores one or more programs, which, when executed by a processor, implement the intelligent agent multitasking planning method according to any one of the above.
[0016] As can be seen from the above, according to the intelligent agent multi-task planning scheme disclosed in this invention, the natural language target is mapped into a verifiable task description through LLM semantic parsing and constraint extraction; on this basis, behavior tree subtrees are automatically generated or assembled through templated / parameterized rules to achieve a stable bridge between "language-planning-execution".
[0017] Achieve deterministic and interpretable execution closed loop: The behavior tree is responsible for real-time scheduling, precondition and postcondition checks, and rollback / retry logic to ensure deterministic, traceable, and verifiable execution; logs of the tree structure and key decisions are retained for reproducibility and auditing.
[0018] Reduce modeling costs and improve generalization ability: Most combined tasks can be covered with a small number of templates and domain vocabularies; new tasks can be quickly extended through language description, significantly reducing the workload of manual rule writing.
[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0020] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating an agent multi-task planning method according to some embodiments of the present invention is shown. Figure 2 A schematic diagram of the system framework of an agent multi-task planning scheme provided according to some embodiments of the present invention is shown; Figure 3 This diagram illustrates a key process flow for intelligent agent multi-task planning according to some embodiments of the present invention. Figure 4 A schematic diagram of the structure of an intelligent agent multi-task planning device provided according to some embodiments of the present invention is shown; Figure 5 A schematic diagram of the structure of an intelligent agent (including a controller or flight controller) provided according to some embodiments of the present invention is shown. Detailed Implementation
[0021] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.
[0022] Terminology Explanation: Large Language Models (LLMs): Deep learning-based artificial intelligence models primarily used for natural language tasks. These models, trained on large-scale text data, are capable of understanding and generating human language, possessing powerful language understanding and generation capabilities.
[0023] Behavior Tree (BT): An executable decision tree composed of composite nodes and atomic nodes, supporting semantics such as Sequence / Parallel.
[0024] ROS: Robot Operating System: An open-source framework for robot development. In this invention, it serves as the foundation for the distributed control algorithm, providing functions such as node management and communication middleware interfaces to support standardized interaction between multiple intelligent agent control nodes.
[0025] DDS: Data Distribution Service: A high-performance, real-time distributed data communication middleware protocol. In this embodiment of the invention, it is used for communication between modules within an intelligent body under the ROS framework.
[0026] TaskList: An ordered list of tasks obtained from LLM parsing.
[0027] Blackboard: Task / environment shared memory; node ports read and write critical status and parameters from the blackboard.
[0028] Port: The interface for BT node input / output parameters, such as goal / ctrl_type / tolerance_d / timeout_ms, etc.
[0029] Skill Library: A collection of atomic abilities registered as plugins.
[0030] Figure 1 A flowchart illustrating an agent multi-task planning method according to an embodiment of the present invention is shown. The method includes the following steps: Step S110: Input the task statement into the language model, use the language model to parse the statement and generate an ordered sequence of task instructions; Step S120: Receive the task instruction sequence using a subscription mechanism, and simultaneously scan the skill library according to a predefined loading path, and load the skill library through a dynamic interface; Step S130: Create the root node of the behavior tree, parse the task description item by item according to the execution order of the task instruction sequence, instantiate the task instructions using the registered functions in the loaded skill library, generate the corresponding behavior tree nodes, and attach them to the root node to form a behavior tree. Step S140: Based on the behavior tree, the task is scheduled and / or concurrently processed using the invocation mechanism.
[0031] According to the agent multi-task planning method in this embodiment, the natural language target is mapped into a verifiable task description through LLM semantic parsing and constraint extraction; on this basis, behavior tree subtrees are automatically generated or assembled through templated / parameterized rules to achieve a stable bridge between "language-planning-execution".
[0032] In some embodiments, receiving the task instruction sequence using a subscription mechanism in step S120 includes: The task instruction sequence is locked by invoking the locking operation of the mutex object in the mutex lock; The locked sequence of task instructions is saved to the action cache; The mutex object's unlock operation is invoked, and the action token in the task instruction sequence is obtained from the action cache as needed, thereby avoiding data races and cache pollution caused by different threads accessing the task instruction sequence at the same time.
[0033] In some embodiments, step S130 creates the root node of the behavior tree, parses the task description item by item according to the execution order of the task instruction sequence, instantiates the task instructions using the functions registered in the loaded skill library, generates corresponding behavior tree nodes, and attaches them to the root node, thereby forming a behavior tree including at least one of the following: Find the predefined action node template in the skill library based on the task name, instantiate the task into an atomic behavior node based on the action node template, and add the atomic behavior node to the current parent node; First, the pre-created condition judgment node is used to determine whether the subtask meets the condition. If it does, the corresponding subtree structure is generated. Then, the subtree structure is used as a selector branch and attached to the parent node. Create a parallel control node and write the fault tolerance parameters and exit parameters of the parallel control node into the node configuration; recursively generate the corresponding parallel subtree for each subtask under the parallel control node and attach it to the parallel node, and then attach the entire parallel subtree to the parent node. The behavior tree is generated using a top-down parsing approach based on the task description. It is constructed by uniformly instantiating and recursively building a tree-like hierarchical structure through the node factory in the skill library. During the construction process, control logic, execution interfaces, and status return mechanisms are automatically associated according to the node type, thereby realizing the automatic generation and assembly of the behavior tree.
[0034] In some embodiments, the method further includes: During behavior tree scheduling, the scheduler will call each parallel node under the root node in sequence. Each parallel node will execute the corresponding function after being triggered and return the execution status according to the task execution result, including success, running or failure. The behavior tree automatically decides whether to continue executing the next node based on the return status of the node; When the sequence reaches a condition node, the scheduler first determines whether the condition is met. If the condition is met, the sub-task subtree is executed recursively. If the condition is not met, failure or skipping is returned directly. The control flow is determined by the upper-level control node. Through the above mechanism, it is possible to dynamically select whether to execute a certain sub-task. When executing a parallel node, the scheduler will simultaneously trigger all subtasks when the parallel fault-tolerant node is triggered, resulting in concurrent execution. When the number of failed subtasks exceeds M, the parallel node returns failure; when the number of successful subtasks reaches N, the parallel node returns success early; if neither condition is met, the running state continues. The above mechanism ensures that the task still has controllable success / failure conditions under multi-branch concurrent execution.
[0035] In some embodiments, receiving the task instruction sequence using a subscription mechanism in step S120 further includes: The task instruction sequence is semantically validated to check the integrity of the action name and / or parameters. If the validation passes, the process proceeds to the next step. If the validation fails, the process returns to the step of parsing the statement using a language model.
[0036] In some optional embodiments, step S140, based on the behavior tree, utilizes a calling mechanism to schedule and / or concurrently process task execution, including: The main loop thread calls the root node of the behavior tree at a fixed frequency, and performs behavior tree scheduling and message queue based on the updated processing status to generate topic messages; After receiving a topic message, the invocation mechanism automatically distributes the message to behavior tree nodes using the communication layer, calls the pre-bound functions within the behavior tree nodes, parses, caches, and updates the status of the received data, and writes it to the shared storage area.
[0037] In some embodiments, the method further includes at least one of the following: When forming the behavior tree, the target point, threshold or strategy of each task in the task sequence is written into the blackboard, and then each node port is used to read from the blackboard. The following scheduling rules are executed in the scheduling process: if the return is successful, proceed to the next node; if the return is in progress, continue execution; if the return is failure or timeout, roll back, retry, or reconstruct the behavior tree online. During behavior tree execution, sensor status, task execution results, and external feedback are continuously monitored. When a preset trigger condition such as task failure, path infeasibility, or external instruction change is detected, the behavior tree reconstruction process is triggered. The scheduler pauses the trigger call of the current behavior tree at a safe point, freezes the behavior tree structure using a mutex lock, and extracts the current execution node, node execution status, and / or blackboard variables so that execution can continue after reconstruction. The corresponding reconstruction strategy is selected according to the trigger type. Reconstruction strategies include node replacement strategy, path replanning strategy, task expansion strategy, and fault tolerance enhancement strategy. The system then dynamically generates a new subtree structure based on the strategy. After reconstruction is completed, the entire behavior tree execution structure is verified, including node connectivity, consistency of status return type, and / or legality of parallel node parameters. After verification, the mutex lock is released, and the updated behavior tree is reassembled into the scheduler. Publish the node execution results for diagnostics and / or logging.
[0038] The above embodiments will be described in detail below through a specific example: The specific embodiments of this invention disclose a multi-task integrated planning method based on Large Language Model (LLM) + Behavior Tree (BT). This method parses natural language tasks from the LLM into high-level action tokens, which are then transmitted to the execution end via ROS topics. The execution end reconstructs the behavior tree online according to the tokens and immediately enters deterministic scheduling and closed-loop execution. Its core consists of the following modules: 1) Task statement input: The user describes the target in natural language (e.g., "take off → arrive at point A / B → return and land"), and the system receives the statement and context constraints.
[0039] 2) LLM Multitasking Parsing and Serialization: The large language model decomposes sentences into tasks and produces an ordered sequence of task instructions, TaskList, with the order directly reflected in the list order.
[0040] 3) Command access and parsing module: Subscribe to the " / llm_action" string topic to receive action tokens generated by LLM; to ensure thread safety, a mutex lock is used in the callback to write the current action cache.
[0041] The mutex lock can be implemented using a mutex object provided by the system, including: calling the mutex locking operation before writing to the cache and calling the unlock operation after writing to the cache, thereby avoiding data competition and cache pollution caused by simultaneous access by different threads.
[0042] Behavior Tree Generation and Assembly Module: This module dynamically constructs a behavior tree structure based on the task list (TaskList). The assembly module first creates a root node (Sequence), then parses the task descriptions item by item in the TaskList according to their execution order, generating corresponding behavior tree nodes, and attaching them sequentially to the root node. Specifically, it includes: Common actions (Takeoff / ArriveGoal / Land, etc.) Find the predefined action node template based on the task name, instantiate it into an atomic behavior node through the NodeFactory, and add the node to the current parent node.
[0043] Condition node (Condition, Subtask) First, a conditional decision node is created. If the condition is met, a subtree structure corresponding to the described subtask is generated. The subtree is generated in the same way as the main task, i.e., the subtask list is recursively parsed and the corresponding behavior tree nodes are constructed. Then, the conditional node is attached to the parent node as a selector branch.
[0044] Parallel node (M, N, subtasks...) Create a parallel control node and write the fault tolerance parameter M (maximum number of failures allowed) and exit parameter N (minimum number of successes) of the parallel node into the node configuration; recursively generate the corresponding subtree for each subtask under the parallel node and attach it to the parallel node, and finally attach the entire parallel subtree to the parent node.
[0045] The entire generation process adopts a top-down parsing approach based on the task description. It uses a node factory to uniformly instantiate and recursively construct a tree-like hierarchical structure. During the construction process, it automatically associates control logic, execution interfaces, and status return mechanisms according to the node type, thereby realizing the automatic generation and assembly of the behavior tree.
[0046] 5) Skill Library and Plugin Mechanism: During startup, the plugin manager scans for skill library files (e.g., .so / .dll) in a specified plugin directory, which is a plugin loading path predefined in the system configuration file. For each scanned skill library, the system loads it into memory through a dynamic loading interface (such as dlopen or an equivalent mechanism) and calls the plugin registration function exposed in that skill library.
[0047] During the registration process, the registration function writes the type name, constructor, and related metadata of the plugin node into the node factory (NodeFactory) or plugin registry (PluginRegistry) of the behavior tree. Thus, during the behavior tree generation phase, the corresponding action nodes, condition nodes, or control nodes can be dynamically instantiated from the node factory based on the task description, enabling the expansion and modular management of the skill library.
[0048] The execution scheduling and concurrent processing module employs ROS's asynchronous Spinner mechanism to handle callback functions from various functional modules. These callbacks include sensor data callbacks (such as odometry, depth maps, and status feedback), LLM action command callbacks, and other control commands or service feedback callbacks. The asynchronous Spinner executes the message queue in an independent thread, allowing various callback functions to be processed concurrently in the background, thus avoiding blocking the main loop.
[0049] Regarding callback implementation, whenever ROS receives a message for a specific topic, the ROS communication layer automatically dispatches the message to the registered callback function, calling the pre-bound function interface within the node (e.g., a callback method registered via `subscribe()`). This callback function parses, caches, and updates the status of the received data, then writes it to the module's shared storage area. The main loop thread runs independently of the callback thread, calling the behavior tree root node (TickRoot) at a fixed frequency. Based on the updated module state, it performs behavior tree scheduling, achieving both real-time and deterministic execution.
[0050] 7) Robustness and Diagnostic Module: Registers the SIGSEGV / SIGABRT signal processor and outputs the stack for easy anomaly localization and reproduction.
[0051] 2.1.2 Key Processes To ensure the determinism and reproducibility of the "natural language → multi-task → sequential execution (with loops / parallelism)" process, the system executes the following closed-loop flow: 1) Initialization and registration: Start the ROS node and asynchronous spinner?, scan the skill library and register it as a behavior tree plugin node; create topics / services.
[0052] 2) Task access and standardization: Receive the task instruction sequence TaskList output by LLM, and complete semantic verification and parameter completion.
[0053] 3) Behavior tree assembly / reconstruction: First, create a root Sequence, then generate subtrees item by item in the TaskList order and attach them (atomic action / Condition / / Parallel(M, N)), completing blackboard key binding and port parameter injection.
[0054] 4) Feedback loop and status reporting: Write sensor and execution feedback to the blackboard; continuously publish bt_status (node entry / exit / result). When all TaskList tasks are completed, output a "complete" event and a result summary.
[0055] 2.2. Point out the differences between the embodiments of the present invention and previous / existing technical solutions. To facilitate review and implementation, the following section explains the "substantial differences from existing technologies" and the resulting technical effects, item by item, according to the comparison objects.
[0056] 1) Unlike end-to-end LLM direct execution: This invention first parses natural language into an ordered sequence of task instructions (TaskList), and then assembles a behavior tree (BT) online; execution is constrained by the tick semantics, preconditions, timeouts, and rollback strategies of the BT, rather than being directly streamed and controlled by the LLM. Execution is deterministic, reproducible, and auditable; semantic verification can be performed before assembly to confirm the compliance of the instructions.
[0057] 2) Unlike manually written static Bitmap / state machines: Supports online reconstruction and hot replacement. Upon receiving a new TaskList, the root sequence and subtrees are immediately reconstructed; parameters are injected via blackboard, eliminating the need for system downtime to modify the graph. Modeling / maintenance costs are significantly reduced, enabling rapid adaptation to task changes and environmental disturbances.
[0058] 3) Unlike planning methods such as HTN / PDDL that require a complete domain model: it adopts a lightweight task intermediate representation (TaskList) → assembly rules to replace the heavy domain modeling; planning and execution are tightly coupled on BT, and it supports hierarchical replanning at runtime. It has a low threshold for implementation, a short deployment cycle, and is more agile in responding to real-time changes.
[0059] 4) Multi-task integrated planning capability: A single statement is parsed into multiple ordered subtasks and assembled into a root Sequence for sequential execution; it also natively supports loops: Condition: Condition(expression, subtask); Parallel fault tolerance: Parallel(M, N, …) (M = maximum allowed number of failures, N = minimum number of successful exits). While ensuring sequential determinism, it can express and execute complex multi-task processes, and reduce overall latency and failure rate through parallel fault tolerance.
[0060] 5) Plugin-based skill library and unified port specifications: Nodes are registered as dynamic plugins (automatic scanning at startup / registerFromPlugin), and ports / effects / constraints have unified descriptions. Adding new perception / control / tool capabilities requires no modification to the main program, resulting in low cross-platform porting costs.
[0061] 6) Thread-safe instruction access and deterministic scheduling: Instruction access employs mutexes / atomic variables and an asynchronous ROS spinner; the scheduler drives the root tree at a fixed tick interval. This maintains timing stability and deterministic execution even in multi-source message and concurrent scenarios.
[0062] In summary, this invention has formed substantial technical features and beneficial effects that are distinct from existing LLM direct-drive, static BT / state machine and traditional planning methods in terms of language-driven multi-task integrated planning, online assembly and deterministic execution, parallel fault tolerance threshold (M / N) model, and plug-in extension.
[0063] 2.3. Related Drawings of Specific Embodiments of the Invention Figure 2 This is a system architecture diagram in an embodiment of the present invention; Figure 3 This is a key flowchart in an embodiment of the present invention.
[0064] 2.4. Provide detailed textual descriptions in conjunction with the accompanying drawings in section 2.2. 2.4.1 Figure 2 System architecture / process overview (module functions, connection relationships, signal flow) 1) System Initialization Functions: Start ROS nodes and asynchronous spinners, load configurations; scan and register plugins (forming a skill library).
[0065] Output: System parameters, topics / server endpoints ( / llm_action, / bt_status, etc.), skill library index.
[0066] Arrow: Issues an activation command to "User Input Task" and "Plug-in Skill Library" (starts access / can be invoked).
[0067] 2) User inputs task → LLM generates TaskList Function: The user inputs the target in natural language; the LLM parses it into an ordered sequence of task instructions, TaskList (including action type, parameters, and constraints).
[0068] Signal: Text / Context → TaskList.
[0069] 3) ROS Topic Publishing / Subscription Functionality: Decouples TaskList transmission from modules; upstream publishes TaskList to the / llm_action topic and installs module subscriptions.
[0070] Arrows: Indicate the direction of data and control flow from top to bottom; this stage only moves data, does not modify content. Assemble the behavior tree (depending on the "plug-in skill library"). Functionality: Creates a root Sequence, generates and attaches subtrees item by item in the TaskList order: atomic actions (Takeoff / ArriveGoal / ReturnHome / Land …); Condition(condition, subtask) generates conditional branches; Parallel(M, N, …) generates parallel fault-tolerant subtrees (M = maximum allowed failures, N = minimum number of successful exits). The specific execution method is as follows: Execute atomic action node During behavior tree scheduling, TickRoot sequentially calls each atomic action node under Sequence. Each atomic node triggers its internal execution function when it is ticked, such as calling the flight control interface to perform takeoff, movement, return, or landing, and returns Success, Running, or Failure based on the task execution status.
[0071] The behavior tree automatically decides whether to continue executing the next node based on the status returned by the node.
[0072] Execution Condition Node When the sequence reaches a Condition node, the scheduler first ticks the condition judgment function. If the condition is met, it recursively ticks its sub-task subtree; if the condition is not met, it directly returns Failure or Skip (depending on the node type), and the upper-level control node determines the control flow. This mechanism allows for dynamic selection of whether to execute a certain task branch.
[0073] Execute the parallel node Parallel(M, N) When a parallel fault-tolerant node is ticked, the scheduler simultaneously ticks all subtasks, creating a concurrent execution effect. If the number of failed subtasks exceeds M, the parallel node returns Failure; if the number of successful subtasks reaches N, the parallel node returns Success early; if neither condition is met, the node remains in the Running state. This mechanism ensures that tasks maintain controllable success / failure conditions even under multi-branch concurrent execution.
[0074] 4) Execute the scheduler Functionality: Schedules root nodes at fixed tick intervals; handles SUCCESS / RUNNING / FAILURE, timeouts, rollbacks, retries, and (if necessary) online refactoring.
[0075] Output: Control commands to the "Sensing / Control Interface" output status events to the "Diagnostics and Logs".
[0076] 5) Sensing / Control Interface Functions: Unified access to attitude / position / obstacle avoidance sensor data; sending setpoint / mode / cmd_vel control commands to flight controller / chassis.
[0077] Signal: Bidirectional—Receives commands from the "Execution Scheduler" and sends execution feedback to the blackboard.
[0078] Execute the task Function: To complete the various actions in TaskList in a real or simulated environment (mainly sequential, with the option of parallelism / looping).
[0079] Arrow: Down to "Diagnostics and Logs".
[0080] 6) Diagnostics and Logs Functions: Records bt_status (node entry / exit / result), diag_event (alarms / abnormalities), performance and blackboard key values.
[0081] Output: Structured logs and "complete / failure / degradation" events.
[0082] Arrow meanings: Vertical arrows indicate main control / data timing; horizontal arrows from the "plug-in skill library" to the "assembly behavior tree" indicate capability retrieval and injection; all judgments / loops are in... Figure 2 Expand.
[0083] 2.4.2 Figure 3 Method flowchart (steps, inputs / outputs for decision-making) 1) Initialize ROS nodes, asynchronous Spinner, and plugin scanning. Output: Available plugin registry, timers, subscribers / publishers.
[0084] 2) Waiting for LLM messages → Receiving the TaskList Input: TaskList (JSON) for the topic / llm_action; Bypass operation: write the mutex lock to the cache to avoid concurrent read and write conflicts between the callback and the assembly thread.
[0085] Output: A standardized TaskList to be assembled.
[0086] 3) Semantic validation Check: Action name and parameter integrity.
[0087] Judgment: Pass? No → Feedback to upstream (returning error code / suggested constraints, or automatically downgrading and then sending back a prompt); the process terminates here or waits for new messages.
[0088] Yes → Proceed to assembly.
[0089] 4) Create the root sequence Output: Empty root node, ready to be attached item by item.
[0090] 5) Attach nodes in TaskList order For each task item: Atomic action → Create the corresponding plugin node; Repeat / Condition / Parallel → Generates a structured subtree; Bind params to the port (goal, ctrl_type, tolerance_d, timeout_ms, etc.).
[0091] 6) Bind blackboard key & inject parameters Write target points / thresholds / policies from TaskList to Blackboard, and read node ports from the blackboard; Output: An executable behavior tree with all parameters.
[0092] 7) Main loop: tickRoot() Scheduling rules: SUCCESS → next node; RUNNING → hold; FAILURE / timeout → rollback / retry / (if necessary) online reconstruction; Simultaneously execute safety protection (triggering minimal risk actions such as low battery / crossing boundaries / loss of contact).
[0093] 8) Publish bt_status Content: Node entry / exit / results, for "Diagnosis and Log" recording and visualization.
[0094] 9) Determine: Are all tasks completed? Yes → Publish "Completed" event (including results summary / statistics) → End; No → Return to "main loop: tickRoot()".
[0095] 2.5 Detailed Explanation of the Technical Effects of the Invention The multi-task integrated planning method of this invention achieves advantages that traditional single-task processing methods cannot reach, and has the following significant technical effects: 1) Improve the efficiency and reliability of multi-task execution. Solution: Through the workflow of "natural language → task instruction sequence (TaskList) → behavior tree assembly", the system can automatically break down the user-input task into multiple ordered subtasks and convert them into an executable behavior tree.
[0096] Technical Results: This system enables parallel planning and sequential execution of multiple tasks, effectively improving task execution efficiency while ensuring task reliability and stability. Each subtask has a defined execution order, avoiding conflicts and resource contention between complex tasks and ensuring a smooth transition between different tasks.
[0097] 2) Supports dynamic adaptation and reconfiguration of tasks Solution: Through online reconstruction and hot replacement functions, the system can dynamically adjust the behavior tree structure based on real-time feedback and changes during task execution.
[0098] The specific implementation steps include: Real-time status monitoring and trigger judgment During behavior tree execution, the system continuously monitors sensor status, task execution results, and external feedback (such as failure count, task progress, and environmental changes). When a preset trigger condition is detected (such as task failure, infeasible path, or change of external instructions), the refactoring process is triggered.
[0099] Locking the behavior tree and obtaining the current context At the safe point, the scheduler pauses tick calls for the current behavior tree and freezes the behavior tree structure using a mutex lock. Simultaneously, it extracts context information such as the currently executing node, node execution state, and blackboard variables to allow execution to resume after reconstruction.
[0100] Select a reconstruction strategy and generate a replacement subtree. The system selects the corresponding reconstruction strategy based on the trigger type, including node replacement strategy (replacing non-executable actions or conditions), path replanning strategy (reconstructing path action subtrees), task expansion strategy (temporarily inserting new task nodes), and fault tolerance enhancement strategy (replacing Sequence with Parallel fault-tolerant structure). The system then dynamically generates a new subtree structure based on the strategy.
[0101] Locate the node to be replaced in the original behavior tree. The scheduler locates the node or subtree to be replaced in the behavior tree structure based on the current context and the node position specified by the policy, and performs a structure-level hot replacement with the generated new subtree.
[0102] Structural verification and reassembly After the replacement is completed, a structural check is performed on the entire behavior tree, including node connectivity, consistency of state return types, and validity of parallel node parameters. If the check is successful, the mutex lock is released, and the updated behavior tree is reassembled into the scheduler.
[0103] Resumption of Execution and Seamless Integration The scheduler resumes the execution flow based on the saved context (current node, blackboard state, etc.) and continues to tick the root node in the next cycle, achieving seamless dynamic adjustment of the behavior tree.
[0104] Technical benefits: It enables the system to adapt to changes in the real-time environment, such as new obstacles perceived during execution, changes in the task midway, or fluctuations in the external environment. It can automatically adjust the execution order or execution method of the task, thereby improving the system's flexibility and robustness.
[0105] 3) Reduce system development and maintenance costs Solution: This invention employs a plug-in-based skill library and task graph assembly method. Various task actions are supported through plug-in nodes in the skill library without modifying the main program. Adding new tasks or skills simply requires adding the new plug-in to the skill library.
[0106] Technical benefits: Significantly reduces system development, expansion, and maintenance costs. For complex task scenarios, developers can quickly reuse existing nodes, avoiding the repetitive work of writing each task process from scratch, and the plug-in design allows for flexible expansion and integration of new features.
[0107] 4) Enhance the reproducibility and auditability of the system. Solution: Through a structured logging mechanism and a behavior tree-based end-to-end reproduction function, the system can fully record the task execution process, including key data such as task input, node status, and execution results.
[0108] Technical benefits: Each task execution provides detailed trajectory data, supporting comprehensive backtracking from input to result and ensuring the reproducibility of the task execution process. Simultaneously, logs can be used for auditing and anomaly tracing, meeting compliance requirements and increasing the system's controllability and transparency.
[0109] 5) Improve the real-time performance and accuracy of task scheduling. Solution: The system uses a behavior tree-based scheduling and execution mechanism to ensure that each task is executed in a predetermined order and under predetermined conditions, and employs timers and timeout retry mechanisms to improve execution efficiency.
[0110] Technical benefits: The scheduler can precisely control the execution sequence and priority of tasks, ensuring that tasks are completed on time and avoiding execution delays caused by task waiting or conflicts. Furthermore, the system can automatically retry or rollback based on timeouts or failures, ensuring stability and real-time performance during task execution.
[0111] 6) Improved fault tolerance for multi-tasking Solution: By using parallel fault-tolerant nodes (Parallel(M,N)) and a failure retry mechanism, the system can handle some failed or abnormal tasks in a multi-tasking environment. When a task fails, partial rollback or replacement can be performed to ensure that the overall task can continue to execute.
[0112] The specific implementation steps include: a. Parallel task initiation and status monitoring When a Parallel(M, N) node is triggered by a clock tick, the scheduler simultaneously starts all its subtasks and monitors the return status of each subtask in real time during execution, including Success, Failure, and Running.
[0113] b. Failure counting and fault tolerance The system maintains a failure counter. When a subtask returns a failure, the failure counter is incremented by one; it is then checked whether the number of failures exceeds the allowable limit M. If it does not exceed M, the subtask is considered tolerable and monitoring of other subtasks continues; if it exceeds M, the parallel node immediately returns a failure and triggers subsequent rollback or alternative processing.
[0114] c. Successful task statistics and early exit judgment The system synchronously counts the number of successful subtasks. When the number of successful subtasks reaches the minimum success threshold N, the Parallel node returns "Success" early; unfinished subtasks will be terminated or ignored to avoid unnecessary waiting. This mechanism ensures that the task can proceed to the next stage as soon as some subtasks succeed.
[0115] d. Triggering and execution of the failure retry mechanism When a critical subtask fails consecutively but does not reach the M threshold, the scheduler initiates a retry mechanism according to a preset strategy. This includes reinitializing the subtask's internal state, resetting relevant blackboard variables, and re-executing the subtask in the next tick cycle. The number of retries can be configured by task parameters to improve robustness.
[0116] e. Execution of partial rollback strategy If a subtask failure causes the entire node to fail (number of failures > M), the system executes a partial rollback strategy, calling predefined Recovery / Reset nodes (such as home point relocation, attitude stabilization, and path replanning). After the rollback node completes, the system decides whether to re-execute the Parallel subtree or switch to an alternative task. This step ensures that critical failures do not cause the entire task to terminate.
[0117] f. Execution of alternative task subtrees If the system is configured with an alternative plan, the scheduler automatically switches to a backup action or subtree upon detecting an unrecoverable failure, such as alternative path planning, low-risk mode, or simplified task flow. Once the alternative subtree executes successfully, the main task continues.
[0118] g. Task flow recovery and continuation After the fault tolerance, retry, rollback, or alternative process is completed, the scheduler continues to execute the next node according to the behavior tree semantics; there is no need to restart the task or rebuild the behavior tree, ensuring the continuity and stability of task execution.
[0119] Technical effect: It significantly improves the system's fault tolerance. Even if some subtasks fail or malfunction, the overall task can continue to progress, avoiding the stagnation or interruption of the overall task.
[0120] 7) Enhance the flexibility of multi-tasking execution Solution: This invention supports conditional branching and parallel execution of tasks. Through structures such as Condition(condition, subtask) and Parallel(M, N, ...), it is possible to add conditional judgments or parallel execution capabilities to tasks.
[0121] Technical benefits: It greatly improves the system's adaptability to complex task scenarios, and can automatically adjust the task execution strategy according to environmental changes or task requirements, so as to achieve more complex multi-task collaborative processing.
[0122] 8) Supports cross-platform extension and integration Solution: Through a plug-in mechanism and a unified task interface, the system can be flexibly integrated with different platforms, hardware devices or operating systems to adapt to different application scenarios.
[0123] Technical benefits: The system has strong portability and scalability, and can be widely used in many fields such as drones, robots, and smart devices to meet the needs of different environments and tasks.
[0124] In summary, the technical solutions of the specific embodiments of this invention achieve significant improvements in multi-task execution, resource scheduling, security protection, and fault tolerance, enabling efficient, reliable, and secure task execution in complex and dynamic environments. Compared to existing technologies, the embodiments of this invention offer significant advantages in flexibility, scalability, robustness, and real-time performance, providing a feasible, practical, and easily scalable solution for multi-task systems.
[0125] 3.1 The core points of the embodiments of the present invention include: 1) Three-layer bridging of language → task graph → behavior tree: Natural language / instructions are semantically parsed to generate task intermediate representation (Task-DSL), and then behavior tree subtrees are automatically synthesized / assembled to achieve stable mapping and reproduction from "language description" to "verifiable execution graph".
[0126] 2) Online reconstruction and hot replacement: At runtime, the subtree is generated, replaced and parameters are injected online based on the new action token / environment feedback (including blackboard binding), and tasks can be changed without downtime.
[0127] 3.2 Alternative Technical Solutions / Supplementary Embodiments of the Invention Without departing from the purpose of the invention, the following variations can achieve substantially similar technical effects: 1) Upstream intelligent replacement: LLM can be replaced with a micro language model, rule / template engine, RAG / ontology driven parser, parser (PEG / ANTLR) or HTN task decomposer.
[0128] 2) Communication and Middleware: In addition to ROS1 / ROS2, DDS, MQTT, gRPC, ZeroMQ, shared memory, or local function calls can be used; both single-machine and distributed systems are acceptable.
[0129] 3) Execution representation: The behavior tree can be replaced with HTN, GOAP, UML Statechart, Petri net, task DAG, etc., as long as the same pre / post conditions and fallback mechanism are met; a timing logic monitor can also be embedded on the tree.
[0130] 4) Plugin form replacement: The skill library can be replaced with Python plugins, microservices / containers, remote RPC skills, or static link libraries.
[0131] 5) Platform and objects: It is also applicable to drones, AGVs / AMRs, robotic arms, USVs / UGVs, etc.; it can be implemented in simulation / real machine, single machine / distributed.
[0132] 3.3 Products in which this technology is applied 1) Method-based products A language-planning-execution approach for complex multi-task applications; and an online behavior tree assembly method for reconstruction.
[0133] 2) System / Device Multi-task planning and execution system: including instruction access unit, parsing and pre-inspection unit, assembly unit, execution scheduling unit, sensing / control interface unit, diagnosis and logging unit, security protection unit, and plug-in skill library unit.
[0134] Robot control device / terminal: Deploy the above system in flight control computer, edge box, vehicle-mounted industrial control computer, etc.
[0135] 3) Computer-readable storage media Store the program code, assembly template, threshold strategy, and plugin description used to execute the method.
[0136] 4) Product forms categorized by implementation end Server-side (cloud / edge): LLM parsing and TaskList generation service, strategy library / template library, log and playback service, plugin repository.
[0137] Client-side (Robot-side Agent Runtime): Command access, BT assembly / execution, sensing / control interface, security protection, blackboard and local logs.
[0138] Development side (SDK / tools): Node plugin SDK, visual BT editor, task template editor, log playback and analysis tool.
[0139] In summary, the key points and beneficial effects of the embodiments of the present invention include: 1) In this embodiment of the invention, natural language is first parsed into an ordered sequence of task instructions (TaskList), and then a behavior tree (BT) is assembled online. Execution is constrained by the tick semantics, preconditions, timeouts, and rollback strategies of the BT, rather than being directly stream-controlled by the LLM. Execution is deterministic, reproducible, and auditable; semantic verification can be performed before assembly to confirm whether the instructions are compliant.
[0140] 2) This invention supports online reconstruction and hot replacement. Upon receiving a new TaskList, the root sequence and subtrees are immediately reconstructed; parameters are injected via the blackboard, eliminating the need for system downtime to modify the graph. Modeling / maintenance costs are significantly reduced, and it can quickly adapt to task changes and environmental disturbances.
[0141] 3) This invention adopts a lightweight task intermediate representation (TaskList) → assembly rules to replace the heavy domain modeling; planning and execution are tightly coupled on BT, and support hierarchical replanning during runtime. It has a low implementation threshold, short deployment cycle, and is more agile in responding to real-time changes.
[0142] 4) Multi-task integrated planning capability: A single statement is parsed into multiple ordered subtasks and assembled into a root Sequence for sequential execution; it also natively supports loops: Condition: Condition(expression, subtask); Parallel fault tolerance: Parallel(M, N, …) (M = maximum allowed number of failures, N = minimum number of successful exits). While ensuring sequential determinism, it can express and execute complex multi-task processes, and reduce overall latency and failure rate through parallel fault tolerance.
[0143] 5) Plugin-based skill library and unified port specifications: Nodes are registered as dynamic plugins (automatic scanning at startup / register From Plugin), and ports / effects / constraints have unified descriptions. Adding new perception / control / tool capabilities requires no changes to the main program, resulting in low cross-platform portability costs.
[0144] 6) Thread-safe instruction access and deterministic scheduling: Instruction access employs mutexes / atomic variables and an asynchronous ROS spinner; the scheduler drives the root tree at a fixed tick interval. This maintains timing stability and deterministic execution even in multi-source message and concurrent scenarios.
[0145] In summary, this invention has formed substantial technical features and beneficial effects that are distinct from existing LLM direct-drive, static BT / state machine and traditional planning methods in terms of language-driven multi-task integrated planning, online assembly and deterministic execution, parallel fault tolerance threshold (M / N) model, and plug-in extension.
[0146] Combination Figure 4 As shown, the present invention also protects an intelligent agent multi-task planning device 400, the intelligent agent multi-task planning device 400 comprising: The task parsing module 410 is suitable for inputting task statements into a language model, using the language model to parse the statements and generate an ordered sequence of task instructions. The skill loading module 420 is adapted to receive the task instruction sequence using a subscription mechanism, and simultaneously scan the skill library according to a predefined loading path and load the skill library through a dynamic interface. The behavior tree forming module 430 is adapted to create the root node of the behavior tree. It parses the task description item by item according to the execution order of the task instruction sequence, instantiates the task instructions using the functions registered in the loaded skill library, generates the corresponding behavior tree nodes, and attaches them to the root node to form a behavior tree. The task execution module 440 schedules and / or processes tasks concurrently using a calling mechanism based on the behavior tree.
[0147] According to the agent multi-task planning device in this embodiment, the natural language target is mapped into a verifiable task description through LLM semantic parsing and constraint extraction; on this basis, behavior tree subtrees are automatically generated or assembled through templated / parameterized rules to achieve a stable bridge between "language-planning-execution".
[0148] This embodiment also achieves a deterministic and interpretable execution closed loop: the behavior tree handles real-time scheduling, precondition checks, and rollback / retry logic, ensuring the determinism, traceability, and verifiability of execution; and retains logs of the tree structure and key decisions for reproducibility and auditing.
[0149] The aforementioned device can reduce modeling costs and improve generalization ability: it can cover most combined tasks with a small number of templates and domain vocabularies; it can quickly expand new tasks through language description, significantly reducing the workload of manual rule writing.
[0150] In some embodiments, the skill loading module 420 is further adapted to: The task instruction sequence is locked by invoking the locking operation of the mutex object in the mutex lock; The locked sequence of task instructions is saved to the action cache; The mutex object's unlock operation is invoked, and the action token in the task instruction sequence is obtained from the action cache as needed, thereby avoiding data races and cache pollution caused by different threads accessing the task instruction sequence at the same time.
[0151] In some embodiments, the behavior tree forming module is further adapted to: Find the predefined action node template in the skill library based on the task name, instantiate the task into an atomic behavior node based on the action node template, and add the atomic behavior node to the current parent node; First, the pre-created condition judgment node is used to determine whether the subtask meets the condition. If it does, the corresponding subtree structure is generated. Then, the subtree structure is used as a selector branch and attached to the parent node. Create a parallel control node and write the fault tolerance parameters and exit parameters of the parallel control node into the node configuration; recursively generate the corresponding parallel subtree for each subtask under the parallel control node and attach it to the parallel node, and then attach the entire parallel subtree to the parent node. The behavior tree is generated using a top-down parsing approach based on the task description. It is constructed by uniformly instantiating and recursively building a tree-like hierarchical structure through the node factory in the skill library. During the construction process, control logic, execution interfaces, and status return mechanisms are automatically associated according to the node type, thereby realizing the automatic generation and assembly of the behavior tree.
[0152] In some embodiments, the device 400 is further adapted to: During behavior tree scheduling, the scheduler will call each parallel node under the root node in sequence. Each parallel node will execute the corresponding function after being triggered and return the execution status according to the task execution result, including success, running or failure. The behavior tree automatically decides whether to continue executing the next node based on the return status of the node; When the sequence reaches a condition node, the scheduler first determines whether the condition is met. If the condition is met, the sub-task subtree is executed recursively. If the condition is not met, failure or skipping is returned directly. The control flow is determined by the upper-level control node. Through the above mechanism, it is possible to dynamically select whether to execute a certain sub-task. When executing a parallel node, the scheduler will simultaneously trigger all subtasks when the parallel fault-tolerant node is triggered, resulting in concurrent execution. When the number of failed subtasks exceeds M, the parallel node returns failure; when the number of successful subtasks reaches N, the parallel node returns success early; if neither condition is met, the running state continues. The above mechanism ensures that the task still has controllable success / failure conditions under multi-branch concurrent execution.
[0153] In some embodiments, the skill loading module 420 is further adapted to: The task instruction sequence is semantically validated to check the integrity of the action name and / or parameters. If the validation passes, the process proceeds to the next step. If the validation fails, the process returns to the step of parsing the statement using a language model.
[0154] In some alternative embodiments, the task execution module 440 is adapted to: The main loop thread calls the root node of the behavior tree at a fixed frequency, and performs behavior tree scheduling and message queue based on the updated processing status to generate topic messages; After receiving a topic message, the invocation mechanism automatically distributes the message to behavior tree nodes using the communication layer, calls the pre-bound functions within the behavior tree nodes, parses, caches, and updates the status of the received data, and writes it to the shared storage area.
[0155] In some embodiments, the device 400 is further adapted to: When forming the behavior tree, the target point, threshold or strategy of each task in the task sequence is written into the blackboard, and then each node port is used to read from the blackboard. The following scheduling rules are executed in the scheduling process: if the return is successful, proceed to the next node; if the return is in progress, continue execution; if the return is failure or timeout, roll back, retry, or reconstruct the behavior tree online. During behavior tree execution, sensor status, task execution results, and external feedback are continuously monitored. When a preset trigger condition such as task failure, path infeasibility, or external instruction change is detected, the behavior tree reconstruction process is triggered. The scheduler pauses the trigger call of the current behavior tree at a safe point, freezes the behavior tree structure using a mutex lock, and extracts the current execution node, node execution status, and / or blackboard variables so that execution can continue after reconstruction. The corresponding reconstruction strategy is selected according to the trigger type. Reconstruction strategies include node replacement strategy, path replanning strategy, task expansion strategy, and fault tolerance enhancement strategy. The system then dynamically generates a new subtree structure based on the strategy. After reconstruction is completed, the entire behavior tree execution structure is verified, including node connectivity, consistency of status return type, and / or legality of parallel node parameters. After verification, the mutex lock is released, and the updated behavior tree is reassembled into the scheduler. Publish the node execution results for diagnostics and / or logging.
[0156] It should be noted that the specific implementation methods of the above-mentioned device embodiments can be referred to the specific implementation methods of the corresponding methods described above, and will not be repeated here.
[0157] It should be noted that: The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. Various general-purpose devices can also be used in conjunction with the teachings herein. The required structure for constructing such devices is apparent from the above description. Furthermore, this invention is not directed to any particular programming language. It should be understood that the contents of the invention described herein can be implemented using various programming languages, and the above description of specific languages is for the purpose of disclosing the best mode of implementation of the invention.
[0158] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.
[0159] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of the invention. However, this disclosure should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim.
[0160] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.
[0161] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of the invention and form different embodiments.
[0162] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the intelligent agent multitasking planning device according to embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
[0163] This invention provides a non-volatile computer storage medium storing at least one executable instruction that can execute the intelligent agent multi-task planning method described in any of the above method embodiments.
[0164] Figure 5 The diagram shows a structural schematic of an embodiment of the intelligent agent of the present invention. The intelligent agent may be a vertically mounted fixed-wing intelligent agent. The specific embodiments of the present invention do not limit the specific structure of the intelligent agent.
[0165] like Figure 5 As shown, the intelligent agent (including a controller, control node, or flight controller) may include: a processor 502, a communications interface 504, a memory 506, and a communications bus 508.
[0166] The processor 502, communication interface 504, and memory 506 communicate with each other via communication bus 508. Communication interface 504 is used to communicate with other network elements, such as clients or other servers. Processor 502 executes program 510, specifically performing the relevant steps in the above-described embodiment of the intelligent agent multi-task planning method for intelligent agents.
[0167] Specifically, program 510 may include program code that includes computer operation instructions.
[0168] Processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The intelligent agent includes one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs.
[0169] Memory 506 is used to store program 510. Memory 506 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.
[0170] Specifically, program 510 can be used to cause processor 502 to perform the operations corresponding to the above-described intelligent agent multi-task planning method embodiment.
[0171] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.
Claims
1. A multi-task planning method for intelligent agents, characterized in that, The method includes: The task statement is input into the language model, and the language model is used to parse the statement to generate an ordered sequence of task instructions. The task instruction sequence is received using a subscription mechanism, and the skill library is scanned according to a predefined loading path and loaded through a dynamic interface. Create the root node of the behavior tree, parse the task description item by item according to the execution order of the task instruction sequence, instantiate the task instructions using the registered functions in the loaded skill library, generate the corresponding behavior tree nodes, and attach them to the root node to form a behavior tree; Based on the behavior tree, the task execution scheduling and / or concurrent processing are performed using the invocation mechanism.
2. The method according to claim 1, characterized in that, Receiving the task instruction sequence using a subscription mechanism includes: The task instruction sequence is locked by invoking the locking operation of the mutex object in the mutex lock; The locked sequence of task instructions is saved to the action cache; The mutex object's unlock operation is invoked, and the action token in the task instruction sequence is obtained from the action cache as needed, thereby avoiding data races and cache pollution caused by different threads accessing the task instruction sequence at the same time.
3. The method according to claim 1, characterized in that, Create the root node of the behavior tree, parse the task description item by item according to the execution order of the task instruction sequence, instantiate the task instructions using the registered functions in the loaded skill library, generate the corresponding behavior tree nodes, and attach them to the root node, thereby forming a behavior tree including at least one of the following: Find the predefined action node template in the skill library based on the task name, instantiate the task into an atomic behavior node based on the action node template, and add the atomic behavior node to the current parent node; First, the pre-created condition judgment node is used to determine whether the subtask meets the condition. If it does, the corresponding subtree structure is generated. The subtree structure is then attached to the parent node as a selector branch; Create a parallel control node and write the fault tolerance parameters and exit parameters of the parallel control node into the node configuration; For each subtask under the parallel control node, a corresponding parallel subtree is recursively generated and attached to the parallel node. Then, the entire parallel subtree is attached to the parent node. The behavior tree is generated using a top-down parsing approach based on the task description. It is constructed by uniformly instantiating and recursively building a tree-like hierarchical structure through the node factory in the skill library. During the construction process, control logic, execution interfaces, and status return mechanisms are automatically associated according to the node type, thereby realizing the automatic generation and assembly of the behavior tree.
4. The method according to claim 3, characterized in that, The method further includes: During behavior tree scheduling, the scheduler will call each parallel node under the root node in sequence. Each parallel node will execute the corresponding function after being triggered and return the execution status according to the task execution result, including success, running or failure. The behavior tree automatically decides whether to continue executing the next node based on the return status of the node; When the sequence reaches a condition node, the scheduler first determines whether the condition is met. If the condition is met, the sub-task subtree is executed recursively. If the condition is not met, failure or skipping is returned directly. The control flow is determined by the upper-level control node. Through the above mechanism, it is possible to dynamically select whether to execute a certain sub-task. When executing a parallel node, the scheduler will simultaneously trigger all subtasks when the parallel fault-tolerant node is triggered, resulting in concurrent execution. When the number of failed subtasks exceeds M, the parallel node returns failure; when the number of successful subtasks reaches N, the parallel node returns success early; if neither condition is met, the running state continues. The above mechanism ensures that the task still has controllable success / failure conditions under multi-branch concurrent execution.
5. The method according to any one of claims 1-4, characterized in that, Receiving the task instruction sequence using a subscription mechanism also includes: The task instruction sequence is semantically validated to check the integrity of the action name and / or parameters. If the validation passes, the process proceeds to the next step. If the validation fails, the process returns to the step of parsing the statement using a language model.
6. The method according to any one of claims 1-4, characterized in that, Based on the behavior tree, the task execution scheduling and / or concurrent processing using the invocation mechanism includes: The main loop thread calls the root node of the behavior tree at a fixed frequency, and performs behavior tree scheduling and message queue based on the updated processing status to generate topic messages; After receiving a topic message, the invocation mechanism automatically distributes the message to behavior tree nodes using the communication layer, calls the pre-bound functions within the behavior tree nodes, parses, caches, and updates the status of the received data, and writes it to the shared storage area.
7. The method according to claim 6, characterized in that, The method further includes at least one of the following: When forming the behavior tree, the target point, threshold or strategy of each task in the task sequence is written into the blackboard, and then each node port is used to read from the blackboard. The following scheduling rules are executed in the scheduling process: if the return is successful, proceed to the next node; if the return is in progress, continue execution; if the return is failure or timeout, roll back, retry, or reconstruct the behavior tree online. During the execution of the behavior tree, the sensor status, task execution results and external feedback are continuously monitored. When the preset trigger conditions such as task failure, path infeasibility or external instruction change are detected, the process of reconstructing the behavior tree is triggered. The scheduler pauses the triggering of the current behavior tree at the safe point, freezes the behavior tree structure using a mutex lock, and extracts the current execution node, node execution state, and / or blackboard variables so that execution can continue after reconstruction; The system selects the corresponding reconstruction strategy based on the trigger type. The reconstruction strategies include node replacement strategy, path replanning strategy, task expansion strategy, and fault tolerance enhancement strategy. The system then dynamically generates a new subtree structure based on the strategy. After the reconstruction is completed, a structural check is performed on the entire behavior tree, including node connectivity, consistency of state return type and / or validity of parallel node parameters. After verifying that there are no errors, release the mutex lock and reassemble the updated behavior tree into the scheduler; Publish the node execution results for diagnostics and / or logging.
8. A multi-task planning device for an intelligent agent, characterized in that, The device includes: The task parsing module is suitable for inputting task statements into the language model, using the language model to parse the statements and generate an ordered sequence of task instructions; The skill loading module is adapted to receive the task instruction sequence using a subscription mechanism, and simultaneously scan the skill library according to a predefined loading path and load the skill library through a dynamic interface. The behavior tree forming module is suitable for creating the root node of the behavior tree. It parses the task description item by item according to the execution order of the task instruction sequence, instantiates the task instructions using the registered functions in the loaded skill library, generates the corresponding behavior tree nodes, and attaches them to the root node to form the behavior tree. The task execution module, based on the behavior tree, uses a calling mechanism to schedule and / or concurrently process task execution.
9. An intelligent agent, characterized in that, It includes a processor and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the agent multitasking planning method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that, when executed by a processor, implement the agent multi-task planning method according to any one of claims 1-7.