A method and device for triggering a command and control task of an unmanned platform

Abstract

The application provides a method and device for triggering a command and control task of an unmanned platform, wherein a task specification is generated according to a natural language task request; before a task creation tool is called, the calling is suspended, a temporary task is created according to the task specification, a temporary task identifier is obtained, a corresponding task tree is queried, a task semantic snapshot is obtained by normalizing and stably sorting the task tree, and a task tree check value is calculated; an action identifier is generated, and a task card is output; a confirmation trigger decision is received for the card, a check context is retrieved according to the action identifier carried by the decision, a current check value of the task tree corresponding to the temporary task identifier is recalculated according to the same rule; when the current check value is inconsistent with the task tree check value in the check context, the trigger is rejected; when the current check value is consistent with the task tree check value in the check context, an intelligent agent is caused to resume execution from the suspended calling and no longer generate a task specification, the temporary task is converted into a formal task and is issued to a task scheduling system, and the unmanned platform is controlled to perform work according to the task tree.

Description

Technical Field

[0001] This invention relates to the field of unmanned platform mission management technology, and in particular to a method and device for triggering command and control missions of unmanned platforms from the same source. Background Technology

[0002] The unmanned platform task management system needs to create tasks such as patrol, inspection, duty, tracking, monitoring, and disposal based on the operator's intentions. The traditional method relies on form filling, map selection, resource selection, and task type selection to complete task creation. Task parameters are entered manually item by item, and the tasks executed by the system and the tasks entered by the operator are naturally the same data.

[0003] With the introduction of large language model intelligent agent technology, the system is now designed to receive natural language commands (such as "create a patrol task for area A" or "patrol area A first, then take action"). The intelligent agent parses the intent, generates task specifications, and autonomously calls the backend task creation tool. At this point, the generator of task parameters changes from humans to models, and task creation in this scenario is an irreversible operation: once a task is issued, the unmanned platform immediately performs formation, resource allocation, and route execution according to the task tree.

[0004] To control risks, a manual confirmation step is usually introduced into the tool call chain: a natural language summary or task prompt is shown to the operator, who then clicks to confirm before continuing to execute the tool call.

[0005] However, in the task creation chain driven by the large language model agent, there is no machine-verifiable identity binding between the task content verified by the operator during the confirmation phase and the task object ultimately issued and executed by the system. The confirmation phase displays a descriptive content output by the model, oriented towards reading; while the final execution involves task parameters generated by the model through further reasoning after confirmation. These two are separate from two independent model outputs; there is no single task entity within the system that is both displayed and executed. Due to the uncertainty of the output of large language models, especially in multi-hop dependent tasks (the results of previous tasks affect the generation of subsequent tasks, and the number, order and objects of tasks are easily variable), tasks with ambiguous regional boundaries (descriptions such as "nearby" and "along the boundary" cause the scope of the operation to drift), resource-constrained tasks (constraints on the number of equipment, power, load, and flight area lead to conflicting solutions), and quantity-sensitive tasks (the number of sub-tasks and the number of equipment shift) – the semantics of the task can drift seamlessly between the "display point" and the "execution point": the card shows "create 2 patrol sub-tasks for area A", but the actual task issued may be "create 3 sub-tasks for areas A and B".

[0006] As a result, manual verification is formally completed but substantively ineffective: it constrains "whether a certain tool is allowed to be invoked," rather than "which task is ultimately issued." Changes in task semantics cannot be intercepted before issuance or attributed afterward. The system can subsequently verify that the task has been executed, but cannot prove that the task is the one the operator verified. The tool interruption and authorization mechanism provided by the general intelligent agent framework only saves the tool name, tool parameters, and feedback identifier, without carrying task domain context such as temporary task identifiers, task tree structure, work area, and task resources, and therefore cannot provide any evidence for the aforementioned identity.

[0007] In view of the above, this application is hereby submitted. Summary of the Invention

[0008] This invention discloses a method and apparatus for triggering command and control tasks on unmanned platforms from the same source. It aims to solve the problem that in the task issuance of unmanned platforms driven by large language model intelligent agents, the task verified by the user is not from the same source as the actual task issued, which leads to the task semantics drifting after verification and the inability to intercept erroneous tasks.

[0009] The first embodiment of the present invention provides a method for triggering command and control tasks on an unmanned platform from the same source, including: The large language model agent generates task specifications based on the natural language task request. Before calling the task creation tool, suspend the call and create a temporary task with an unconfirmed status according to the task specifications, and obtain the temporary task identifier; Query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot; Generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated based on the task semantic snapshot; Receive a confirmation trigger decision for the task card, the confirmation trigger decision carrying the action identifier; query the associated and saved verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; If the current verification value is inconsistent with the task tree verification value in the verification context, the trigger is rejected; if they are consistent, the agent resumes execution from the suspended call point, and the task specification is not regenerated. Instead, the temporary task corresponding to the temporary task identifier is converted into a formal task and sent to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

[0010] The second embodiment of the present invention provides a co-triggered device for command and control tasks of an unmanned platform, comprising: The task specification generation module is used to generate task specifications by the large language model agent based on natural language task requests. The suspend module is invoked to suspend the call to the task creation tool before it is invoked. A temporary task with an unconfirmed status is created according to the task specifications, and a temporary task identifier is obtained. The snapshot verification module is used to query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot. The verification context module is used to generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated based on the task semantic snapshot; The consistency verification module is used to receive a confirmation trigger decision for the task card, the confirmation trigger decision carrying the action identifier; query the associated and stored verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; The same-source triggering module is used to refuse triggering when the current verification value is inconsistent with the task tree verification value in the verification context; when they are consistent, the agent resumes execution from the suspended call point, and no longer regenerates the task specification, but converts the temporary task corresponding to the temporary task identifier into a formal task and sends it to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

[0011] The third embodiment of the present invention provides a device for triggering unmanned platform command and control tasks from the same source, characterized in that it includes a memory and a processor, wherein the memory stores a computer program, and the computer program can be executed by the processor to implement the method for triggering unmanned platform command and control tasks from the same source as described above.

[0012] The fourth embodiment of the present invention provides a computer-readable storage medium, characterized in that it stores a computer program, which can be executed by the processor of the device where the computer-readable storage medium is located, to implement the unmanned platform command and control task co-triggering method as described in any of the above claims.

[0013] Beneficial effects: Before the task creation tool is executed, its invocation is suspended. A temporary task with an unconfirmed status is first created based on the task specifications. The task card verified by the user and the final issued task both point to the same temporary task identifier. After verification, the agent resumes execution from the suspended invocation point, without regenerating the task specifications. Instead, the same temporary task is changed from an unconfirmed status to a formal task. Thus, what the user sees is what the system issues, fundamentally eliminating the semantic drift caused by "secondary inference of task parameters by a large model after confirmation," and preventing deviations in key parameters such as the number of subtasks, work area, and task resources between verification and issuance.

[0014] After normalizing and stabilizing the task tree of temporary tasks, a task semantic snapshot is generated, and a task tree checksum is calculated. This ensures that the same temporary task has a consistent semantic structure and checksum when the task semantics remain unchanged. Before deployment, the verification context is retrieved based on the action identifier, and the current checksum is recalculated according to the same rules and compared with the current checksum. If the two values ​​are inconsistent, it is determined that the task semantics have changed and the task is rejected. Compared with methods that only display natural language summaries or only verify "whether tool calls are allowed", this method provides a definite data basis for verification before task deployment. If the task tree is modified by external processes during verification (such as adding subtasks, changing the work area, or replacing task resources), it can be automatically intercepted, reducing the risk of erroneous task deployment on unmanned platforms. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating a method for triggering command and control tasks on an unmanned platform according to the first embodiment of the present invention. Figure 2 This is a schematic diagram of a module of a co-source triggering device for command and control tasks of an unmanned platform provided in the second embodiment of the present invention. Detailed Implementation

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

[0017] To better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0018] This invention discloses a method and apparatus for triggering command and control tasks on unmanned platforms from the same source. It aims to solve the problem that in the task issuance of unmanned platforms driven by large language model intelligent agents, the task verified by the user is not from the same source as the actual task issued, which leads to the task semantics drifting after verification and the inability to intercept erroneous tasks.

[0019] Please see Figure 1 The first embodiment of the present invention provides a method for triggering command and control tasks on an unmanned platform, which can be executed by a triggering device (hereinafter referred to as a system), and in particular by one or more processors within the triggering device, to at least implement the following steps: S101, the large language model agent generates the task specifications based on the natural language task request; The unmanned platform task management system's session service receives natural language task requests input by operators through the human-machine interface, such as "create a patrol task for area A" or "patrol area A first, then create a disposal task based on the patrol results." Simultaneously, the session service receives the session identifier of the current interaction and the work area information provided by the map component in the interface. Furthermore, the session service can also receive auxiliary information such as files and images submitted by the operator along with the request. The work area information is structured data output by the map component based on the operator's selection, point selection, or area search operations. It includes the area name, the set of area boundary points, the area center point, and the area type. The set of area boundary points is a set of coordinate points that constitute the outline of the work area; the area center point represents the geometric center of the work area; and the area type represents whether the work area is a no-fly zone, a work area, or an observation area, etc.

[0020] The session service retrieves the agent input context corresponding to the session identifier from the session storage. This input context records historical requests, responses, and actions generated in previous rounds of interaction within the session. The session service then writes the received natural language task request and task area information into the agent input context. The task area information is written in structured data format, meaning it is transmitted as independent context fields for the region name, region boundary point set, region center point, and region type, rather than being concatenated into natural language text and then incorporated into the request statement. This structured data format allows the large language model agent to directly reference the original region data provided by the map component when generating task specifications, avoiding task area deviations caused by coordinate accuracy loss, region name ambiguity, or missing boundary points during natural language concatenation and re-parsing.

[0021] The large language model agent reads the input context, parses the operator's intent, and generates a task specification. The task specification includes a task name, task type, work area, sub-task list, and parent-child task relationship. The work area in the task specification includes the set of boundary points of that area; that is, the work area described in the task specification and the set of boundary points provided by the map component use the same coordinate data, without any re-description or re-inference. Taking "inspecting area A first, then creating a disposal task based on the inspection results" as an example, the task specification generated by the agent includes the task name "Composite Task for Area A," the task type is a composite task, the work area is area A with its set of boundary points, the sub-task list includes the area A inspection sub-task and the area A disposal sub-task, and the parent-child task relationship indicates that the two sub-tasks belong to the composite task, and the disposal sub-task depends on the execution result of the inspection sub-task. The generated task specification is output to the agent's tool invocation stage as the basis for creating temporary tasks.

[0022] S102, before calling the task creation tool, suspend the call, create a temporary task with an unconfirmed status according to the task specifications, and obtain the temporary task identifier; The large language model agent initiates a tool call based on the task specifications, preparing to invoke the task creation tool provided by the task system. At this point, the call interception logic running in the agent's execution environment does not allow the call; instead, it first identifies whether the tool identifier of the tool to be invoked belongs to a pre-defined set of tools requiring verification. This set of tools requiring verification pre-registers tool identifiers that will have a practical effect on the unmanned platform, such as formal task creation tools, task distribution tools, and task modification tools; while query and retrieval tools, which do not have a practical effect, are not in this set, and their calls are unaffected. When the system identifies that the tool identifier of the tool to be invoked belongs to the set of tools requiring verification, it determines that the call needs to be verified by the task tree and therefore suspends the call before the task creation tool is actually executed. This suspension is not a refusal to execute, nor is it a rollback after task execution; rather, it puts the agent into a waiting state at the point of the tool call, while simultaneously retaining the call identifier, call parameters, and current session state so that execution can continue from there after verification is successful.

[0023] After suspending the call, the system no longer issues tasks through the task creation tool. Instead, it calls the temporary task creation interface of the task system, uses the generated task specifications as input parameters, creates a temporary task corresponding to those specifications, and sets the task status of the temporary task to unconfirmed. The interface returns the temporary task identifier (taskId). The temporary task has the same task tree structure as the formal task in the task system, including main tasks, sub-tasks, parent-child task relationships, work areas, and resource allocation relationships. Therefore, it accurately reflects the actual task organization if the task were issued. However, because its task status is unconfirmed, the task system's scheduling chain isolates it from the formal task. Specifically, during the unconfirmed period, the temporary task is only used to generate the necessary task tree and task cards. The task system will not trigger actual resource occupation or locking for it; for example, it will not set the equipment to an occupied state, reserve power and payload, apply for flight areas, or issue the temporary task to the task scheduling system. Therefore, it will not cause any actual action by the unmanned platform. In other words, the temporary task at this stage is a task object that exists only within the task system, can be queried and displayed, but cannot be executed.

[0024] It should be noted that the temporary task is not merely a text copy or preview snapshot for display, but a real task object implemented in the task system. Its temporary task identifier (taskId) will be used to query the task tree in step S103, saved as part of the verification context in step S104, and used as the sole basis for issuing the formal task in step S106. Because the task card verified by the operator and the finally issued formal task are both derived from the temporary task pointed to by the same taskId, they share a common origin. This is also why this embodiment creates the temporary task first, rather than regenerating the task parameters from the large language model after user confirmation.

[0025] S103, query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot; In this embodiment, the system uses the returned temporary task identifier (taskId) as input parameter to call the task system's task tree query interface to obtain the complete task tree corresponding to the temporary task. In addition to the basic information of the main task and each subtask, this task tree also includes organizational and constraint information between tasks, as well as the correspondence information between tasks and job resources. The system further abstracts this task tree to construct a task semantic tree: each task in the task tree is a task node; the parent-child relationship, task dependency relationship, execution order relationship, and condition triggering relationship between tasks are used as the association edges between task nodes; and the job area information and resource allocation relationship are used as the node attributes of the corresponding task node. Among them, parent-child relationships represent the subordinate relationship between the main task and its subtasks; task dependency relationships represent whether a task depends on the output or state of another task, such as the disposal subtask depending on the execution result of the patrol subtask; execution order relationships represent the temporal constraints between multiple tasks; condition triggering relationships represent the logical relationship of triggering subsequent tasks after a preset condition is met during task execution; work area information represents the work scope corresponding to the task node and its set of boundary points; and resource allocation relationships represent the correspondence between patrol resources, disposal resources, other execution resources, and the task node. After this abstraction, all the information in the task tree that carries the meaning of task execution is organized into a deterministic data structure expressed by nodes, edges, and node attributes, providing a unified basis for subsequent comparisons.

[0026] Subsequently, the system normalizes the task semantic tree to obtain a normalized task semantic tree. Normalization essentially filters out information irrelevant to task execution from the task semantic tree, retaining only fields that determine how the task is executed: task identifier, task type, task execution parameters, parent-child relationships, task dependencies, execution order relationships, conditional trigger relationships, job area information, and resource allocation relationships. It removes information that does not participate in the task execution logic, such as task creation time, task update time, operator display information, task card display text, and interface style information. This processing is necessary because the update time and display text of temporary tasks may change during querying and display. If these changes are included in the verification scope, even if the execution meaning of the task itself remains unchanged, the verification value will change, leading to a large number of meaningless verification failures. Conversely, if task execution parameters, job area, or resource allocation relationships are omitted from the verification scope, substantial changes in the task content will be missed.

[0027] Based on this, the system performs stable sorting on the normalized task semantic tree: task nodes are sorted according to task level, and task nodes within the same task level are sorted according to task identifier; the job area in the node attributes is sorted according to the area identifier, the resource list is sorted according to the resource type and resource identifier; and the associated edges are sorted according to the associated edge type and the task identifier of the task node it connects to. The problem that stable sorting aims to solve is that the order of subtasks, resource items, and associated edges in the task tree returned by the task system at different times may differ due to differences in database query plans, cache hits, or serialization implementations. If the verification value is calculated directly without sorting, the verification values ​​obtained by the same temporary task may be different even if the semantics remain completely unchanged, and the consistency check will lose its meaning. After the above stable sorting, the same temporary task can always generate a consistent normalized semantic structure when its task semantics have not changed. It should be noted that the goal here is not to make any two semantically identical tasks in the world have the same structure, but to ensure the comparability of the same temporary task before and after verification, which is consistent with the technical purpose of this method: "to determine whether the task verified by the user has changed before it was issued."

[0028] Finally, the system serializes the stable sorted normalized task semantic tree to obtain a task semantic snapshot. Before serialization, the system first performs encoding normalization: Structured fields are arranged according to a predetermined key order to avoid different byte sequences for the same object due to different field writing orders; numeric fields are truncated according to a predetermined precision to avoid differences in the representation of floating-point numbers under different operating environments, especially the slight jitter of work area coordinates under different precisions; unordered sets are sorted according to a predetermined sorting key and duplicates are removed, such as the same resource item appearing due to repeated writing in the resource list; the set of region boundary points in the work area information is rearranged according to a predetermined starting point and predetermined bypass direction, because the same polygonal region can be expressed by different starting points and different bypass directions. For example, A, B, C, D and B, C, D, A are actually the same region, and if they are not rearranged, completely different check values ​​will be calculated; finally, the normalized task semantic tree processed above is serialized according to a unified character encoding (such as UTF-8) to obtain a task semantic snapshot in byte sequence form. The system calculates a digest of the task semantic snapshot to obtain the task tree verification value, taskTreeHash, for example, using the SHA-256 digest algorithm. At this point, a task semantic snapshot and its task tree verification value, which are both readable and displayable by humans and can be accurately compared by machines, are generated.

[0029] S104, Generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated according to the task semantic snapshot; In this embodiment, the system generates a globally unique action identifier (actionId) for the task to be verified. This action identifier is used to uniquely identify the same action to be verified in subsequent stages of display, decision-making, verification, and issuance. The system then constructs a verification context, using the temporary task identifier (taskId) and the task tree verification value (taskTreeHash) as essential content, and saves them in association with the action identifier. In a preferred embodiment, the verification context may also save information such as task semantic snapshot, job area, task type, number of subtasks, and task resource summary, so that the task content displayed at that time can be restored without re-querying the task system during retrospective analysis. The verification context must include both taskId and taskTreeHash because the former determines "which task was issued," and the latter determines "whether the content of the task is still consistent with the content verified by the operator." If either one is missing, the identity judgment relied upon in step S106 cannot be established.

[0030] While preserving the verification context, the system generates task cards based on the task semantic snapshot. The task card is a readable representation of the task semantic snapshot for the operator. Its content is not a natural language summary separately organized by the large language model, but rather directly rendered from the task semantic snapshot, ensuring that the content seen by the operator and the content used in the verification value calculation come from the same data. The task card includes the task name, work area name, work area range, task type, number of subtasks, task resources, and a task tree relationship summary. The work area range can be displayed on the map as an outline of the area. The task tree relationship summary includes the parent-child relationship, task dependency relationship, execution order relationship, condition trigger relationship, and resource allocation relationship represented by the task semantic snapshot. Taking "inspecting area A first, then creating a disposal task based on the inspection results" as an example, the task card will show the main task as a composite task for area A, the number of subtasks as two, namely, an inspection subtask for area A and a disposal subtask for area A, the disposal subtask depending on the execution result of the inspection subtask, the work area as area A and its outline, and the task resources as the corresponding inspection resources and disposal resources. Compared to a simple natural language prompt asking "Create patrol task?", the structured content above allows operators to verify that the task has been broken down into several sub-tasks, which work area each sub-task falls into, what their order and dependencies are, and which resources are called respectively. This provides the actual means to discover errors in task breakdown, work area selection, or resource selection.

[0031] The system writes the action identifier into the task card, binding the card to the action to be verified, and outputs the task card to the front end in a streaming manner along with the agent's response and reasoning content. The message type of the task card is marked as the action type to be verified. The front end renders it as a card with two operation entries: "Continue Trigger" and "Cancel". The operator's confirmation trigger decision or cancellation decision for the task card will be sent back to the system along with the action identifier bound to the card. In the streaming output scenario, the response text, reasoning content, tool call results, and task card may be sent to the front end in blocks. The existence of the action identifier ensures that each data block can be clearly attributed to the same action to be verified, preventing mismatches in multiple rounds of conversation.

[0032] Simultaneously, the system sets the action status corresponding to the action identifier to "pending verification" and writes the action identifier, action status, and task card into the session history corresponding to the session identifier, making this action pending verification a searchable, recoverable, and traceable record in the session. Subsequently, if the operator finds that the work area is incorrect, the number of subtasks does not match their intention, or the resource selection is wrong when viewing the task card, they can click "Cancel." After receiving the cancellation decision carrying the action identifier, the system updates the action status to "Canceled" and does not convert the temporary task into a formal task. The temporary task remains in an unconfirmed state and will not trigger any actual action from the unmanned platform. During subsequent auditing, the complete record can still be found in the session history that this session generated the task card, the operator canceled it, and no formal task was issued. Conversely, if the consistency verification in subsequent step S106 passes, the temporary task is converted into a formal task and issued to the task scheduling system, the system updates the action status to "Verification Passed." The persistence of the above-mentioned action states ensures that each scenario, such as triggering, canceling, re-triggering, and session resumption, has a clear state affiliation, thus avoiding state confusion in multi-turn sessions.

[0033] S105, receive a confirmation trigger decision for the task card, the confirmation trigger decision carrying the action identifier; query the associated and stored verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; In this embodiment, the operator views the task card on the front end and verifies whether the displayed task name, work area, task type, number of subtasks, task resources, and task tree relationship summary match their true intention. If everything is correct, the operator clicks the "Continue Trigger" entry on the card. Based on this, the front end initiates a confirmation trigger decision for the task card to the system. This confirmation trigger decision carries the action identifier (actionId) bound to the card, as well as the session identifier for this session. It is important to emphasize that the confirmation trigger decision only carries the action identifier and session identifier, and does not contain any task parameters. The front end does not send back task specifications or task tree content, thus preventing the task content from being tampered with or regenerated during the front-end and back-end back-end communication at the protocol level.

[0034] Upon receiving the confirmation trigger decision, the system retrieves the verification context associated with the action identifier from the session history based on the session identifier and action identifier, and extracts the temporary task identifier (taskId) and the task tree verification value (taskTreeHash). If the verification context is not found, or if it is found but lacks a temporary task identifier or a task tree verification value (e.g., due to session expiration, storage anomaly, action record cleanup, or the front end sending back a non-existent action identifier), the system must not continue the current distribution process in any way. It is not allowed to re-invoke the large language model to generate the task specification to fill in the missing task content, nor is it allowed to bypass the consistency check and directly convert a temporary task into a formal task. Instead, the system terminates the current process and outputs a message indicating a missing verification context to the front end, prompting the operator to re-initiate the task creation request. This strict limitation is necessary because if task parameters are regenerated when the verification context is missing, the newly generated task will no longer originate from the task previously verified by the operator on the task card, creating a gap in the consistency guarantee that this method aims to ensure. Conversely, allowing deployment without a task tree verification value is equivalent to abandoning the assessment of whether the task content has changed, resulting in the deployment of a task with uncertain content. Therefore, the complete existence of the verification context is a prerequisite for this method to continue the deployment process.

[0035] After successfully obtaining the verification context, the system uses the temporary task identifier `taskId` as input to re-invoke the task tree query interface of the task system, retrieves the task tree corresponding to the temporary task, and processes it according to the same rules: abstracting it into a task semantic tree in the same way, performing the same normalization to filter out fields that do not participate in the task execution logic, performing the same stable sorting, performing the same encoding normalization and serialization, obtaining the current task semantic snapshot, and using the same digest algorithm to calculate the current verification value. Since the rules for normalization, stable sorting, and encoding normalization are consistent in both calculations, when the task semantics of the temporary task have not changed, the current verification value obtained will necessarily be the same as the `taskTreeHash` stored in the verification context; conversely, if the temporary task is modified by other processes during the period from the time the task card is displayed to the time the operator confirms it, such as adding or deleting subtasks, changing the boundary point set of the work area, replacing the allocated task resources, or adjusting the dependencies and execution order between subtasks, the current verification value obtained will necessarily be different from `taskTreeHash`.

[0036] S106, if the current verification value is inconsistent with the task tree verification value in the verification context, the trigger is rejected; if they are consistent, the agent resumes execution from the suspended call point, and the task specification is not regenerated. Instead, the temporary task corresponding to the temporary task identifier is converted into a formal task and sent to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

[0037] The system compares the current verification value with the task tree verification value taskTreeHash stored in the verification context, and divides it into two mutually exclusive processing paths based on the comparison result.

[0038] When the two are inconsistent, it indicates that the task semantics of the temporary task have changed between the time the task card is displayed and the time the operator confirms it. The task confirmed by the operator at this moment is no longer the one the system is about to issue. In this case, the system refuses to trigger: it does not convert the temporary task into a formal task, does not issue any content to the task scheduling system, and terminates the resumption of execution of the agent, keeping it stuck at the suspended call point without allowing it to proceed; at the same time, the system updates the action status corresponding to the action identifier to verification failure and takes this status as the final state of the action identifier. After this, the action identifier can no longer be used in any issuance process, thus eliminating the possibility of replaying a changed task with the old action identifier. To ensure operators can continue task assignment after being aware of the changes, the system re-queries the task tree corresponding to the temporary task based on the same temporary task identifier (taskId). It then generates a new task semantic snapshot according to the same normalization, stable sorting, encoding normalization, and serialization rules as in step S103, and calculates a new task tree verification value. Subsequently, a new action identifier is generated, and the temporary task identifier and the new task tree verification value are associated and saved as a new verification context. A new task card carrying the new action identifier is generated based on the new task semantic snapshot and output to the front end, while simultaneously prompting the operator that the task content has changed and requesting re-verification. The reason for generating a new action identifier and a new verification context, rather than using the original action identifier or directly overwriting the original verification context with the new verification value, is that the former would cause the operator to click confirm again, still using the old taskTreeHash for comparison, inevitably leading to another verification failure and an infinite loop where task assignment cannot be completed. The latter would cause an action identifier previously bound to old task content to be bound to new task content, disrupting the one-to-one correspondence between the action identifier and its displayed content. After the operator re-verifies and confirms the new task card, the process returns to step S105, retrieves the new verification context with the new action identifier, and re-verifies.

[0039] When the two match, it indicates that the semantics of the temporary task have not changed since the task card was generated, and the operator is verifying the task that the system is about to issue. The system then enters the resumption execution and same-source issuance process. The system first queries the execution snapshot saved during the suspended call in step S102 based on the session identifier and the temporary task identifier. This execution snapshot includes the session identifier, execution node identifier, suspended tool identifier, and suspended tool call context, and is stored in association with the temporary task identifier. Based on this, the system reconstructs the agent's resumption execution environment, writing the temporary task identifier (taskId) and the verified task tree checksum (taskTreeHash) as structured parameters into the resumption execution context, instead of relaying the result "user confirmed" to the large language model in a natural language prompt. Otherwise, the confirmed task content would be re-introduced through model reasoning, thus reintroducing the task semantic drift that this method aims to prevent. Subsequently, the system locates the agent's execution state to the execution node corresponding to the execution node identifier and uses the resumption execution context as input to that execution node, causing the suspended task creation tool to resume execution from that point.

[0040] The task creation tool, after resuming execution, behaves differently from its initial call: its context now directly carries the taskId and taskTreeHash, thus no longer triggering the large language model to regenerate task specifications or re-parse the operator's natural language request. Instead, it directly retrieves the temporary task based on the taskId, changes its status from unconfirmed to formal, and obtains the formal task. Only after this formal status is achieved does the task system actually occupy and lock the execution resources for the task, and then distributes the formal task along with its task tree to the task scheduling system. The task scheduling system then controls the corresponding unmanned platform to execute the task in the corresponding work area according to the parent-child relationships, task dependencies, execution order, and conditional triggering relationships in the task tree. Taking "inspecting area A first, and then creating a disposal task based on the inspection results" as an example, the task scheduling system first schedules inspection resources to execute the inspection sub-task for area A based on the task tree. Once the execution results meet the set conditions, the disposal sub-task is then triggered. At this point, the composite task tree verified by the operator on the task card and the task tree that is finally issued and executed point to the same task object uniquely identified by taskId and have completely identical content, demonstrating their common origin. After the task is issued, the system updates the action status corresponding to the action identifier to "verification passed" and writes the subsequently generated response content, task execution result, and last modified time of the session into the session history. This allows for retrospective tracking of which task tree the system displayed during the session, whether the consistency verification before issuance passed, and which task was ultimately issued.

[0041] Please see Figure 2The second embodiment of the present invention provides a triggering device for command and control tasks of an unmanned platform, comprising: Task specification generation module 201 is used to generate task specifications by a large language model agent based on a natural language task request. The suspend module 202 is invoked to suspend the call before calling the task creation tool, and to create a temporary task with an unconfirmed status according to the task specifications, thereby obtaining a temporary task identifier; The snapshot verification module 203 is used to query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot. The verification context module 204 is used to generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated according to the task semantic snapshot; The consistency verification module 205 is used to receive a confirmation trigger decision made for the task card, the confirmation trigger decision carrying the action identifier; query the associated and stored verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; The same-source trigger module 206 is used to refuse triggering when the current verification value is inconsistent with the task tree verification value in the verification context; when they are consistent, the agent resumes execution from the suspended call point, and no longer regenerates the task specification, but converts the temporary task corresponding to the temporary task identifier into a formal task and sends it to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

[0042] The third embodiment of the present invention provides a device for triggering unmanned platform command and control tasks from the same source, characterized in that it includes a memory and a processor, wherein the memory stores a computer program, and the computer program can be executed by the processor to implement the method for triggering unmanned platform command and control tasks from the same source as described above.

[0043] The fourth embodiment of the present invention provides a computer-readable storage medium, characterized in that it stores a computer program, which can be executed by the processor of the device where the computer-readable storage medium is located, to implement the unmanned platform command and control task co-triggering method as described in any of the above claims.

[0044] Exemplary examples show that the computer program described in the third and fourth embodiments of the present invention can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the implementation of a command and control mission triggering device for an unmanned platform. For example, the apparatus described in the second embodiment of the present invention.

[0045] The processor referred to can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. This processor is the control center of the aforementioned method for triggering the same source of command and control tasks for unmanned platforms, connecting various parts of the method through various interfaces and lines.

[0046] The memory can be used to store the computer program and / or modules. The processor, by running or executing the computer program and / or modules stored in the memory, and by calling the data stored in the memory, implements various functions of a method for triggering a command and control task on an unmanned platform. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, text conversion function, etc.), etc.; the data storage area may store data created based on the use of the mobile phone (such as audio data, text message data, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0047] If the implemented module is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0048] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0049] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for triggering command and control tasks on an unmanned platform from the same source, characterized in that, include: The large language model agent generates task specifications based on the natural language task request. Before calling the task creation tool, suspend the call and create a temporary task with an unconfirmed status according to the task specifications, and obtain the temporary task identifier; Query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot; Generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated based on the task semantic snapshot; Receive a confirmation trigger decision for the task card, the confirmation trigger decision carrying the action identifier; query the associated and saved verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; If the current verification value is inconsistent with the task tree verification value in the verification context, the trigger is rejected; if they are consistent, the agent resumes execution from the suspended call point, and the task specification is not regenerated. Instead, the temporary task corresponding to the temporary task identifier is converted into a formal task and sent to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

2. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The process of generating task specifications by the large language model agent based on the natural language task request is as follows: The system receives the natural language task request, a session identifier, and work area information provided by the map component. The work area information includes the area name, the set of area boundary points, the area center point, and the area type. Obtain the corresponding agent input context based on the session identifier, and write the work area information into the agent input context in the form of structured data; The task specification is generated by the agent based on the input context. The task specification includes a task name, task type, work area, subtask list and parent-child task relationship, and the work area in the task specification includes the set of boundary points of the area.

3. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The process of suspending the task creation tool call before calling it, creating a temporary task with an unconfirmed status based on the task specifications, and obtaining a temporary task identifier specifically involves: When the agent initiates a tool call, it identifies whether the tool identifier of the tool to be called belongs to a preset set of tools that need to be verified. When the tool identifier belongs to the set of tools to be verified, the call is suspended before the task creation tool is executed, and the call identifier, call parameters and session state of the call are retained; Call the temporary task creation interface, create the temporary task according to the task specifications, set the task status of the temporary task to unconfirmed, and return the temporary task identifier; During the unconfirmed state, the temporary task is only used to generate the task tree and the task card, does not trigger the actual occupation and locking of execution resources, and is not sent to the task scheduling system.

4. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The process of querying the task tree corresponding to the temporary task identifier, and then normalizing and stably sorting the task tree to obtain a task semantic snapshot, is as follows: Query the task tree corresponding to the temporary task identifier, take each task in the task tree as a task node, take the parent-child relationship, task dependency relationship, execution order relationship and condition trigger relationship between tasks as the association edge between the task nodes, and take the work area information and resource allocation relationship as the node attributes of the corresponding task node to construct a task semantic tree. The task semantic tree is normalized to obtain a normalized task semantic tree; The normalized task semantic tree is subjected to stable sorting, and the normalized task semantic tree after stable sorting is serialized to obtain the task semantic snapshot.

5. The method for triggering unmanned platform command and control tasks according to claim 4, characterized in that, The task semantic tree is normalized to obtain a normalized task semantic tree, specifically as follows: The task identifier, task type, task execution parameters, parent-child relationship, task dependency relationship, execution order relationship, condition trigger relationship, job area information and resource allocation relationship in the task semantic tree are retained; Remove the task creation time, task update time, operator display information, task card display text, and interface style information from the task semantic tree that do not participate in the task execution logic to obtain the normalized task semantic tree.

6. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The output, a task card carrying the action identifier generated based on the task semantic snapshot, is specifically as follows: The task card is generated based on the task semantic snapshot. The task card includes the task name, job area name, job area range, task type, number of subtasks, task resources, and task tree relationship summary. The task tree relationship summary includes the parent-child relationship, task dependency relationship, execution order relationship, condition triggering relationship, and resource allocation relationship represented by the task semantic snapshot. The action identifier is written into the task card and the task card is output in a streaming manner. The message type of the task card is the action type to be verified, so as to make the confirmation trigger decision or cancellation decision for the task card.

7. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The step of querying the associated and stored verification context based on the action identifier specifically involves: Based on the session identifier and the action identifier, query the verification context that is saved in association with the action identifier; If the verification context is not found, or if the verification context found is missing the temporary task identifier or the task tree verification value, the task specification shall not be regenerated and the temporary task shall not be converted into a formal task. A prompt message indicating that the verification context is missing shall be output.

8. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, The step of resuming execution of the intelligent agent from the point of the suspended call specifically involves: When the call is suspended, an execution snapshot is saved. The execution snapshot includes the session identifier, execution node identifier, suspended tool identifier, and suspended tool call context. The execution snapshot is then associated with and stored with the temporary task identifier. When the current verification value is consistent with the task tree verification value in the verification context, the execution snapshot is queried according to the session identifier and the temporary task identifier, and the temporary task identifier and the verified task tree verification value are written as structured parameters into the recovery execution context. The execution state of the agent is located to the execution node corresponding to the execution node identifier, and the recovery execution context is used as the input of the execution node to resume the execution of the suspended task creation tool.

9. The method for triggering unmanned platform command and control tasks according to claim 1, characterized in that, After generating the action identifier, the method further includes: Set the action status corresponding to the action identifier to pending verification, and write the action identifier, the action status, and the task card into the session history corresponding to the session identifier; Upon receiving a cancellation decision carrying the action identifier, the action status is updated to canceled, and the temporary task is not converted into a formal task; When the temporary task is converted into a formal task and issued to the task scheduling system, the action status is updated to "verification passed".

10. A triggering device for command and control tasks of an unmanned platform, characterized in that, include: The task specification generation module is used to generate task specifications by the large language model agent based on natural language task requests. The suspend module is invoked to suspend the call to the task creation tool before it is invoked. A temporary task with an unconfirmed status is created according to the task specifications, and a temporary task identifier is obtained. The snapshot verification module is used to query the task tree corresponding to the temporary task identifier, normalize and stably sort the task tree to obtain a task semantic snapshot, and calculate the task tree verification value of the task semantic snapshot. The verification context module is used to generate an action identifier, associate and save the temporary task identifier and the task tree verification value as a verification context with the action identifier, and output a task card carrying the action identifier generated based on the task semantic snapshot; The consistency verification module is used to receive a confirmation trigger decision for the task card, the confirmation trigger decision carrying the action identifier; query the associated and stored verification context according to the action identifier, and recalculate the current verification value of the task tree corresponding to the temporary task identifier in the verification context according to the same normalization and stable sorting rules; The same-source triggering module is used to refuse triggering when the current verification value is inconsistent with the task tree verification value in the verification context; when they are consistent, the agent resumes execution from the suspended call point, and no longer regenerates the task specification, but converts the temporary task corresponding to the temporary task identifier into a formal task and sends it to the task scheduling system to control the unmanned platform to perform the operation according to the task tree.

Images