Robot building block program generation method and device and computer equipment

Abstract

The application relates to a robot building block program generation method and device and computer equipment, semantic understanding and structural assembly responsibility are completely separated, that is, a large language model is called to be responsible for semantic understanding that the large language model is good at, and a tree-shaped tool calling structure that does not contain any XML is output; finally, XML program assembly is completed according to predefined connection rules that can be accurately executed by code. Since the LLM only needs to output structured JSON, the task complexity is greatly reduced, and the accuracy of semantic understanding is improved; the assembly of the XML is realized based on the predefined connection rules, so that the correctness of the connection is guaranteed; meanwhile, the generation speed is synergistically optimized through tree-shaped tool calling structure driven parallel tool calling, and finally, a complete building block XML program that can be directly imported into a building block editor for execution is output.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating robot building blocks. Background Technology

[0002] With the popularization of robotics technology and its deep application in education, visual block programming (such as graphical programming based on the Blockly framework) has been widely used in the field of robot control due to its intuitive and low-barrier characteristics. Users describe the robot's motion, perception, and control logic by assembling blocks. The program is serialized and stored in XML format and is ultimately interpreted and executed or compiled into low-level instructions. The structure of the block XML has strict constraints on the connection relationships: statement blocks must be chained together in sequence through tags; output blocks must be nested in the value input slots of their parent blocks; control structures must contain correct child elements and branch / loop body tags. Any XML that violates these rules will generate parsing errors when imported into the editor, causing the robot program to fail to execute.

[0003] In recent years, the automatic generation technology of block programs based on large language models has received widespread attention. Traditional methods mainly fall into two categories: The first is the end-to-end direct generation method, which inputs the XML format descriptions of all block types and the user's natural language task instructions into the large language model at once, and the model directly outputs the complete block XML program. However, this method requires the model to simultaneously undertake four tasks in the same generation process: semantic understanding, format memorization, structural assembly, and compliance with connection rules. As the task complexity and the number of blocks increase, the constraints that the model needs to maintain in a single inference increase dramatically, leading to frequent structural problems such as incorrect placement of output blocks at the top level, omission of chain relationships, and format errors. This results in a significant increase in the failure rate and logical error rate of the generated XML when importing it into the block editor. The second type of method adopts the MCP tool-based improvement scheme, which encapsulates each block type into an independent tool interface, which is called step by step by the large language model to generate each block XML fragment. Although this method alleviates the format correctness problem of single fragments to some extent, the final assembly process between fragments is still the responsibility of the large language model. Because the nesting relationships, serial order, and slot matching rules between building blocks place extremely high demands on the model's structured reasoning ability, connection errors still frequently occur during the assembly stage in scenarios with deep nesting levels of task logic and complex control structures. Moreover, these errors are difficult to pinpoint accurately and fix locally, often requiring the entire model to be regenerated, which affects both the correctness of the output and severely restricts the generation efficiency.

[0004] Both of these approaches face the same fundamental contradiction: large language models simultaneously handle semantic understanding and structural assembly, while structural connection rules are essentially deterministic constraints that can be precisely executed by code, yet they are delegated to large language models with probabilistic output characteristics. As task complexity increases, verification and retry rounds must be added to ensure correct generation, and each retry requires a full LLM call, causing generation time to increase linearly or even superlinearly with complexity, making it impossible to simultaneously meet the dual requirements of high correctness and high efficiency. Summary of the Invention

[0005] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for generating robot building blocks, in response to the above-mentioned technical problems.

[0006] In a first aspect, this application provides a method for generating robot building block programs, the method comprising: Obtain task description information for robot control tasks issued in natural language format; Based on the task description information and the predefined MCP tool registry, a tree-shaped tool call structure is generated by calling the large language model; the tree-shaped tool call structure is expressed in JSON format, including the tool name of each node, call parameters, hierarchical relationship between nodes, and slot type label; the MCP tool registry includes the tool name of at least one MCP tool and its corresponding natural language tool description; The validity of the tree-shaped tool call structure is verified based on preset verification conditions; If the verification is successful, based on the hierarchical relationship between nodes in the tree-shaped tool call structure, the corresponding MCP tool is called concurrently for nodes with no dependency relationship to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool. Based on the block type tags of each node, the block XML fragments of each node are recursively assembled from bottom to top according to predefined connection rules to obtain a complete block XML program corresponding to the task description information.

[0007] In one embodiment, the block type label includes block categories such as statement type, output type, and control type; The statement-type building blocks have predecessor connection nodes and successor connection nodes for sequential chaining, and sibling nodes are linked by tags during assembly; The output-type blocks have value outputs and are used to be nested in the value slot of the parent node; The control-type building block contains sub-blocks and / or condition slots for carrying element descriptions of the number of branches, and the main body is a statement-type block sequence.

[0008] In one embodiment, the preset verification conditions include at least one of the following: tool name verification, slot type matching verification, necessary slot integrity verification, and root node type verification. The validity verification of the tree-shaped tool call structure based on preset verification conditions includes at least one of the following: If it is determined that the tool name of each node in the tree-shaped tool call structure exists in the MCP tool registry, then the verification of the tool name is deemed successful. In the tree-shaped tool call structure, if the slot type label of the node is the value slot and the corresponding block type label has the block category of output, or if the slot type label of the node is the statement slot and the corresponding block type label has the block category of statement or control, then the verification of the slot type matching is determined to be successful. If it is determined that the block type label of the node in the tree tool call structure is of the control type and the corresponding necessary slots are filled completely, then the verification of the completeness of the necessary slots is determined to be successful. If, in the tree-shaped tool call structure, the block type label of the root node in the node is determined to be either statement or control type, then the validation of the root node type is deemed successful.

[0009] In one embodiment, after performing legality verification on the tree-shaped tool call structure based on preset verification conditions, the method further includes: If the verification fails, the feedback information for the verification failure is determined. The feedback information includes the path of the node that failed the verification, the corresponding verification conditions that failed, and the expected conditions. The feedback information is sent to the large language model to instruct the large language model to correct the corresponding nodes in the tree-shaped tool call structure based on the feedback information; Obtain the tree-shaped tool call structure after the large language model is corrected, and return to the step of performing legality verification.

[0010] In one embodiment, the predefined connection rules include at least one of the following: For nodes whose block type tag is control type, the XML fragments corresponding to the statement type child nodes under the statement slot of the node are recursively chained into a chain structure through tags, and the entire chain structure is inserted into the statement slot. For nodes whose block type tag is control type, the block XML fragments corresponding to the output type child nodes under the value slot of the node are nested in the value slot; For multiple root nodes whose block type tag is statement, the XML fragments corresponding to the multiple root nodes are concatenated into a program body chain using tags.

[0011] In one embodiment, the bottom-up recursive assembly of the building block XML fragments of each node to obtain a complete building block XML program corresponding to the task description information includes: For leaf nodes, directly return the corresponding leaf node's block XML fragment; For nodes whose block type tag is control type, the corresponding block XML fragment of the child node is inserted into the corresponding slot based on the block type tag of the child node under the node, and the corresponding child element is completed according to Boolean annotation; For the root node, wrap the root node's block XML fragment with a root tag to obtain the corresponding complete block XML program.

[0012] In one embodiment, the step of concurrently calling the corresponding MCP tool for nodes with no dependencies based on the hierarchical relationship between nodes in the tree-shaped tool call structure, to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool, includes: Based on the hierarchical relationship between nodes in the tree-shaped tool call structure, the nodes are topologically sorted to determine the dependencies between them. Concurrently call the corresponding MCP tool for the leaf nodes that have no dependencies in the topological sorting to obtain the block XML fragment and block type tag of the corresponding leaf node returned by the MCP tool; After the leaf node is invoked, the corresponding MCP tool is invoked on the parent node that has a dependency relationship with the leaf node to obtain the block XML fragment and block type tag of the corresponding parent node returned by the MCP tool; If it is determined that the parent node has a parent node above it, and the child node that has a dependency relationship with the parent node has been called, the corresponding MCP tool is called on the parent node to obtain the block XML fragment and block type tag of the parent node returned by the MCP tool, until the call to each node in the tree tool call structure is completed.

[0013] In one embodiment, before invoking the large language model to generate the tree structure, the method further includes: Obtain a registration request for the block atomic operation, and generate the corresponding MCP tool based on the registration request; the registration request includes the tool name, natural language tool description, parameter definition, block type tag and XML template, and the block type tag includes block category, input slot type and structural variation information; Add the MCP tool to the MCP tool registry; the MCP tool registry maintains an index structure, which includes the tool name, block category, input slot type, and structure variation information.

[0014] Secondly, this application also provides a robot block program generation device, the device comprising: The task acquisition module is used to acquire task description information for robot control tasks issued in natural language. The tree structure generation module is used to generate a tree-shaped tool call structure by calling a large language model based on the task description information and a predefined MCP tool registry. The tree-shaped tool call structure is expressed in JSON format, including the tool name of each node, call parameters, hierarchical relationship between nodes, and slot type label. The MCP tool registry includes the tool name of at least one MCP tool and its corresponding natural language tool description. The verification module is used to perform legality verification on the tree-shaped tool call structure based on preset verification conditions; The tool invocation module is used to concurrently invoke the corresponding MCP tool for nodes with no dependency relationship, based on the hierarchical relationship between nodes in the tree-shaped tool invocation structure, after confirming that the verification has passed, so as to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool. The program assembly module is used to recursively assemble the block XML fragments of each node from bottom to top according to the block type tags of each node and predefined connection rules, so as to obtain a complete block XML program corresponding to the task description information.

[0015] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in the first aspect.

[0016] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0017] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect above.

[0018] The aforementioned robot block program generation method, apparatus, computer equipment, computer-readable storage medium, and computer program product completely separate the responsibilities of semantic understanding and structural assembly. Specifically, a large language model is invoked to handle its strength in semantic understanding, outputting a tree-shaped tool call structure that does not contain any XML. Then, based on predefined connection rules that can be precisely executed by code, the final XML program assembly is completed. Since the LLM only needs to output structured JSON, the task complexity is greatly reduced, improving the accuracy of semantic understanding. Furthermore, the XML assembly, based on predefined connection rules, ensures the correctness of the connections. Simultaneously, the parallel tool calls driven by the tree-shaped tool call structure achieve collaborative optimization of generation speed, ultimately outputting a complete block XML program that can be directly imported into a block editor for execution. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a robot block program generation method in one embodiment; Figure 2 This is a flowchart illustrating the legality verification step in one embodiment. Figure 3 This is a flowchart illustrating the tool invocation steps in one embodiment; Figure 4 This is a flowchart illustrating the XML assembly steps in one embodiment; Figure 5 This is a structural block diagram of a robot block program generation device in one embodiment; Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0022] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0023] This application provides a method for generating robot block programs, aiming to solve the problem that traditional technologies, when directly generating XML from large language models, cannot meet the dual requirements of high accuracy and high efficiency due to the simultaneous handling of semantic understanding and structural assembly tasks. The core idea of ​​this embodiment is to completely separate the responsibilities of semantic understanding and structural assembly. Specifically, the large language model is invoked to handle its strength in semantic understanding, outputting a structured intermediate representation (i.e., a tree-like tool call structure) that does not contain any XML. Then, according to predefined connection rules that can be precisely executed by code, the final XML program assembly is completed. This ensures deterministic guarantee of the correctness of the block program connections, while simultaneously optimizing the generation speed through parallel tool calls driven by the tree-like tool call structure. The final output is a complete block XML program that can be directly imported into a block editor for execution.

[0024] In one embodiment, such as Figure 1 As shown, a method for generating robot building block programs is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method may include the following steps: Step 102: Obtain task description information for robot control tasks issued in natural language.

[0025] The task description information can be task instructions for controlling the robot. It can include specific task content and be expressed in natural language. Natural language means that the user describes the task the robot needs to perform using everyday language, industry operating habits, or a combination of both, without requiring adherence to any fixed instruction format or programming syntax rules. For example, the task description information could be a user-issued instruction in natural language such as: "Repeat 3 times: Take 2 steps forward, then check for obstacles ahead; if there is an obstacle, turn left." This instruction is typically used to control the robot's execution.

[0026] For example, the natural language form may include any one or more of the following: text input, voice input, or external system call. The terminal can obtain the task description information input by the user through a human-computer interaction interface for task input. The human-computer interaction interface may be a text input area in a graphical user interface, a voice recognition interface corresponding to a voice input device, or a program interface called by an external business system or scheduling system. For example, text input may be the user directly inputting the task description in natural language through a text input box on the terminal interface; voice input may be the user inputting task instructions through a voice input device, which are then converted into text by voice recognition and transmitted to the terminal; external system call may be the interface called by a higher-level scheduling system, human-computer interaction system, or business system to send the natural language task text to the terminal.

[0027] Step 104: Based on the task description information and the predefined MCP tool registry, call the large language model to generate a tree-shaped tool call structure.

[0028] The MCP (Model Context Protocol) tool registry pre-registers various building block atomic operations (such as forward, loop, conditional judgment, etc.). Each operation is encapsulated as an MCP tool, and each MCP tool has a corresponding description file, including the tool name, natural language tool description, parameter definition, building block type label, and XML template. The building block type label further includes the building block category, acceptable input slot types, and structural variation information.

[0029] In this embodiment, the MCP tool registry can adopt a layered design. The upper layer is the MCP protocol exposure layer, which only provides tool names and natural language tool descriptions to the large language model; the lower layer is the internal metadata layer, which stores metadata required for deterministic assembly, such as block type tags, parameter definitions, and XML templates, and does not expose them to the large language model.

[0030] For example, the tool name is a globally unique identifier used by the large language model when calling the tool; the natural language tool description enables the large language model to understand the applicable scenarios and connection constraints of the tool, and is the basis for the large language model to choose which tool to call; the parameter definition constrains the parameter name, type, and value range passed to the large language model when calling the tool, and is usually in JSON Schema form; the block type tag is used to mark the block category and slot information of the tool, including the block category, acceptable input slot types, and Boolean annotations, so as to be read during the assembly stage, and does not participate in the large language model's calling decision; the XML template is used to define the XML structure of the tool calling block. When the tool is called, the parameter values ​​passed to the large language model are filled into the corresponding placeholders in the template, thereby deterministically generating the XML fragment of the block, without calling the large language model to generate XML content. It should be noted that the XML template of the control block only contains its own block structure and does not contain any child node content. The insertion and connection of child nodes are completed during the assembly stage.

[0031] The building block categories include statement, output, and control types. Statement blocks have predecessor and successor connection nodes for sequential chaining; sibling nodes connect via connections during assembly. <next>Tag links; Output blocks have value outputs and are used to nest in the value slot of the parent node; Control blocks contain child blocks and / or condition slots to carry the number of branches describing the element, and the main body is a sequence of statement blocks.

[0032] Input slot types include value slots and statement slots. In visual block-based programming frameworks like Blockly, value and statement slots are two different types of input connection points used to define how blocks can be nested and combined. The value slot is for receiving the return value of an expression or output block; it generally only accepts output blocks (such as sensor readings, mathematical operations, Boolean judgments, etc.). The statement slot is for receiving a sequence of statement blocks as the execution body; it generally only accepts statement blocks or control blocks (i.e., instructions that can be executed sequentially).

[0033] Structural variation information is used in the Blockly framework to describe the structural variations of a block, such as the data of conditional branches, the number of loops, and whether an else branch is included. This information determines the shape of the block displayed in the editor and the acceptable slot configuration.

[0034] In this embodiment, before invoking the large language model to generate the tree-shaped tool invocation structure, the process further includes: obtaining a registration request for the building block atomic operation; generating the corresponding MCP tool based on the registration request; and adding the MCP tool to the MCP tool registry. The registration request includes the tool name, natural language tool description, parameter definitions, building block type tags, and XML template of the MCP tool to be registered. The building block type tags include the building block category, acceptable input slot types, and structural variation information. The MCP tool registry maintains an index structure that includes the tool name, building block category, input slot type, and structural variation information (such as whether mutation is required).

[0035] For example, taking common building blocks in robot control scenarios as an example, the registration process is as follows: (1) The registration request for statement-type blocks such as move_forward_block includes the following: Tool name: move_forward_block.

[0036] Natural Language Tool Description: Generates a robot forward movement block to control the robot to move forward a specified number of steps. This block is a statement-type block; executing it moves the robot forward. It can be sequentially chained with other statement-type or control-type blocks, but cannot be placed in any value slot.

[0037] Parameter definition (JSON Schema): json { "steps": { "type": "integer", "description": "Number of steps forward", "minimum": 1 } } Block type tags: json { "block_category": "statement", "has_value_slot": false, "has_statement_slot": false } XML template: json { "xml_template": " <block type="move_forward"> <field name="STEPS"> {steps}< / field> < / block> " } The block type label description states that if block_category is "statement", it means the block is a statement-type block and can be assembled. <next>Tag concatenation; has_value_slot being false indicates that the block does not contain any value slots, and there is no need to nest output blocks inside it; has_statement_slot being false indicates that the block does not contain any statement slots, and there is no need to insert statement sequences inside it.

[0038] XML Template Description: When this tool is invoked, it replaces the {steps} placeholders in the template with the actual value of the steps parameter, generating a complete XML fragment. For example, calling move_forward_block(steps=2) returns: <block type="move_forward"> <field name="STEPS"> 2< / field> < / block> (2) The registration request for control blocks such as loop_block includes the following: Tool name: loop_block.

[0039] Natural Language Tool Description: Generates a loop control block that repeatedly executes the sequence of statement blocks in its DO slot a specified number of times. This block is a control block, and the DO slot is used to hold an execution sequence consisting of one or more statement blocks. The number of loops is specified by the count parameter and can be concatenated with other statement blocks.

[0040] Parameter definition (JSON Schema): json { "count": { "type": "integer", "description": "Number of loops", "minimum": 1 } } Block type tags: json { "block_category": "control", "has_value_slot": false, "value_slots": [], "has_statement_slot": true, "statement_slots": ["DO"], "requires_mutation": true, "mutation_template": " <mutation times="{count}" / > " } XML template: json { "xml_template": " <block type="controls_repeat_ext"> <mutation times="{count}" / > < / block> " } The block type label description is as follows: `block_category` being "control" indicates that this block category is a control block. When assembling this node, the list of child nodes under its `statement` slot will be accessed via... <next>Inserting the entire tag after recursive chaining <statement>Tags; `has_value_slot` being false indicates that this block has an unconditional slot and does not require nested output blocks; `statement_slots` being ["DO"] indicates that this block contains a statement sequence slot named DO; `requires_mutation` being true indicates that the XML fragment of this block must carry... <mutation>The element, mutation_template, provides its format template, where {count} is replaced by the actual parameter value when the tool is invoked.

[0041] XML Template Description: When this tool is invoked, it replaces the {count} placeholder in the template with the actual value of the parameter count, generating the XML skeleton fragment of loop_block itself, excluding the child node content of the DO slot. For example, calling loop_block(count=3) returns: <block type="controls_repeat_ext"> <mutation times="3" / > < / block> Among them, the sequence of statement-type child nodes in the DO slot is assembled through... <next>Inserting the entire tag after recursive chaining <statement>Tags are used instead of being processed during the tool invocation phase.

[0042] (3) The registration request for control blocks such as if_block includes the following: Tool name: if_block Tool Description: Generates conditional decision blocks. Based on the return value of the output blocks in the IF slot (representing the condition slot, also known as the value slot, used for asking questions, generally containing output blocks that return true / false), it determines whether to execute the statement sequence in the DO slot (representing the execution body slot, also known as the statement slot, used for performing actions, generally containing a sequence of statement blocks that execute when the condition is true). This block is a control block. The IF slot only accepts output blocks as conditional input, and the DO slot only accepts a sequence of statement blocks as the execution body. Statement blocks cannot be placed in the IF slot, and output blocks cannot be placed in the DO slot.

[0043] Parameter definition: json {} Block type tags: json { "block_category": "control", "has_value_slot": true, "value_slots": ["IF0"], "has_statement_slot": true, "statement_slots": ["DO0"], "requires_mutation": true, "mutation_template": " <mutation elseif="0" else="0" / > " } XML template: json { "xml_template": " <block type="controls_if"> <mutation elseif="0" else="0" / > < / block> " } The block type label description states that `value_slots` being `["IF0"]` indicates that the block contains a condition slot named `IF0`. When assembling this node, the output child nodes under the `IF0` slot will be directly nested within the corresponding condition slot. <value>Within the tag; `statement_slots` being `["DO0"]` indicates that this block contains a statement sequence slot named `DO0`, and during assembly, the list of statement-type child nodes under it will be... <next>Inserting the entire tag after recursive chaining <statement>Label.

[0044] XML template description: `if_block` requires no external parameters. When the tool is called, it directly returns its own XML skeleton fragment, excluding the child node content of slots IF0 and DO0. The returned result is: <block type="controls_if"> <mutation elseif="0" else="0" / > < / block> The output-type child nodes in slot IF0 are directly nested within the corresponding ones during assembly. <value>Within the tag; the sequence of statement-type child nodes within the DO0 slot is passed through <next>Inserting the entire tag after recursive chaining <statement>Tags are not processed during the tool invocation stage.

[0045] (4) The registration request for output type blocks such as obstacle_sensor_block includes the following: Tool name: obstacle_sensor_block Tool Description: Generates an obstacle sensor detection block, returning a Boolean value indicating whether an obstacle exists in front of the robot. This block is an output block and can only be nested in the value slot of its parent block as a conditional input. It cannot appear independently as a top-level statement and cannot be combined with statement blocks. <next>Series connection.

[0046] Parameter definition: json {} Block type tags: json { "block_category": "output", "output_type": "Boolean", "has_value_slot": false, "has_statement_slot": false } XML template: json { "xml_template": " <block type="obstacle_sensor" / > " } XML template description: obstacle_sensor_block requires no external parameters; the tool returns a fixed XML fragment directly when invoked, such as: <block type="obstacle_sensor" / > This fragment is a complete output block XML, containing no slots, and is nested within the parent block during assembly. <value>Within the tag.

[0047] Block type tag description: block_category set to output indicates that this block is an output block. During the assembly phase, when processing the value slot of its parent node, the XML fragment of this block is directly nested within the corresponding... <value>Within the tags, [they] do not participate in any [activities]. <next>Chain operation; output_type is Boolean, indicating that the output value of this block is of Boolean type. During the validity verification stage of the tree tool call structure, it is used to check whether it is placed in the value slot with the matching type.

[0048] After registration, the index structure of the MCP tool registry is generated as shown in Table 1 below: Specifically, when the terminal starts up, it traverses all tool description files through the MCP server, loads the description file of each tool as a function interface that can be called remotely, and maintains an internal mapping index from tool name to function implementation, forming the MCP tool registry.

[0049] The MCP server exposes the tool name, natural language tool description, and parameter definitions in JSON Schema format to the large language model via the MCP protocol. This enables the large language model to identify and select the corresponding tool to generate a tree-like tool call structure. The tree-like tool call structure is expressed in JSON format, including the tool name, call parameters, hierarchical relationship between nodes, and slot type label for each node. In this embodiment, the large language model only needs to understand the semantic purpose of each tool and does not need to be aware of any XML format details; the execution of XML connection rules is completed during the assembly phase. In this embodiment, the large language model can specifically employ ChatGPT, Gemini, or Claude, among others.

[0050] This embodiment achieves the separation of responsibilities between semantic understanding and structural assembly through a hierarchical registry design. The large language model obtains tool names, natural language descriptions, and parameter definitions only through the MCP protocol. The natural language descriptions already contain slot names and slot type descriptions, which the large language model uses to output a tree-shaped tool call structure. The internal fields of the block type tags (including block_category, XML template, mutation_template, and other information required for structural assembly) are not exposed to the large language model through the MCP protocol, but are read directly from the registry during the assembly phase. This design eliminates the XML format memory burden and the join rule reasoning burden of the large language model, transforming the execution of join rules from probabilistic reasoning to deterministic execution of code logic, laying a data foundation for the deterministic guarantee of join correctness.

[0051] For example, the terminal constructs system prompts and calls the large language model to generate a tree-shaped tool call structure based on the preset MCP tool registry and task description information. Taking the registered tool name and natural language tool description mentioned above as an example, if the task description information is "Repeat 3 times: Take 2 steps forward, then check if there is an obstacle ahead, and turn left if there is an obstacle", the constructed system prompt is as follows: [System Prompt] You are a robot block program planning assistant.

[0052] Your sole responsibility is to control the robot according to the user's description of the task. Choose the appropriate tool from the list of tools provided by the MCP server. Output a tree-shaped tool call structure (JSON format).

[0053] And strictly adhere to the following rules: 1. Only JSON can be output; no XML content is allowed. 2. Tool names not listed in the MCP tool list must not be invented. 3. Each node must contain three fields: tool, params, and slots. 4. The slots field describes the child node affiliation of this tool. 5. Output tools can only appear in value type slots. 6. Statement-type tools can only appear in slots of the statement type. 7. The top-level node list can only contain statement or control tools. Output format requirements Output a JSON array, formatted as follows: Single node format: { "tool": "tool name", "params": {"parameter name": parameter value}, "slots": { "Slot Name (Statement Class)": [Node, Node, ...], "Slot Name (Value Class)": Node } } illustrate: - tool: must be the name of a tool in the MCP tool list. - params: Parameters required by the tool; fill in {} if no parameters are specified. - slots: The slots to which child nodes belong; fill in {} if there are no child nodes. - The value of the statement slot is an array (an ordered sequence of statements). - The value in the value slot is a single node object (not an array). - The top-level output is an array, representing the sequence of top-level statements.

Example

[0054] This embodiment reduces the output objective of the large language model from "directly generating XML" to "outputting a JSON tree structure." Since the syntactic complexity of JSON is far lower than that of XML with nested constraints, the output difficulty of the model is significantly reduced; furthermore, since the model does not require memorization... <next>(Used to chain two statement blocks together in sequence, indicating that after the current statement is executed, the next statement will continue to be executed.) <value>(Used to nest output blocks into the value input slot of the parent block, indicating that a value or expression is required here.) <statement>(Used to embed a sequence of statement blocks into the statement slot of the parent block (usually a control block), indicating that an executable sequence of instructions is required here.) <mutation>The rules for using XML tags (used to describe the structural variation information of control blocks, i.e., the shape configuration of the block, such as the number of loops, the number of branches, etc. This information determines how the block is displayed in the editor and the acceptable slot configuration) eliminate errors caused by format memory failure; and the hierarchical expression of tree structure is a strength of LLM. The model only needs to understand the semantic relationship that the loop contains forward and conditional judgments, without needing to understand how XML fragments are concatenated, thus decoupling the semantic understanding task from the structural assembly task.

[0055] Step 106: Perform legality verification on the tree-shaped tool call structure based on preset verification conditions.

[0056] Among these, validity verification is fundamental to ensuring that the model output can directly enter subsequent processes. The preset verification conditions include at least one of the following: tool name verification, slot type matching verification, necessary slot integrity verification, and root node type verification.

[0057] For example, tool name verification can be achieved by checking if the tool field (i.e., tool name) of each node exists in the MCP tool registry; slot type matching verification can be achieved by checking if the slot type of the child node matches its block type; necessary slot integrity verification can be achieved by checking if the control type block fills all declared necessary slots; and root node type verification can be achieved by checking the node types in the root node list.

[0058] In this embodiment, the terminal performs a validity verification on the tree-shaped tool call structure based on preset verification conditions, thereby ensuring that the tree-shaped tool call structure output by the model can directly enter the subsequent process.

[0059] Step 108: If the verification is successful, based on the hierarchical relationship between nodes in the tree tool call structure, concurrently call the corresponding MCP tool for nodes with no dependency relationship to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool.

[0060] In this context, hierarchical relationships refer to the parent-child relationships expressed by nested JSON objects (i.e., nodes) in a tree-like tool call structure. Nodes without dependencies typically refer to the final leaf nodes.

[0061] In this embodiment, after successful verification, the terminal concurrently calls the corresponding MCP tools for nodes with no dependencies based on the hierarchical relationship between nodes in the tree-shaped tool call structure. After each MCP tool is called, it returns an XML fragment of the block itself (excluding child nodes) and its block type tag.

[0062] Step 110: Based on the block type tags of each node, recursively assemble the block XML fragments of each node from bottom to top according to the predefined connection rules to obtain a complete block XML program corresponding to the task description information.

[0063] The connection rules can be predefined strategies for assembling XML fragments corresponding to nodes with different block type tags. For example, for a node whose block type tag is "control," the XML fragments corresponding to the statement-type child nodes under that node can be assembled by... <next>Tags are recursively chained together into a chain structure, and then the entire chain structure is inserted into the statement slot. For block-type tags with control-type nodes, the XML fragments corresponding to the output-type child nodes under the value slot of that node can be directly nested into the corresponding value slot; for multiple root nodes with statement-type blocks, the XML fragments corresponding to each of the multiple root nodes can be nested... <next>The tags are linked together to form the main chain of the program.

[0064] In this embodiment, after calling the MCP tool of each node based on the above steps to obtain the corresponding block XML fragments and block type tags, the XML fragments can be recursively assembled from bottom to top according to the block type tags of each node and the predefined connection rules to obtain a complete block XML program corresponding to the task description information.

[0065] In the aforementioned robot block program generation method, the responsibilities of semantic understanding and structural assembly are completely separated. Specifically, a large language model is invoked to handle its strength in semantic understanding, outputting a tree-shaped tool call structure without any XML. Then, based on predefined connection rules that can be precisely executed by code, the final XML program assembly is completed. Since the LLM only needs to output structured JSON, the task complexity is greatly reduced, improving the accuracy of semantic understanding. The XML assembly, based on predefined connection rules, ensures the correctness of the connections. Simultaneously, the parallel tool calls driven by the tree-shaped tool call structure achieve collaborative optimization of generation speed, ultimately outputting a complete block XML program that can be directly imported into a block editor for execution.

[0066] In an exemplary embodiment, step 106 involves validating the tree-shaped tool call structure based on preset validation conditions, which may specifically include: The tool name verification checks whether the tool field (i.e., the tool name) of each node exists in the MCP tool registry. For example, if it is determined that the tool name of all nodes in the tree tool call structure exists in the MCP tool registry, the tool name verification is considered successful; if the tool name of any node does not exist in the MCP tool registry, the tool name verification is considered unsuccessful.

[0067] The slot type matching validation checks whether the slot type of the child node matches the block type. For example, it's required that the block type label of the node placed in the "value" slot has an output type block, and the block type label of the node placed in the "statement" slot has a statement or control type block. Then, in determining the tree tool call structure, if the node's slot type label is "value" and the corresponding block type label has an output type block, or if the node's slot type label is "statement" and the corresponding block type label has a statement or control type block, then the slot type matching validation passes; otherwise, the slot type matching validation fails.

[0068] The verification of necessary slot integrity checks whether control-type blocks have filled all declared necessary slots. For example, in determining a tree-like tool call structure, if a node's block type label indicates a control type block and all corresponding necessary slots are filled, the verification of necessary slot integrity passes; if a node's block type label indicates a control type block but its corresponding necessary slots are not filled, the verification of necessary slot integrity fails.

[0069] The root node type validation checks the node types in the root node list. Nodes in the root node list must have a block type label indicating a statement or control type. Output nodes are not allowed at the top level. For example, in determining a tree-like tool call structure, if the root node's block type label indicates a statement or control type, the root node type validation passes; if the root node's block type label indicates an output type, the root node type validation fails.

[0070] In one exemplary embodiment, such as Figure 2 As shown, after validating the tree-shaped tool call structure based on preset validation conditions in step 106, the above method may further include: Step 202: If the verification fails, determine the feedback information for the verification failure.

[0071] The feedback information includes the path of the node that failed verification, the corresponding failed verification condition, and the expected condition. Specifically, when an error is found during the validity verification of the tree-shaped tool call structure (such as when a verification condition fails), the terminal can generate feedback information containing the path of the erroneous node, the corresponding verification condition, and the expected condition.

[0072] Step 204: Send feedback information to the large language model.

[0073] Specifically, the terminal can send the aforementioned generated feedback information to the large language model to instruct the large language model to make local corrections to the corresponding nodes in the tree-shaped tool call structure based on the feedback information.

[0074] Step 206: Obtain the tree-shaped tool call structure after the large language model is corrected, and return to the step of performing legality verification.

[0075] For example, if an IF0 slot of an if_block is incorrectly placed into a statement-type block, the feedback generated after the terminal performs validity verification will indicate that the slot type under that node path does not match and expects an output-type block. The terminal sends this feedback to the large language model, instructing it to correct only the specified erroneous node. After the large language model corrects the error, the terminal performs validity verification again on the corrected partial or complete tree-structured tool call structure until the verification passes.

[0076] This embodiment sets up a verification checkpoint before entering the tool invocation stage, pinpointing errors to the node path. The feedback information includes both the expected and actual types, guiding the model for targeted correction and minimizing the cost of error correction. Furthermore, since verification and correction are completed before any MCP tool is invoked, the correction process involves only one lightweight LLM call, eliminating the need to regenerate any XML fragments, significantly improving generation efficiency and success rate for complex tasks.

[0077] In one exemplary embodiment, such as Figure 3 As shown, in step 108, based on the hierarchical relationship between nodes in the tree-structured tool call, the corresponding MCP tool is concurrently called for nodes with no dependencies to obtain the corresponding node's XML fragment and block type tag returned by the MCP tool. Specifically, this may include: Step 302: Based on the hierarchical relationship between nodes in the tree tool call structure, perform topological sorting on each node to determine the dependency relationship between each node.

[0078] In this embodiment, the terminal first performs topological sorting on each node according to the hierarchical relationship between each node in the verified tree tool call structure, so as to determine the dependency relationship between each node.

[0079] Step 304: Concurrently call the corresponding MCP tool for the leaf nodes that have no dependencies in the topological sorting to obtain the block XML fragment and block type tag of the corresponding leaf node returned by the MCP tool.

[0080] Since leaf nodes have no dependencies, they can be executed immediately. Parent nodes, however, must wait for all their child nodes' MCP tool calls to complete before they can execute. Therefore, the terminal can use an asynchronous concurrency mechanism to divide leaf nodes with no dependencies into the same batch, and simultaneously send concurrent requests to the MCP server to call the MCP tools for each leaf node. Each MCP tool independently returns the corresponding leaf node's block XML fragment and block type tag.

[0081] Step 306: After the leaf node is called, the corresponding MCP tool is called on the parent node that has a dependency relationship with the leaf node to obtain the block XML fragment and block type tag of the corresponding parent node returned by the MCP tool.

[0082] Specifically, after the leaf node is invoked, the corresponding MCP tool is invoked on the parent node that has a dependency relationship with the leaf node to obtain the block XML fragment and block type tag of the corresponding parent node returned by the MCP tool.

[0083] Step 308: If it is determined that the parent node has a parent node above it and the child node that has a dependency relationship with the parent node has been called, call the corresponding MCP tool for the parent node above it until the call to each node in the tree tool call structure is completed.

[0084] Specifically, when it is determined that a parent node has a parent node above it, it indicates that the parent node is an intermediate node, meaning it has both child nodes and a parent node above it. After the child nodes that depend on this parent node have completed their calls, the corresponding MCP tool is called on the parent node to obtain the block XML fragment and block type tags returned by the MCP tool, until the calls to each node in the tree-like tool call structure are completed.

[0085] For example, consider the tree-like tool invocation structure corresponding to the task description "Repeat 3 times: advance 2 steps, turn left if an obstacle is detected". The terminal determines the dependencies between nodes by performing topological sorting on the hierarchical relationships between the nodes in the tree-like tool invocation structure, as shown below: loop_block (top-level node, also known as the root node) Dependency → move_forward_block (leaf node, no dependency) Dependency → if_block (intermediate node) Dependency → obstacle_sensor_block (leaf node, no dependency) Dependency → turn_left_block (leaf node, no dependency) Therefore, the nodes in the tree-like tool invocation structure can be divided into three batches for MCP tool invocation. The first batch calls three leaf nodes that have no dependencies simultaneously, the second batch calls the intermediate nodes, and the third batch calls the root node.

[0086] For example, the first batch of calls specifically includes: Call 1: Request: move_forward_block(steps=2) The MCP server executes utility functions, generates XML fragments, and returns: { "xml": " <block type="move_forward"> <field name="STEPS"> 2< / field> < / block> ", "block_category": "statement" } Call 2: Request: obstacle_sensor_block() The MCP server executes utility functions to generate XML fragments. return: { "xml": " <block type="obstacle_sensor" / > ", "block_category": "output", "output_type": "Boolean" } Call 3: Request: turn_left_block(degrees=90) The MCP server executes utility functions to generate XML fragments. return:{ "xml": " <block type="turn_left"> <field name="DEGREES"> 90< / field> < / block> ", "block_category": "statement" } The three calls in the first batch are issued simultaneously, and the total time depends on the slowest single tool call, not the sum of the three. After the first batch is completed, the XML fragments and block type tags of the three leaf nodes are ready and stored in the node result cache. Then, the second batch of calls is made, which calls the MCP tool of the intermediate node if_block.

[0087] Since the leaf nodes `obstacle_sensor_block` and `turn_left_block`, which the intermediate node `if_block` depends on, have both returned results at this point, all dependent nodes of the intermediate node `if_block` are now ready. Therefore, the second batch of nodes `if_block` can be called, as follows: Request: if_block() The MCP server executes utility functions to generate the XML fragment for the if_block itself: return: { "xml": " <block type="controls_if" / > ", "block_category": "control", "has_value_slot": true, "value_slots": ["IF0"], "has_statement_slot": true, "statement_slots": ["DO0"], "requires_mutation": true, "mutation_template": " <mutation elseif="0" else="0" / > " } It should be noted that the MCP tool here only returns the XML skeleton of the if_block itself, without including its child node content. The child node XML fragments are filled in and assembled according to predefined connection rules, thus achieving strict separation between the tool invocation phase and the assembly phase.

[0088] At this point, the leaf nodes move_forward_block and if_block, which the root node loop_block depends on, have both returned results. All dependent nodes of the root node loop_block are now ready, and the third batch of calls to the root node loop_block can then be performed. The specific call is as follows: Request: loop_block(count=3) The MCP server executes utility functions to generate the XML fragment for loop_block itself: return: { "xml": " <block type="controls_repeat_ext" / > ", "block_category": "control", "has_value_slot": false, "value_slots": [], "has_statement_slot": true, "statement_slots": ["DO"], "requires_mutation": true, "mutation_template": " <mutation times="3" / > " } After all the MCP tool calls corresponding to all nodes in the above tree-shaped tool call structure are completed, the node result cache stores the XML fragments and block type tags of all five nodes. The above XML fragments are the skeleton structure of each block itself, and the child node content has not yet been filled in. The insertion and connection of child nodes are assembled according to predefined connection rules.

[0089] This embodiment identifies independent nodes through topological sorting and concurrently calls the corresponding MCP tools, transforming the generation time from being linearly related to the total number of nodes to being related to the depth of the tree structure. The acceleration effect is particularly significant for robot control scenarios with a large number of nodes but shallow nesting levels (i.e., many types of actions with shallow nesting). Simultaneously, each MCP tool only returns the XML skeleton fragment of that block itself, without any child node content, ensuring the atomicity and independence of tool calls. This provides clean input for subsequent deterministic assembly, fundamentally resolving the contradiction between correctness and generation speed.

[0090] In one exemplary embodiment, such as Figure 4 As shown, in step 110, the building block XML fragments of each node are recursively assembled from bottom to top to obtain a complete building block XML program corresponding to the task description information, which may specifically include: Step 402: Process the leaf nodes.

[0091] Understandably, assembly can be performed based on predefined connection rules during the actual assembly process. These connection rules include: for nodes whose block type tag is control-type, the XML fragments corresponding to the statement-type child nodes under that node can be connected via... <next>Tags are recursively chained together into a chain structure, and then the entire chain structure is inserted into the statement slot. For control-type nodes of the block type tag, the block XML fragments corresponding to the output-type child nodes under the value slot of that node can be directly nested into the corresponding value slot. For multiple root nodes of the statement type tag, the block XML fragments corresponding to each of the multiple root nodes can be nested... <next>The tags are linked together to form the main chain of the program.

[0092] In this embodiment, during the bottom-up recursive assembly process, the XML fragments corresponding to the leaf nodes are assembled first. Specifically, for a leaf node, the corresponding XML fragment is directly returned to the tree structure. It can be understood that regardless of whether the leaf node is of type statement, output, or statement, the corresponding XML fragment is directly returned without any additional processing.

[0093] Step 404: Process the control node.

[0094] Specifically, after processing the leaf nodes, the nodes at their parent level are processed. For example, for a node whose block type tag has a control type block category, the corresponding block XML fragments of the child nodes are inserted into the corresponding slots based on the block type tags of the child nodes under that node, and the corresponding child elements are completed using Boolean annotations. For instance, if a control type node has a child node whose block type tag has a statement type block category, the corresponding block XML fragments can be processed according to the order of the child nodes in the tree structure. <next>The tags are chained together to form a chain structure, and then the whole thing is inserted into the parent block. <statement>Within the tag; if the block type tag of a child node under a control node has a block type of output child node, then the block XML fragment of that child node will be directly nested within the corresponding parent block. <value>Within the tag.

[0095] For example, taking the above embodiment as an example, first process the three leaf nodes move_forward_block (statement type), obstacle_sensor_block (output type), and turn_left_block (statement type), and directly return the corresponding leaf node's block XML fragment.

[0096] Then, the intermediate node `if_block` is processed. First, the block type tag of the `if_block` node is read to determine that its IF0 slot is of type `value` and its DO0 slot is of type `statement`. Since the child node `obstacle_sensor_block` under this node `if_block` is of type `output` and `turn_left_block` is of type `statement`, the XML fragment of its child node `obstacle_sensor_block` is nested within... <value name="IF0">Within the tag; place the XML fragment of its child node turn_left_block within the tag. <statement name="DO0">Within the tag; and complete according to the requirements_mutation annotation. <mutation>element.

[0097] Next, the parent node of `loop_block` is processed. First, the block type tag of the `loop_block` node is read, revealing that its DO slot is of type `statement`. Since the child nodes `move_forward_block` (statement type) and `if_block` (control type) under `loop_block`, the XML fragments of its child nodes `move_forward_block` and `if_block` are processed according to the order in the tree structure. <next>After the tags are linked together, they are placed in <statement name="DO">Within the tags; and complete. <mutation>element.

[0098] Step 406: Process the root node.

[0099] Finally, the root node is processed. Specifically, for the root node, its block XML fragment is processed as follows: <xml>Wrapped in a root tag, this outputs the final complete block XML program. The final output XML program is shown below: <xml xmlns ="https: / / developers.google.com / blockly / xml"> <block type =="controls_repeat_ext"> <mutation times =3" / > <statement name =DO"> <block type =move_forward"> <field name 2 <next> <block type ="controls_if"> <mutation elseif ="0" else ="0" / > <value name ="IF0"> <block type ="obstacle_sensor" / > < / next> < / xml> < / mutation> < / statement> < / next> < / mutation> < / statement> < / value> <statement name =DO0"> <block type =="turn_left" / > < / value> < / statement> < / next> < / next> < / next> < / next> < / next> < / mutation> < / statement> This embodiment ensures the structural correctness of the final generated XML by removing the deterministic rule of block connection from the probabilistic LLM, so that it can be directly parsed and executed by the block editor, thus achieving a deterministic guarantee of connection correctness.

[0100] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0101] Based on the same inventive concept, this application also provides an apparatus for implementing the robot block program generation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more apparatus embodiments provided below can be found in the limitations of the method described above, and will not be repeated here.

[0102] In one exemplary embodiment, such as Figure 5 As shown, a robot block program generation device is provided, including: a task acquisition module 502, a tree structure generation module 504, a verification module 506, a tool calling module 508, and a program assembly module 510, wherein: The task acquisition module 502 is used to acquire task description information for robot control tasks issued in natural language. The tree structure generation module 504 is used to generate a tree-shaped tool call structure by calling a large language model based on the task description information and a predefined MCP tool registry. The tree-shaped tool call structure is expressed in JSON format, including the tool name, call parameters, hierarchical relationship between nodes, and slot type label for each node. The MCP tool registry includes the tool name and corresponding natural language tool description of at least one MCP tool. The verification module 506 is used to perform legality verification on the tree-shaped tool call structure based on preset verification conditions; The tool invocation module 508 is used to concurrently invoke the corresponding MCP tool for nodes with no dependency relationship according to the hierarchical relationship between nodes in the tree-shaped tool invocation structure when the verification is confirmed to be successful, so as to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool. The program assembly module 510 is used to recursively assemble the block XML fragments of each node from bottom to top according to the block type tags of each node and predefined connection rules to obtain a complete block XML program corresponding to the task description information.

[0103] In an exemplary embodiment, the block type label includes statement type, output type, and control type blocks; the statement type blocks have predecessor connection nodes and successor connection nodes for sequential chaining, and sibling nodes are linked by labels during assembly; the output type blocks have value outputs for nesting in the value slot of the parent node; the control type blocks contain sub-blocks and / or condition slots for carrying element descriptions of the number of branches, and the main body is a sequence of statement type blocks.

[0104] In an exemplary embodiment, the preset verification conditions include at least one of tool name verification, slot type matching verification, necessary slot integrity verification, and root node type verification; the verification module is further configured to: determine that the tool name verification is passed when it is determined that the tool name of each node in the tree tool call structure exists in the MCP tool registry; determine that the slot type matching verification is passed when it is determined that in the tree tool call structure, the slot type label of the node is the value slot and the corresponding block type label's block category is output, or the slot type label of the node is the statement slot and the corresponding block type label's block category is statement or control; determine that the necessary slot integrity verification is passed when it is determined that in the tree tool call structure, the block type label of the node's block category is control and the corresponding necessary slot is filled completely; and determine that the root node type verification is passed when it is determined that in the tree tool call structure, the block type label's block category of the root node is statement or control.

[0105] In an exemplary embodiment, the verification module is further configured to: determine feedback information indicating that the verification has failed, wherein the feedback information includes the path of the node that failed the verification, the corresponding verification condition that failed, and the expected condition; send the feedback information to the large language model to instruct the large language model to correct the corresponding node in the tree-shaped tool call structure according to the feedback information; obtain the tree-shaped tool call structure corrected by the large language model, and return it for legality verification.

[0106] In one exemplary embodiment, the predefined connection rules include at least one of the following: For nodes whose block type tag is control type, the XML fragments corresponding to the statement type child nodes under the statement slot of the node are recursively chained into a chain structure through tags, and the entire chain structure is inserted into the statement slot. For nodes whose block type tag is control type, the block XML fragments corresponding to the output type child nodes under the value slot of the node are nested in the value slot; For multiple root nodes whose block type tag is statement, the XML fragments corresponding to the multiple root nodes are concatenated into a program body chain using tags.

[0107] In an exemplary embodiment, the program assembly module is further configured to: for leaf nodes, directly return the corresponding leaf node's block XML fragment; for nodes whose block type tag has a control type, insert the block XML fragment corresponding to the child node into the corresponding slot based on the block type tag of the child node under the node, and complete the corresponding child element according to Boolean annotation; for root nodes, wrap the root node's block XML fragment with a root tag to obtain the corresponding complete block XML program.

[0108] In one exemplary embodiment, the tool invocation module is further configured to: Based on the hierarchical relationship between nodes in the tree-shaped tool call structure, the nodes are topologically sorted to determine the dependencies between them. Concurrently call the corresponding MCP tool for the leaf nodes that have no dependencies in the topological sorting to obtain the block XML fragment and block type tag of the corresponding leaf node returned by the MCP tool; After the leaf node is invoked, the corresponding MCP tool is invoked on the parent node that has a dependency relationship with the leaf node to obtain the block XML fragment and block type tag of the corresponding parent node returned by the MCP tool; If it is determined that the parent node has a parent node above it, and the child node that has a dependency relationship with the parent node has been called, the corresponding MCP tool is called on the parent node to obtain the block XML fragment and block type tag of the parent node returned by the MCP tool, until the call to each node in the tree tool call structure is completed.

[0109] In one exemplary embodiment, the apparatus further includes a registry generation module for: Obtain a registration request for the block atomic operation, and generate the corresponding MCP tool based on the registration request; the registration request includes the tool name, natural language tool description, parameter definition, block type tag and XML template, and the block type tag includes block category, input slot type and structural variation information; Add the MCP tool to the MCP tool registry; the MCP tool registry maintains an index structure, which includes the tool name, block category, input slot type, and structure variation information.

[0110] Each module in the aforementioned robot block program generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0111] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a method for generating robot building blocks. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0112] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0113] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0114] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0115] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0116] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0117] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0118] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0119] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.< / value> < / next> < / next> < / value> < / value> < / next> < / statement> < / next> < / value> < / statement> < / next> < / value> < / statement> < / next> < / mutation> < / statement> < / next> < / next> < / next>

Claims

1. A method for generating robot building block programs, characterized in that, The method includes: Obtain task description information for robot control tasks issued in natural language format; Based on the task description information and the predefined MCP tool registry, a tree-shaped tool call structure is generated by calling the large language model; the tree-shaped tool call structure is expressed in JSON format, including the tool name of each node, call parameters, hierarchical relationship between nodes, and slot type label; the MCP tool registry includes the tool name of at least one MCP tool and its corresponding natural language tool description; The validity of the tree-shaped tool call structure is verified based on preset verification conditions; If the verification is successful, based on the hierarchical relationship between nodes in the tree-shaped tool call structure, the corresponding MCP tool is called concurrently for nodes with no dependencies to obtain the corresponding node's block XML fragment and block type tag returned by the MCP tool. Based on the block type tags of each node, the block XML fragments of each node are recursively assembled from bottom to top according to predefined connection rules to obtain a complete block XML program corresponding to the task description information.

2. The method according to claim 1, characterized in that, The block type labels include statement type, output type, and control type. The statement-type building blocks have predecessor connection nodes and successor connection nodes for sequential chaining, and sibling nodes are linked by tags during assembly; The output-type blocks have value outputs and are used to be nested in the value slot of the parent node; The control-type building block contains sub-blocks and / or condition slots for carrying element descriptions of the number of branches, and the main body is a statement-type block sequence.

3. The method according to claim 2, characterized in that, The preset verification conditions include at least one of the following: tool name verification, slot type matching verification, necessary slot integrity verification, and root node type verification. The validity verification of the tree-shaped tool call structure based on preset verification conditions includes at least one of the following: If it is determined that the tool name of each node in the tree-shaped tool call structure exists in the MCP tool registry, then the verification of the tool name is deemed successful. In the tree-shaped tool call structure, if the slot type label of the node is the value slot and the corresponding block type label has the block category of output, or if the slot type label of the node is the statement slot and the corresponding block type label has the block category of statement or control, then the verification of the slot type matching is determined to be successful. If it is determined that the block type label of the node in the tree tool call structure is of the control type and the corresponding necessary slots are filled completely, then the verification of the completeness of the necessary slots is determined to be successful. If, in the tree-shaped tool call structure, the block type label of the root node in the node is determined to be either statement or control type, then the validation of the root node type is deemed successful.

4. The method according to claim 3, characterized in that, After performing legality verification on the tree-shaped tool call structure based on preset verification conditions, the method further includes: If the verification fails, the feedback information for the verification failure is determined. The feedback information includes the path of the node that failed the verification, the corresponding verification conditions that failed, and the expected conditions. The feedback information is sent to the large language model to instruct the large language model to correct the corresponding nodes in the tree-shaped tool call structure based on the feedback information; Obtain the tree-shaped tool call structure after the large language model is corrected, and return to the step of performing legality verification.

5. The method according to claim 2, characterized in that, The predefined connection rules include at least one of the following: For nodes whose block type tag is control type, the XML fragments corresponding to the statement type child nodes under the statement slot of the node are recursively chained into a chain structure through tags, and the entire chain structure is inserted into the statement slot. For nodes whose block type tag is control type, the block XML fragments corresponding to the output type child nodes under the value slot of the node are nested in the value slot; For multiple root nodes whose block type tag is statement, the XML fragments corresponding to the multiple root nodes are concatenated into a program body chain using tags.

6. The method according to claim 5, characterized in that, The bottom-up recursive assembly of the building block XML fragments of each node yields a complete building block XML program corresponding to the task description information, including: For leaf nodes, directly return the corresponding leaf node's block XML fragment; For nodes whose block type tag is control type, the corresponding block XML fragment of the child node is inserted into the corresponding slot based on the block type tag of the child node under the node, and the corresponding child element is completed according to Boolean annotation; For the root node, wrap the root node's block XML fragment with a root tag to obtain the corresponding complete block XML program.

7. The method according to any one of claims 1 to 6, characterized in that, The step of concurrently calling the corresponding MCP tool for nodes with no dependencies based on the hierarchical relationship between nodes in the tree-shaped tool call structure, to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool, includes: Based on the hierarchical relationship between nodes in the tree-shaped tool call structure, the nodes are topologically sorted to determine the dependencies between them. Concurrently call the corresponding MCP tool for the leaf nodes that have no dependencies in the topological sorting to obtain the block XML fragment and block type tag of the corresponding leaf node returned by the MCP tool; After the leaf node is invoked, the corresponding MCP tool is invoked on the parent node that has a dependency relationship with the leaf node to obtain the block XML fragment and block type tag of the corresponding parent node returned by the MCP tool; If it is determined that the parent node has a parent node above it, and the child node that has a dependency relationship with the parent node has been called, the corresponding MCP tool is called on the parent node to obtain the block XML fragment and block type tag of the parent node returned by the MCP tool, until the call to each node in the tree tool call structure is completed.

8. The method according to any one of claims 1 to 6, characterized in that, Before invoking the tree-shaped tool for generating large language models, the method further includes: Obtain a registration request for the block atomic operation, and generate the corresponding MCP tool based on the registration request; the registration request includes the tool name, natural language tool description, parameter definition, block type tag and XML template, and the block type tag includes block category, input slot type and structural variation information; Add the MCP tool to the MCP tool registry; the MCP tool registry maintains an index structure, which includes the tool name, block category, input slot type, and structure variation information.

9. A robot block program generation device, characterized in that, The device includes: The task acquisition module is used to acquire task description information for robot control tasks issued in natural language. The tree structure generation module is used to generate a tree-shaped tool call structure by calling a large language model based on the task description information and a predefined MCP tool registry. The tree-shaped tool call structure is expressed in JSON format, including the tool name of each node, call parameters, hierarchical relationship between nodes, and slot type label. The MCP tool registry includes the tool name of at least one MCP tool and its corresponding natural language tool description. The verification module is used to perform legality verification on the tree-shaped tool call structure based on preset verification conditions; The tool invocation module is used to concurrently invoke the corresponding MCP tool for nodes with no dependency relationship, based on the hierarchical relationship between nodes in the tree-shaped tool invocation structure, after confirming that the verification has passed, so as to obtain the block XML fragment and block type tag of the corresponding node returned by the MCP tool. The program assembly module is used to recursively assemble the block XML fragments of each node from bottom to top according to the block type tags of each node and predefined connection rules, so as to obtain a complete block XML program corresponding to the task description information.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

Images