Knowledge enhancement method and device for remote sensing agent, and electronic device

Abstract

The application provides a knowledge enhancement method and device for a remote sensing intelligent agent, and an electronic device. The knowledge enhancement method comprises the following steps: retrieving a task card related to an input question of a user from a preset hierarchical knowledge base based on the input question, wherein the hierarchical knowledge base comprises at least one task card; performing experience retrieval in a preset experience memory bank by using the task card; and generating a prompt word for driving the remote sensing intelligent agent by using the input question, the task card and the experience retrieval result. According to the example embodiment of the application, the hierarchical knowledge base can be retrieved, each atomic task is encapsulated as a task card, experience retrieval is performed by using the task card, the prompt word for driving the remote sensing intelligent agent is generated by using historical failure experience, and therefore, the tool calling correctness of the remote sensing task and the reliability of the generated result are improved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically, to a knowledge enhancement method and apparatus for remote sensing intelligent agents, electronic devices, and non-transitory computer-readable storage media. Background Technology

[0002] Remote sensing and geoscientific analysis tasks are typically characterized by "multi-source data, multi-step processing, multi-tool collaboration, and strong professional constraints." In recent years, Large Language Models (LLMs) and tool-augmented agents have shown potential in general task planning and tool invocation, and researchers have begun to explore their application in tasks such as remote sensing image processing, time-series analysis, index calculation, change detection, and surface parameter inversion. However, existing general agents face three prominent problems in the field of remote sensing: (1) Lack of domain knowledge leads to fragile planning.

[0003] Remote sensing tasks often involve implicit physical meanings and variable contracts (such as brightness temperature and surface temperature, radiometric calibration and atmospheric correction, band selection and index definition, projection / resolution consistency, etc.). General intelligent agents are prone to misunderstanding key concepts, which can lead to cascading errors.

[0004] (2) Over-reliance on manual templates.

[0005] Some methods improve success rates by having experts write workflow templates or prompt word libraries, but templates are costly to build and maintain, have limited coverage, and are difficult to evolve quickly with changes in data, tools, and tasks.

[0006] (3) Failure experiences are difficult to accumulate and reuse.

[0007] Failures are not uncommon in remote sensing toolchains (incorrect tool names, improper parameters, path / format mismatches, variable drift, incomplete loop closure, etc.). Existing systems mostly focus on "correcting errors in the current instance" and lack mechanisms to extract reusable experience from failure trajectories, leading to repeated occurrences of similar problems and low overall efficiency. Summary of the Invention

[0008] This application proposes a knowledge enhancement method and apparatus, electronic device, and non-transitory computer-readable storage medium for remote sensing intelligent agents, in order to solve the problem in the prior art that historical experience cannot be reused when intelligent agents perform tasks.

[0009] According to one aspect of this application, a knowledge enhancement method for remote sensing agents is proposed, comprising: Based on the user's input question, a task card related to the input question is retrieved from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card; Using the task card, experience can be retrieved from a preset experience memory bank; Using the input question, the task card, and the experience retrieval results, prompt words are generated to drive the remote sensing agent.

[0010] According to some embodiments, before retrieving task cards related to the user's input question from a preset hierarchical knowledge base, the method further includes: constructing the hierarchical knowledge base.

[0011] According to some embodiments, the hierarchical knowledge base is constructed as follows: Establish atomic tasks based on the application domain of the input problem; Construct task cards for the atomic tasks; Create a retrieval index for the task card.

[0012] According to some embodiments, the retrieval index includes a title keyword index, a domain keyword index, and a semantic vector index. Based on the user's input question, task cards related to the input question are retrieved from a pre-defined hierarchical knowledge base, including: The input question is subjected to keyword extraction to obtain a set of query keywords; The query keyword set is semantically encoded to obtain a query semantic vector; Lexical retrieval is performed using the query keyword set, the title keyword index, and the domain keyword index. Calculate the vector similarity between the query semantic vector and the semantic vector index to obtain the semantic retrieval result; The lexical retrieval results and semantic retrieval results are fused and sorted to obtain task cards related to the input question.

[0013] According to some embodiments, the task card is used to perform experience retrieval in a preset experience memory bank, including: Using the task card, historical failure patterns or repair experiences corresponding to the task card are retrieved from a preset experience memory bank to obtain experience retrieval results; The experience retrieval results include negative constraints, variable contract constraints, path rules, format rules, and / or operable repair plans derived from historical failure experiences.

[0014] According to some embodiments, the prompt word template includes a task description, task-level guidance, instance-level historical experience constraints, and output requirements.

[0015] According to some embodiments, the knowledge enhancement method further includes: The prompt words are used to drive the remote sensing agent generation tool to call the trajectory; The tool's call trajectory is detected; When an anomaly is detected, the tool is used to update the experience memory database by recalling the trajectory. The updated experience memory is used to continue generating prompts that correspond to the input question and drive the remote sensing agent.

[0016] According to some embodiments, the detection of the tool call trajectory includes: Real-time detection is performed after each tool call completes; and / or After all tools have been invoked, perform post-event testing.

[0017] According to some embodiments, when an anomaly is detected, the tool is used to update the experience memory bank by recalling the trajectory, including: The tool's trajectory is compressed to obtain a compressed trajectory; The compression trajectory is diagnosed based on preset failure discrimination rules; Generate experience entries based on failure diagnosis results; The experience entries are saved to the experience memory bank for updating the experience memory bank.

[0018] According to one aspect of this application, a knowledge enhancement device for remote sensing intelligent agents is proposed, comprising: The task card retrieval unit is used to retrieve task cards related to the user's input question from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card. An experience retrieval unit is used to retrieve experience from a preset experience memory bank using the task card. The prompt word generation unit is used to combine the input question, the task card, and the experience retrieval results through a preset prompt word template to generate prompt words that drive the remote sensing agent.

[0019] According to one aspect of this application, an electronic device is provided, comprising: a processor; a memory for storing a computer program; and, when the computer program is executed by the processor, causing the processor to implement the knowledge enhancement method as described in any of the preceding embodiments.

[0020] According to one aspect of this application, a non-transitory computer-readable storage medium is proposed, on which computer-readable instructions are stored, which, when executed by a processor, cause the processor to perform the knowledge enhancement method as described in any of the preceding embodiments.

[0021] According to the example embodiments of this application, by constructing a searchable hierarchical knowledge base, encapsulating each atomic task as a task card, and using the task cards to obtain experience retrieval, prompt words that drive remote sensing agents are generated using historical failure experiences, thereby improving the correctness of tool calls for remote sensing tasks and the reliability of generated results. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below.

[0023] Figure 1 A flowchart of a knowledge enhancement method for a remote sensing agent according to an example embodiment of this application is shown.

[0024] Figure 2 A schematic diagram of the hierarchical structure of an Earth science knowledge base according to an example embodiment of this application is shown.

[0025] Figure 3 A flowchart of another knowledge enhancement method for remote sensing agents according to an example embodiment of this application is shown.

[0026] Figure 4 A schematic diagram of a knowledge enhancement method for a remote sensing agent according to an example embodiment of this application is shown.

[0027] Figure 5 A schematic diagram illustrating an example implementation process of a knowledge enhancement method for a remote sensing intelligent agent according to an example embodiment of this application is shown.

[0028] Figure 6 A schematic diagram showing a comparison of the tool call trajectory and result performance of a knowledge enhancement method for remote sensing agents according to an example embodiment of this application and the prior art is illustrated.

[0029] Figure 7 A schematic diagram comparing the efficiency and cost of a knowledge enhancement method for remote sensing agents according to an example embodiment of this application with existing technologies is shown.

[0030] Figure 8 The diagram illustrates the token percentage during the reflection phase of a knowledge enhancement method for remote sensing agents according to an example embodiment of this application and the prior art.

[0031] Figure 9 A block diagram of a knowledge enhancement device for a remote sensing agent according to an example embodiment of this application is shown.

[0032] Figure 10 An electronic device is shown according to an exemplary embodiment of this application. Detailed Implementation

[0033] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that this application will be thorough and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted.

[0034] The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced without one or more of these specific details, or other methods, components, materials, apparatus, or operations may be employed. In these cases, well-known structures, methods, apparatuses, implementations, materials, or operations will not be shown or described in detail.

[0035] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0036] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0037] Before describing the embodiments of this application, the terms appearing in this application will first be explained.

[0038] Remote sensing intelligent agent: refers to a software system that uses a large language model as its core and can call on external remote sensing / geographic tools (such as image processing, index calculation, classification / detection / inversion, vector analysis, etc.) to complete multi-step task planning and execution.

[0039] Tool call trajectory: A time-series record of "thinking - calling tools - obtaining results - continuing decision-making" generated by the agent during a task-solving process, including tool name, parameters, input / output paths / summaries, error messages, etc.

[0040] Task hierarchy / level classification: A classification system that organizes remote sensing geoscience tasks in a hierarchical manner according to "domain - subdomain - atom task", used to map user questions to searchable task units.

[0041] Task Card: A structured knowledge unit for an atomic task, containing at least a task title Ti, a domain definition Di, and execution suggestions / toolchain hints Si, used to guide planning and tool selection.

[0042] Hierarchical Knowledge Grounding (HKG): Based on a task hierarchy retrieval and alignment mechanism, it performs hierarchical matching of user queries and outputs task-level guidance information to constrain agent planning and tool selection.

[0043] Failure-Aware Experience Refinement (FAR) involves structured diagnosis of failed tool call trajectories, extracting reusable "negative constraints / repair strategies," and writing them into experience memory to avoid repeating mistakes.

[0044] Dual-stream retrieval: Simultaneously retrieves task-level knowledge (static knowledge base) and instance-level experience (dynamic memory base), providing two types of context: "how to do it" and "don't do it this way / how to fix it last time".

[0045] Trace Compression: Summarizes and compresses redundant inputs and outputs (such as large file lists and long logs) in long trajectories while retaining key signals, thereby reducing the overhead of experience generation and storage.

[0046] Failure detection rule set: A set of rules used to detect structural / semantic anomalies in the trajectory, which may include: invalid tool name, missing / out-of-bounds parameters, inconsistent paths, target variable drift, and incorrect output format for non-closed loops.

[0047] The specific embodiments according to this application will now be described in detail with reference to the accompanying drawings.

[0048] Figure 1 A flowchart illustrating a knowledge enhancement method for a remote sensing agent according to an example embodiment of this application is shown, such as... Figure 1 The knowledge enhancement method shown includes steps S101, S103, and S105. The following will use... Figure 1 Taking an example, a knowledge enhancement method for remote sensing intelligent agents according to an example embodiment of this application will be described in detail.

[0049] In step S101, based on the user's input question, a task card related to the input question is retrieved from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card.

[0050] According to an embodiment of this application, before step S101, Figure 1 The knowledge enhancement method shown also includes constructing the hierarchical knowledge base.

[0051] In some embodiments, when constructing a hierarchical knowledge base, firstly, atomic tasks are established based on the application domain of the input question; then, task cards are constructed for the atomic tasks; and finally, a retrieval index is established for the task cards.

[0052] This application establishes corresponding task cards for each application area, enabling searchable task-level guidance and reducing reliance on manually fixed workflow templates.

[0053] Taking environmental monitoring as an example, when creating task cards, firstly, remote sensing geoscience applications are divided into multiple fields (such as environmental monitoring, disaster management, urban development, etc.), and these fields are identified as primary fields. Then, combining literature, task classification systems, and expert knowledge in this field, the primary fields are further subdivided. For example, environmental monitoring is further divided into multiple subfields such as land cover monitoring, vegetation monitoring, water resource monitoring, and surface temperature / thermal environment monitoring. Subsequently, each subfield is further broken down to obtain atomic tasks that can be directly executed by intelligent agents using tools.

[0054] For example, in the land cover subdomain, atomic tasks such as pixel-level semantic segmentation, scene classification, change detection, and sub-pixel spectral decomposition are defined; in the water resource monitoring subdomain, atomic tasks such as water body extraction, water quality parameter inversion, and temporal change analysis are defined. Through this approach, previously scattered remote sensing geoscience knowledge can be gradually transformed into clearly structured, searchable, and reusable task knowledge units, providing a foundation for subsequent task matching, prompt construction, and tool invocation. Figure 2 As shown, the outer ring is the defined first-level domain, and the inner ring is the corresponding subdomain.

[0055] In some embodiments, a task card si={Ti, Di, Si} also needs to be constructed for each atomic task i. Here, Ti is the task title, Di is the task definition, and Si is the standardized execution suggestion corresponding to the atomic task. The standardized execution suggestion is used to provide a structured description and constraints for the execution process of the atomic task.

[0056] In specific embodiments, the standardized implementation recommendations include at least one or more of the following: necessary input data types, input data preprocessing requirements, selection principles for key parameters and thresholds, common error types, and corresponding verification points.

[0057] In other embodiments, a retrieval index needs to be created for each task card to facilitate retrieval.

[0058] For example, multi-granularity index information is generated for each task card, including a title keyword index, a domain keyword index, and a semantic vector index. The title keyword index records the core terms in the task title, the domain keyword index records the set of professional terms related to the task's domain, subdomains, and task definition, and the semantic vector index records the vectorized representation of the task card text.

[0059] In specific embodiments, the title keyword index and domain keyword index can be generated through word segmentation, stop word removal, terminology extraction, and manual verification; the semantic vector index can be obtained by encoding the task title, task definition, and standardized execution suggestions using a text embedding model. The text embedding model includes, but is not limited to, BERT, Sentence-BERT, E5, or bge.

[0060] According to an embodiment of this application, in step S101, firstly, keywords are extracted from the input question to obtain a query keyword set; then, the query keyword set is semantically encoded to obtain a query semantic vector; for example, a text embedding model is used to encode the query keyword set into a query semantic vector. Then, lexical retrieval is performed using the query keyword set, the title keyword index, and the domain keyword index; then, the vector similarity between the query semantic vector and the semantic vector index is calculated to obtain a semantic retrieval result; finally, the lexical retrieval result and the semantic retrieval result are fused and sorted to obtain a task card related to the input question, which serves as a task-level guidance context.

[0061] Specifically, lexical retrieval can be implemented using text retrieval techniques such as inverted indexes, Boolean retrieval, TF-IDF, or BM25; semantic retrieval can be implemented using text embedding models, vector databases, and similarity retrieval techniques; fusion ranking can be achieved using any of the following: weighted summation, recall followed by reordering, or rule-based priority ranking. Vector retrieval can be based on cosine similarity, inner product, or Euclidean distance; the vector index structure can be implemented using FAISS, Milvus, HNSW, or other existing vector retrieval techniques.

[0062] It should be noted that in other embodiments, the experience memory can also be organized and retrieved based on task identifiers, problem categories, domain tags, or other associated identifiers. Any historical experience relevant to the current task that can be retrieved upon re-execution is applicable to this application.

[0063] In this embodiment, the fusion scoring function is as shown in formula (1).

[0064] (1) in, The semantic vector representing the input question q. Represents task card semantic vectors, (q) This indicates whether a match exists between the query and the task title. (q, k_j) Indicates query and domain keywords Does a match exist? and These are the weighting coefficients. and The value can be set as needed, and no specific restrictions are made here.

[0065] In a specific embodiment, after sorting the candidate task cards according to formula (1), at least one task card ranked first is used as the task-level guidance context Context_A.

[0066] In step S103, the task card is used to retrieve experience from a preset experience memory bank.

[0067] According to an embodiment of this application, in step S103, the task card is used to retrieve historical failure patterns or repair experiences corresponding to the task card from a preset experience memory, and the experience retrieval results are obtained as instance-level context Context_B. The experience retrieval results include negative constraints, variable contract constraints, path rules, format rules, and / or operable repair plans extracted from historical failure experiences.

[0068] In some embodiments, each task card is configured with a unique task identifier, and each experience entry in the experience memory is associated with at least one task identifier. An index structure is established according to the task identifiers, so that after determining the atomic task to which the current task belongs, the set of experience entries corresponding to that task can be directly read. This allows for the extraction of the task identifier corresponding to the task card, and the use of that task identifier to perform a matching search in the experience memory to select the experience entry that matches the task identifier as the instance-level context Context_B for the current task. If multiple experience entries correspond to the same task identifier, they can be selected according to a preset order, chronological order, failure frequency, or manually set priority, or multiple experience entries can be selected to jointly form the instance-level context Context_B.

[0069] It should be noted that experience retrieval based on task identifiers can be implemented using key-value mapping, hash indexes, database primary key indexes, inverted indexes, or other identifier-based precise retrieval techniques. This application does not limit the specific index implementation method; any method that can locate and retrieve the corresponding experience entry from the experience memory based on the task identifier is applicable to this application.

[0070] In some embodiments, the instance-level context Context_B is used to provide failure avoidance information and repair guidance information for the current task execution, and its content includes at least negative constraints, variable contract constraints, path / format rules and actionable repair plans that match the current task.

[0071] Specifically, "negative constraints" refer to prohibitive execution rules derived from historical failure experiences, used to clarify tools, parameter settings, or calling sequences that should not be used again in the current task. For example, negative constraints may manifest as prohibiting the use of a certain tool, prohibiting the use of a certain parameter value method, prohibiting the premature execution of subsequent steps when necessary intermediate results are lacking, or prohibiting the use of tool combinations in a known order that will lead to failure.

[0072] In other embodiments, "variable contract constraints" refer to constraint rules set for semantic consistency among task target variables, input variables, intermediate processing variables and output variables, which are used to avoid target variable drift, conceptual confusion or incorrect substitution of intermediate results by the agent during multi-step tool invocation.

[0073] Specifically, variable contract constraints are used to require that the inputs, processing procedures, and final outputs in a tool call chain always revolve around the target variable, and to restrict variables with different physical meanings or different semantic levels from being incorrectly replaced.

[0074] In other embodiments, "path / format rules" refer to constraint rules set for input and output file paths, data organization, file formats, and result formats during tool invocation.

[0075] For example, the input path must point to the intermediate result file on which the current step depends, the output file must be written to a preset directory, raster data, vector data and tabular data must meet the corresponding tool interface requirements, and the final output result must meet the preset field, preset structure or specified format requirements.

[0076] In other embodiments, an "operable repair plan" refers to a directly reusable correction scheme derived from historical failure experience, used to guide the agent to adjust tool selection, parameter settings, execution order, or verification steps when attempting again. The repair plan includes at least one or more of the following: suggested replacement tools, suggested parameter corrections, suggested supplementary preprocessing steps, suggested new verification actions, suggested adjusted execution order, and suggested supplementary result formatting steps.

[0077] This application organizes experience memory entries into structured experience units that are associated with task identifiers and contain negative constraints, variable contract constraints, path / format rules, and repair plans. These structured experience units are then introduced into the agent's task planning and tool invocation process through task identifier retrieval, thereby enabling the continuous accumulation, reuse, and evolution of failure experience.

[0078] In step S105, the input question, the task card, and the experience retrieval results are combined using a preset prompt word template to generate prompt words that drive the remote sensing agent.

[0079] In a specific example, the input question, task-level guidance context Context_A, and instance-level context Context_B are combined according to a preset template to generate prompts that drive the remote sensing agent.

[0080] In this embodiment, task-level guidance context is used to indicate what to do, while instance-level experience is used to suggest what not to do / how to fix, together improving the robustness of planning and execution.

[0081] It should be noted that the prompt construction method is not limited to fixed wording, but at least includes task description, task-level guidance, instance-level experience constraints, and output requirements.

[0082] Specifically, the preset template includes at least one or more of the following fields: The task description field is used to identify the user's input question q; The task-level guidance field is used to identify the task title, task definition, standardized execution suggestions, recommended toolchain order, key parameter or threshold selection principles, common errors and checkpoints written in the task card. Instance-level experience fields are used to identify historical experience entries written to the current task identifier, including negative constraints, variable contract constraints, path / format rules, and repair plans; The output requirements field is used to identify the steps that the agent needs to output, including the name of the tool to be called at each step, the parameter description, and the format of the final result.

[0083] In some embodiments, the preset template may be implemented as any one of the following: a natural language template, a combination of system prompts and user prompts template, a message list template, a key-value pair template, or a JSON structured template.

[0084] For example, the following natural language template can be used: "User task: {q}; Task-level guidance: {Context_A}; Historical experience constraints: {Context_B}; Please generate a step-by-step plan based on the above information, specifying the tool name, input parameters, and expected output for each step, and avoid violating historical experience constraints during execution, ultimately outputting results that meet the preset format requirements." For example, the following structured template can be used: The task description field is {q}; the task-level guidance field is {Context_A}; the instance-level experience field is {Context_B}; and the output requirements field is {plan, tools, parameters, result format}. This invention does not limit the specific template representation; any combination of the query, task-level guidance information, and instance-level experience information can be input into the agent.

[0085] according to Figure 1 The illustrated embodiment improves the correctness of tool calls and the reliability of generated results in remote sensing tasks by constructing a searchable hierarchical knowledge base, encapsulating each atomic task as a task card, and using the task cards to obtain experience retrieval, thereby generating prompt words to drive the remote sensing agent based on historical failure experience.

[0086] Figure 3 A flowchart illustrating a knowledge enhancement method for a remote sensing agent according to an example embodiment of this application is shown, such as... Figure 3 The knowledge enhancement methods shown include, in addition to Figure 1 In addition to steps S101, S103, and S105, the document also includes steps S107, S109, S111, and S113. The following will use... Figure 3 For example, a knowledge enhancement method for a remote sensing intelligent agent will be described according to an example embodiment of this application. To avoid redundancy, this embodiment only describes the method used in the example. Figure 1 The differences will not be repeated, and the similarities will not be described again.

[0087] like Figure 3 As shown, in step S107, the remote sensing agent generation tool is driven to call the trajectory using the prompt word.

[0088] According to an embodiment of this application, the step-by-step plan for generating the intelligent agent is expressed as shown in formula (2).

[0089] Plan = {p1, p2, ..., pk (2) In each step p k It should include at least the step objectives, the name of the tool to be called, the draft parameters, and the expected output.

[0090] In some embodiments, the step-by-step plan sequentially calls external remote sensing tools and records the actual execution process as a tool call trajectory, as shown in formula (3). Here, the step-by-step plan is used to describe the arrangement of steps to be executed, the tools to be called, the draft parameters, and the dependencies between steps; the tool call trajectory is used to record the actual tool call process that has occurred and its execution results.

[0091] (3) Among them, tool call trajectory Each trajectory unit in It should include at least one or more of the following: the actual tool name, actual input parameters, input file path, output file path, summary of returned results, return code, exception information, and timestamp.

[0092] Specifically, each step p k For each tool invocation action, the agent reads the proposed tool name and parameter draft in the current step, invokes the corresponding external remote sensing tool, and receives the processing result returned by the remote sensing tool. Afterwards, this actual invocation is recorded as a trajectory unit a. t Each trajectory unit a t It should include at least one or more of the following: the actual tool name called, the actual input parameters, the input file path, the output file path, the summary of the returned result, the return code, the exception information, and the timestamp.

[0093] In some embodiments, the agent also executes tool calls according to the generated step-by-step plan. After each tool call is completed, the agent first checks the tool return result, error message, and constraint rules of the completed step to determine whether the current step was executed successfully and whether the output generated by the step meets the input requirements of the next step. If the detection result indicates that the current step was executed successfully and its output meets the input requirements of the next step, then the subsequent steps are executed. If the detection result indicates that the current step has an anomaly, or although it has been completed, its output does not meet the input requirements of the next step, then the anomaly information is recorded, and the parameters, paths, execution order, or verification actions of the subsequent steps that have not yet been executed are adjusted before execution continues. Thus, the step-by-step plan provides the initial execution framework, while the tool call trajectory records the actual execution process. The two are logically connected but not equivalent.

[0094] This invention does not limit the specific implementation of the tool call interface, as long as it can call the corresponding tool according to the step-by-step plan and return the execution result. For example, external remote sensing tools can be accessed through function call interfaces, command line interfaces, script interfaces, workflow node interfaces, or other existing tool call methods.

[0095] In step S109, the tool call trajectory is detected.

[0096] In some embodiments, the tool call trajectory is analyzed based on a set of failure criteria rules. Perform real-time or post-event detection. Real-time detection means that after each tool call is completed, a detection is performed on the current trajectory unit; if the detection passes, the subsequent steps continue; if the detection fails, the exception type is recorded and step S111 is executed. Post-event detection means that after the entire tool call trajectory has been executed, the aforementioned check is performed on all trajectory units and the final output result to determine whether any exceptions exist.

[0097] The failure discrimination rule set is used to check each trajectory unit and its corresponding intermediate results to determine whether there are any anomalies in the current execution process. In specific embodiments, the failure discrimination rule set can be implemented using existing rule engines, condition judgment modules, anomaly detection scripts, or combinations thereof. In other embodiments, it can also be implemented using classifiers, anomaly detection models, or a hybrid approach combining rule-based discrimination and learning-based discrimination; no specific limitations are imposed here.

[0098] For example, a conditional judgment method based on if-then rules can be used to verify the return code, path existence, parameter integrity, output format, and result range item by item. This invention is not limited to a specific implementation form, as long as it can detect anomalies in the tool invocation process and results according to preset rules.

[0099] In some embodiments, the detected content includes at least one or more of the following: Tool call validity check: Check whether the actual tool name is in the set of tools allowed by the current task, check whether the tool was started successfully, whether the return code is the preset success status, and whether there are explicit error messages or abnormal termination messages; Parameter validity check: Check whether input parameters are missing, whether the parameter format is correct, whether the parameter values ​​fall within the preset range, and whether the necessary parameters satisfy the dependency relationship; Input / output path detection: Checks whether the input file path exists, whether the output file is successfully generated, whether the output path is written to the preset directory, and whether the path referenced in subsequent steps is consistent with the actual output of the previous step; Data format and structure check: Check whether the file format, band structure, field structure, coordinate reference information or resolution information of the input and output data meet the requirements of the corresponding tool interface; Target variable consistency check: Check whether the input variables, intermediate results and output results of the current step are consistent with the task target variable to avoid target variable drift, semantic confusion or incorrect substitution of intermediate results; Result closure check: Check whether the final result required by the task has been generated, and whether the final result meets the preset fields, preset structure or specified format requirements; Result range and reasonableness check: Check whether the output result falls within a reasonable value range, and whether the result is empty, all zero, all empty value or obviously abnormal.

[0100] In step S109, if the detection result shows no abnormality, the final result is output; if the detection result shows an abnormality, the corresponding abnormality type, abnormality location and related context information are recorded, and step S111 is executed.

[0101] In step S111, when an anomaly is detected, the tool is used to call the trajectory to update the experience memory bank.

[0102] According to an embodiment of this application, in step S111, firstly, the tool call trajectory is compressed to obtain a compressed trajectory; then, the compressed trajectory is diagnosed for failure based on a preset failure discrimination rule; then, experience entries are generated based on the failure diagnosis results; finally, the experience entries are saved to the experience memory bank to update the experience memory bank.

[0103] In a specific embodiment, by tracking the tool's call trajectory Compression processing is performed, retaining key decision texts and error signals. Lengthy tool input / output content, log content, and intermediate result descriptions are truncated, filtered, or summarized to obtain the compression trajectory. .

[0104] In some embodiments, trajectory The data for each trajectory unit comes from the interaction log records during the execution of the agent.

[0105] Specifically, during the execution of step S107 by the intelligent agent, user input, intelligent agent output, tool call request, and tool return result are written to a log file or session record; during trajectory compression, the execution process corresponding to the current task is extracted from the log file or session record to form the original trajectory. The tool name and parameters in each trajectory unit of the original trajectory come from the tool call request initiated by the agent. The input / output paths, result summaries, return codes, and error messages come from the return results or system log information after the tool is executed. The key decision text comes from the analysis text, decision text, or step description text output by the agent before and after calling the tool.

[0106] In some embodiments, trajectory compression can be implemented as follows: First, locate the execution segment corresponding to the current task from the log file or session records; Then, extract the agent text, tool call records, and tool return records from the execution segment in chronological order; Then, key text related to task solving, step decision-making, and error analysis is retained from the agent's text. Then, the tool call log retains the tool name and its key input parameters; Then, retain key information from the output results in the tool's return records, including input / output paths, result summaries, return codes, exception information, and error messages; Then, excessively long tool inputs, tool outputs, log lists, or file lists are compressed to generate a compression track. Among them, the compression trajectory The trajectory compression shall include at least one or more of the following: key decision text, tool name, key parameters, key input / output paths, result summary, return code, error message, anomaly location, and context fragments related to failure. The trajectory compression can be implemented using existing log parsing, string truncation, rule filtering, template extraction, or text summarization techniques. It should be noted that this application does not limit the specific compression algorithm; any algorithm that can extract key steps from the execution log and compress redundant tool input / output content is applicable to this application.

[0107] In specific embodiments, the compression process includes at least one or more of the following: Length truncation: When the length of tool input, tool output, or log text exceeds a preset threshold, only the beginning text, the end text, or key segments are retained; List compression: When the output is a long list, a long array, or a large number of file paths, only the first few items, the last few items, and the number of omitted items are retained; Dictionary compression: When the output is a structured result with many fields, only some key fields and their values ​​are retained; Error priority retention: When the output contains error messages, exception stacks, failure messages, missing path messages, or invalid parameter messages, relevant fragments are retained in their entirety or with high fidelity. Order Preservation: The original sequence of each key step is preserved after compression, so as to determine the location and context of the failure later.

[0108] In some embodiments, if the tool output contains error keywords, these are identified as high-value error signals and retained with priority. The error keywords may include one or more of the following: error, exception, failed, traceback, invalid, not found, cannot, unable, etc. For output text containing the above error keywords, if its length does not exceed a preset limit, it can be retained entirely; if its length exceeds the preset limit, the preceding error context and the subsequent key error segment can be retained.

[0109] In other embodiments, if the tool output is a list, array, or collection of file paths, only the first and last few items can be retained, with ellipsis markers added in between; if the tool output is a dictionary or key-value pair structure, only some key fields can be retained. In this way, the length of the trajectory can be reduced while retaining the key information needed for subsequent failure diagnosis and experience generation.

[0110] According to embodiments of this application, when performing failure diagnosis on the compression trajectory based on preset failure discrimination rules, the failure is based on a preset set of failure discrimination rules and context information. Perform diagnostics to identify the failure type of the current execution process. The information below should include at least the user query q, task-level guidance context Context_A, instance-level context Context_B, current task identifier, step-by-step plan, and compressed trajectory. The system retains key tool call information. The failure diagnosis is used to determine the location of the failure, the direct cause of the failure, and the correspondence between the cause and task constraints, providing a basis for subsequent experience generation.

[0111] Specifically, failure identification can be achieved through the following process: First, read the compressed track. The tool name, key parameters, input / output paths, return result summary, return code, and exception information for each key step in the process; Then, the final output result is checked according to the preset failure judgment rules to determine whether there are any abnormalities in this round of execution; If an anomaly is found, the cause of the anomaly is further classified by combining the task-level guidance information, instance-level experience constraints, and key trajectory segments of the current task to obtain the corresponding failure type. The failure type, along with the steps in which the anomaly occurred, key error signals, and relevant context, are then output to generate experience entries.

[0112] In some embodiments, the failure criteria include at least one or more of the following: the final answer is missing; the final answer does not meet the preset label or preset format requirements; the final output lacks a parsable result identifier; the output contains abnormal prompts such as refusal to answer, inability to continue, or lack of necessary steps; the output contains data access abnormal prompts such as inability to access data, file not existing, missing path, or insufficient permissions; the output contains obvious speculative statements; and the tool returns error codes, failure prompts, exception stacks, or key error keywords.

[0113] In other embodiments, after determining that an exception exists in the current execution, the exception can be further classified into one or more of the following failure types: Invalid tool call: A tool that does not exist, is unauthorized, or should not be used by the current task was invoked; Missing or invalid parameters: Key parameters are missing, parameter format is incorrect, parameters are out of bounds, or the parameters do not satisfy the dependency relationship; Data path inconsistency: Input path does not exist, output file not generated, path referenced by subsequent steps is inconsistent with the actual output of the previous step; Target variable drift: The processing or output results deviate from the target variable of the task, resulting in variable confusion, incorrect substitution of intermediate results, or incorrect correspondence of physical quantities; Incomplete closed loop: Although some steps have been performed, the final result required by the task has not been generated, or the format of the final result does not meet the requirements; Spatial reference or resolution inconsistency: Inconsistency in projection, coordinate reference system, resolution, or raster structure between input and output data; Abnormal results: The output is empty, all zeros, all null values, the value is obviously abnormal, or it does not match the task objective.

[0114] It should be noted that the failure identification rule set can also be implemented using existing rule matching, conditional judgment, regular expression detection, anomaly detection scripts, or combinations thereof. This application does not limit the specific identification algorithm, as long as it can identify whether the current execution has failed and summarize the failure type based on the execution result, trajectory information, and preset rules.

[0115] For example, regular expressions can be used to detect whether the final output contains preset answer tags, whether the output text contains abnormal prompts such as "cannot access", "missing file", "no such file or directory", "permission denied", "sorry", "unable to complete", etc., and whether error keywords such as error, exception, failed, traceback, invalid, not found appear in the results returned by the inspection tool.

[0116] In some embodiments, when the same failed instance satisfies multiple failure rules at the same time, a primary failure type and a secondary failure type can be recorded, wherein the primary failure type is used to drive experience generation, and the secondary failure type is written into the experience entry as a supplementary constraint.

[0117] According to an embodiment of this application, when generating experience entries, the experience generation module is invoked to compress the trajectory. Perform reflection processing to generate an experience entry M corresponding to the current failed instance. i Preferably, the input to the experience generation module includes at least one or more of the following: the user's original query, task-level guidance context, and compressed trajectory. The current round identifier and the current problem identifier are also present. The output of the experience generation module is an experience entry M that can be used in the next round of execution. i .

[0118] In a specific embodiment, experience entries can be generated through the following steps: First, read the user query, task-level guidance information, and compressed trajectory corresponding to the current failed instance. ; Then, the above information is organized according to the preset reflection prompt template to form experience generation input; Then, the experience-generated input is processed to summarize the most likely reasons for failure in this round of execution and generate remedial guidance for the next round of execution. Then, the generated results are parsed for format. Then, if the generated result meets the preset format requirements, an experience entry M is generated. i If the generated result does not meet the preset format requirements, the default text will be used to generate a fallback experience entry.

[0119] In some embodiments, the preset reflection prompt template includes at least one or more of the following: problem identifier, round information, original problem text, task-level guidance information, compressed trajectory, and output format requirements. The output format requirements are used to constrain the structured results output by the experience generation module. The structured results include at least a problem identifier field and an experience text field.

[0120] In other embodiments, empirical entry M i Include at least one or more of the following fields: The issue identifier field is used to identify the issue instance corresponding to this experience entry; The round identifier field is used to identify which execution attempt the experience entry originated from; The experience text field is used to record the corrective guidance output by the experience generation module; The time field is used to record the time when the experience entry was generated.

[0121] In other embodiments, the experience text field is used to record reflections generated for the current failure instance. These reflections include at least one or more of the following: a summary of the cause of the failure, key clues leading to the failure, priority areas for correction in the next execution, and high-level recommendations to avoid repeating the failure. The experience text may be stored in natural language text format.

[0122] In a specific implementation, if the output of the experience generation module cannot be correctly parsed or lacks preset fields, a default experience text can be used as a fallback. The default experience text serves as a prompt to re-examine the tool call flow, data path, and final output format requirements during the next execution.

[0123] It should be noted that experience entries can be generated using existing text generation, template filling, rule induction, or a combination thereof. This application does not limit the specific method of generating experience entries, as long as it can generate experience entries that can be reused in the next round of execution based on the compressed trajectory and problem context.

[0124] In step S113, the updated experience memory is used to continue generating prompt words that correspond to the input question and drive the remote sensing agent.

[0125] According to an embodiment of this application, in step S113, the generated experience entries are written into the experience memory bank, and starting from step S101, prompt words corresponding to the input question and driving the remote sensing agent are generated.

[0126] It should be noted that experience entries can be represented in the form of natural language text, field templates, JSON structures, knowledge graph triples, or workflow descriptions. The specific representation of an experience entry can also vary, but this does not affect its role as corrective guidance information for subsequent executions.

[0127] In specific embodiments, the experience memory is implemented using a structured file storage method, such as a JSON file, a key-value store file, a database record table, or other data storage structures that support reading and appending by identifier.

[0128] In some embodiments, experience writing and updating can be implemented by methods such as direct append writing, deduplication and merging, prioritizing the retention of high-yield experiences, time decay forgetting, or selective writing, without specific limitations.

[0129] In some embodiments, the experience memory includes at least an experience entry area and a metadata area.

[0130] Specifically, the experience entries in the experience memory are organized and stored according to the problem identifier.

[0131] For example, a mapping structure can be adopted, using problem identifiers as keys and lists of experience entries as values. This means maintaining a corresponding list of experience entries for each problem identifier. Each time a new experience entry is generated, it is appended to the experience entry list corresponding to that problem identifier, and the statistics and update time information in the metadata area are updated synchronously, thus forming an online experience memory aggregated by problem identifier. To avoid inconsistencies during the writing process, the updated experience memory can be written to a temporary file first, and then the original experience memory file can be overwritten using atomic replacement, thereby improving the stability and consistency of the writing process. When the same problem is executed again subsequently, the corresponding list of experience entries can be read from the experience memory based on the current problem identifier, and the most recently generated experience entry can be selected as the instance-level experience context for the current problem and injected into the subsequent suggestion construction process. This enables the continuous accumulation and reuse of historical failure experiences.

[0132] In specific embodiments, experience entries include at least one or more of the following fields: The issue identifier field is used to identify the issue instance corresponding to this experience entry; The round identifier field is used to identify which execution attempt the experience entry originated from; The experience text field is used to store restorative guidance content output by the experience generation module; The time field is used to record when the experience entry was generated.

[0133] In other embodiments, the experience memory also includes a metadata area for recording overall state information of the experience memory. The metadata area includes at least one or more of the following fields: last update time, total number of experience entries, version information, and other statistical information.

[0134] In some embodiments, after a failure, the current step can be set to retry once or multiple times. Alternatively, after completing the experience update, only the local subprocess corresponding to the failed step can be rolled back and replanned, rather than the entire trajectory can be completely rerun.

[0135] according to Figure 3 The illustrated embodiment transforms failed trajectories into structured constraints and repair strategies through trajectory compression and the generation of structured experience entries, forming searchable instance-level experience and preventing the recurrence of similar errors. Simultaneously, it controls reflection and storage overhead, thereby achieving sustained performance gains with minimal additional cost. This application can be used as a plug-in mechanism to integrate with different large model backbones and various remote sensing tool sets, making it applicable to multiple types of remote sensing tasks.

[0136] In other embodiments, there is a collaborative mechanism of knowledge and experience that guides planning with structured domain knowledge, automatically generates reusable experience from failure trajectories, and continuously improves the success rate through multiple rounds of interaction / multiple attempts.

[0137] Figure 4 A schematic diagram of a knowledge enhancement method for a remote sensing agent according to an example embodiment of this application is shown, such as... Figure 4 As shown, Part A is the offline knowledge base construction phase, used to build a hierarchical knowledge base.

[0138] Specifically, firstly, geoscientific literature, domain data, or expert knowledge are organized to form domain knowledge sources; then, tasks are organized according to a hierarchical structure of "domain - subdomain - atomic task" and the hierarchical decomposition of tasks is completed; subsequently, task cards are constructed for each atomic task, and the task cards include task titles, task definitions, and standardized execution suggestions; based on this, the task cards are written into a hierarchical knowledge base to form a static knowledge foundation for online reading.

[0139] In Part B, an online dual-stream search is performed.

[0140] Specifically, firstly, based on the input question q, task-level knowledge related to the current question is retrieved from the hierarchical knowledge base to obtain the task-level guidance context, as described in step S101; then, historical experience corresponding to the current input question is retrieved from the experience memory base to obtain the instance-level experience context, as described in step S103.

[0141] After obtaining the aforementioned two parts of context, the prompt builder combines the user query, task-level guidance information, and instance-level experience information to form a prompt input for the agent to execute. The hierarchical knowledge base provides relatively stable domain knowledge and task guidance, while the experience memory provides restorative experience extracted from historical failures; together, they constitute the input basis for the online phase.

[0142] Part C focuses on online iterative experience refinement, such as... Figure 3 As described in [the text].

[0143] Specifically, the agent generates a step-by-step plan based on the aforementioned input prompts and invokes external remote sensing tools to execute the task, forming a tool invocation trajectory. After execution, anomaly detection and failure judgment are performed on the tool invocation trajectory and the final result. If no anomalies are found, the final answer is output; if anomalies are detected, the process enters the experience refinement stage.

[0144] For example, firstly, the original tool call trajectory is compressed, retaining key decision text, key tool call information, and error signals to obtain a compressed trajectory; then, the failure type of this round of failure is identified based on the compressed trajectory and context information; next, experience entries are generated based on the compressed trajectory, failure diagnosis results, and current problem context; finally, the experience entries are written into the experience memory for subsequent reading and reuse when the same problem is executed again.

[0145] After completing the experience writing, the online execution process can be re-entered, that is, execution can start again from step S101. Compared with the first execution, the updated experience memory will be read during the re-execution, so that the agent can obtain corrective guidance information corresponding to the previous failure in the new prompt input, thereby reducing repeated errors and improving the success rate of solving the problem. In this way, this application forms an iterative closed-loop mechanism of "online execution - anomaly detection - experience refinement - memory writing - re-execution".

[0146] Furthermore, Figure 4 The memory module shown comprises two parts: an offline-built hierarchical knowledge base and an online-updated experience memory. The former primarily provides task-level knowledge, while the latter mainly accumulates and reuses failed experiences. Together, they provide the agent with dual support from domain knowledge to instance experience, thereby improving the stability, repairability, and success rate in solving complex remote sensing tasks.

[0147] Figure 5 This illustration shows an example of the implementation process of a knowledge enhancement method for remote sensing agents according to an example embodiment of this application. Figure 5 The process of this application's failure trajectory → experience entry → re-retrieval guidance → successful execution of memory evolution effect is shown, demonstrating the role of variable contract constraints and toolchain repair.

[0148] like Figure 5 As shown, the "Query" section at the top corresponds to the input stage of the online execution process described above, where the user inputs the problem to be solved. This problem requires, based on Landsat 8 TOA data, to count the number of days that meet specific surface temperature conditions within a given time range and threshold. Upon receiving this query, step S101 is first executed to retrieve task-level guidance information corresponding to the problem from the hierarchical knowledge base; simultaneously, step S103 is executed to read historical experience related to the current problem from the experience memory (if this is the first execution, the experience memory can be empty); then step S103 is executed again to organize the user query, task-level guidance information, and experience information into a prompt input, driving the agent to generate a step-by-step plan.

[0149] The "First Round: Execution + Result (Failure)" section on the upper left of this diagram shows the agent calling external remote sensing tools according to the generated step-by-step plan. These tools sequentially attempt to complete operations such as thermal infrared data processing, temperature inversion, and threshold statistics, forming a tool call trajectory. The diagram lists the main steps executed in this round and the anomalies that occurred. For example, invalid tool calls, incorrect target variable substitutions, and failure to generate a complete answer are all considered critical failure signals in the tool call trajectory.

[0150] The "Problems" section shown on the upper right of this diagram indicates that after execution, the following failure phenomena were identified by examining the first round of tool call trajectory and final results: First, a non-existent tool was invoked, constituting an invalid tool call. Second, the target variable was incorrectly replaced from surface temperature to brightness temperature during processing, constituting target variable drift. Third, the statistical process for all scenarios was not completed as required by the problem, and the final output did not conform to the answer format, indicating an incomplete closed loop. Through the above detection and classification, the system identified the main reasons for this round of failure.

[0151] The "Example Experience Synthesis" section shown in the lower middle of this diagram first compresses the original tool call trajectory from the first round, retaining key steps, error messages, and decision text related to the failure. Then, combining the compressed trajectory, failure type, and task context, the reasons for the failure are summarized. Based on this, an experience entry addressing the current problem is generated. This experience entry summarizes the root cause of the failure in this round, namely, the incorrect use of brightness temperature directly as the target variable, and further provides corrective suggestions, such as first performing single-channel inversion to obtain the surface temperature before performing threshold statistics. The three parts in the diagram, "Error Diagnosis," "Domain Knowledge," and "Executable Plan," respectively represent the failure cause summary, task-related knowledge basis, and remedial suggestions for the next round of execution contained in the experience entry.

[0152] The "Round 2: Running + Result (Success)" section at the bottom of this diagram describes how, after completing the experience writing, the newly generated experience entries are written to the experience memory; then the online process is executed again. In the second round, the agent obtains the restorative experience generated in the previous round from the new prompt input, thereby adjusting the processing flow and completing the thermal infrared inversion and threshold statistics according to the correct target variable and processing order, ultimately obtaining the correct result that meets the requirements of the problem.

[0153] therefore, Figure 5 The overall process described in this application is a closed loop of "execution—failure detection—experience generation—re-execution". The first round of execution exposed problems such as incorrect tool selection, target variable drift, and incomplete process closure. After detecting failures, the failure trajectory is compressed and summarized to generate instance-level experience. In the second round of execution, this experience is used to revise the original plan, ultimately leading to successful solution completion. This demonstrates that this application can not only use task-level knowledge to guide agent execution but also continuously improve the correctness and stability of subsequent executions by accumulating instance experience online.

[0154] To facilitate understanding of the feasibility and technical effects of this invention, the implementation process and comparative evaluation of a knowledge enhancement method (RSMeM) for remote sensing agents according to an example embodiment of this application are described below. It should be noted that although this embodiment uses a multi-step tool invocation task for remote sensing agents on the existing EarthBench benchmark as an example, this application is not limited to a specific benchmark, toolset, or specific remote sensing task.

[0155] This application validates the generality of the model on multiple large language model backbones, covering open-source models (such as Qwen3-8B, Qwen3-32B, Kimi-K2, DeepSeek-V3.2, etc.) and optional commercial models. To ensure comparability, a unified set of remote sensing tools and a unified evaluation protocol are used. In terms of evaluation configuration, two settings are adopted: single-round execution (R@1) and up to three rounds of iterative execution (R@3). R@3 allows the agent to trigger one or more closed loops of "reflection-experience update-re-execution" after failure, to reflect the benefits of the memory evolution mechanism.

[0156] Unlike methods that use only a single metric, this embodiment conducts a systematic evaluation from three dimensions: "trajectory accuracy, result accuracy, and efficiency cost." (1) Trajectory correctness: Any-Order (AO), In-Order (IO), Exact-Match (EM) and Wise-Score (WS) are used to measure tool selection coverage, tool order consistency, whole trajectory matching and parameter / prefix sensitivity; (2) Result accuracy: End-to-end accuracy (Acc) is used to measure whether the final answer is correct; (3) Efficiency cost: TRI (Trajectory Redundancy Index), additional token overhead ratio and experience density ED are used to measure the return density under limited overhead.

[0157] For ease of description, the method of this invention will be referred to as RSMeM. In RSMeM, task-level guidance and instance-level experience can be used simultaneously in the online phase. The task-level guidance mechanism refers to Hierarchical Knowledge Grounding (HKG), and the experience refinement mechanism can be referred to as FAR. When execution fails, the system triggers the Failure-Aware Experience Refinement (FAR) mechanism to refine the experience from the failure trajectory and generate reusable restorative experience. Furthermore, to verify the role of each component, comparisons can be made between enabling only HKG, enabling only FAR, and enabling both HKG and FAR. This embodiment presents the experimental results from three aspects: overall performance, efficiency cost, and ablation comparison. Figure 6 Used to display the overall trajectory and result performance comparison Figure 7 and Figure 8 Used to demonstrate the comparison between efficiency and cost.

[0158] like Figure 6 As shown, across various backbone models, this application demonstrates an improving trend in both tool call trajectory metrics (AO / IO / EM / WS) and end-to-end result Acc, especially under the R@3 setting, which significantly improves the success rate of complex multi-step tasks.

[0159] like Figure 7 and Figure 8 As shown, the additional token overhead introduced in this application remains at a low level, the token proportion in the reflection phase is usually less than about 1%, and the ED remains high, indicating that the generated experience has a high information density.

[0160] The above description primarily focuses on the methodological aspects of the embodiments of this application. Those skilled in the art should readily recognize that, based on the operations or steps described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Those skilled in the art can implement the described functionality in different ways for each specific operation or method, and such implementations should not be considered beyond the scope of this application.

[0161] The apparatus embodiments of this application are described below. For details not described in the apparatus embodiments of this application, please refer to the method embodiments of this application.

[0162] Figure 9 A block diagram of a knowledge enhancement device for a remote sensing agent according to an example embodiment of this application is shown, such as Figure 9 The knowledge enhancement device shown includes a task card retrieval unit 901, an experience retrieval unit 903, and a prompt word generation unit 905. The task card retrieval unit 901 retrieves task cards related to a user's input question from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card. The experience retrieval unit 903 uses the task cards to perform experience retrieval in a preset experience memory bank. The prompt word generation unit 905 uses the input question, the task cards, and the experience retrieval results, combined with a preset prompt word template, to generate prompt words that drive the remote sensing agent.

[0163] Figure 10 An electronic device according to an exemplary embodiment of this application is shown. Reference is made below. Figure 10 To describe an electronic device 200 according to this embodiment of the present application. Figure 10 The electronic device 200 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0164] like Figure 10 As shown, the electronic device 200 is presented in the form of a general-purpose computing device. The components of the electronic device 200 may include, but are not limited to: at least one processing unit 210, at least one storage unit 220, a bus 230 connecting different system components (including storage unit 220 and processing unit 210), a display unit 240, etc.

[0165] The storage unit stores program code that can be executed by the processing unit 210, causing the processing unit 210 to perform the methods described in this specification according to various exemplary embodiments of this application. For example, the processing unit 210 can perform the methods described above.

[0166] Storage unit 220 may include readable media in the form of volatile storage units, such as random access memory (RAM) 2201 and / or cache memory 2202, and may further include read-only memory (ROM) 2203.

[0167] Storage unit 220 may also include a program / utility 2204 having a set (at least one) program module 2205, such program module 2205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0168] Bus 230 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0169] Electronic device 200 can also communicate with one or more external devices 300 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 200, and / or with any device that enables electronic device 200 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 250. Furthermore, electronic device 200 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 260. Network adapter 260 can communicate with other modules of electronic device 200 via bus 230. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0170] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. The technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, or network device, etc.) to execute the methods described above according to the embodiments of this application.

[0171] Software products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections with one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0172] Computer-readable storage media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0173] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0174] The aforementioned computer-readable medium carries one or more programs, which, when executed by a device, cause the computer-readable medium to perform the aforementioned functions.

[0175] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0176] According to an embodiment of this application, a computer program is proposed, including a computer program or instructions, which, when executed by a processor, can perform the methods described above.

[0177] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of this application, and on the specific implementation methods and application scope of this application, are all within the scope of protection of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0178] Those skilled in the art will understand that the above modules can be distributed in the device as described in the embodiments, or they can be modified accordingly and placed in one or more devices that are unique to this embodiment. The modules in the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0179] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only for the purpose of helping to understand the method and core ideas of this application. Furthermore, any changes or modifications made by those skilled in the art based on the ideas of this application, and on the specific implementation methods and application scope of this application, are all within the scope of protection of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A knowledge enhancement method for remote sensing intelligent agents, characterized in that, include: Based on the user's input question, a task card related to the input question is retrieved from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card; Using the task card, experience can be retrieved from a preset experience memory bank; Using the input question, the task card, and the experience retrieval results, prompt words are generated to drive the remote sensing agent.

2. The knowledge enhancement method according to claim 1, characterized in that, Before retrieving task cards related to the user's input question from a pre-defined hierarchical knowledge base, the process also includes: Construct the hierarchical knowledge base.

3. The knowledge enhancement method according to claim 2, characterized in that, Constructing the hierarchical knowledge base includes: Establish atomic tasks based on the application domain of the input problem; Construct task cards for the atomic tasks; Create a retrieval index for the task card.

4. The knowledge enhancement method according to claim 3, characterized in that, The retrieval index includes a title keyword index, a domain keyword index, and a semantic vector index. Based on the user's input question, task cards related to the input question are retrieved from a preset hierarchical knowledge base, including: The input question is subjected to keyword extraction to obtain a set of query keywords; The query keyword set is semantically encoded to obtain a query semantic vector; Lexical retrieval is performed using the query keyword set, the title keyword index, and the domain keyword index. Calculate the vector similarity between the query semantic vector and the semantic vector index to obtain the semantic retrieval result; The lexical retrieval results and semantic retrieval results are fused and sorted to obtain task cards related to the input question.

5. The knowledge enhancement method according to claim 1, characterized in that, Using the task card, experience retrieval is performed in a preset experience memory bank, including: Using the task card, historical failure patterns or repair experiences corresponding to the task card are retrieved from the preset experience memory bank to obtain experience retrieval results; The experience retrieval results include negative constraints, variable contract constraints, path rules, format rules, and / or operable repair plans derived from historical failure experiences.

6. The knowledge enhancement method according to claim 1, characterized in that, The prompt template includes a task description, task-level guidance, instance-level historical experience constraints, and output requirements.

7. The knowledge enhancement method according to claim 1, characterized in that, Also includes: The prompt words are used to drive the remote sensing agent generation tool to call the trajectory; The tool's call trajectory is detected; When an anomaly is detected, the tool is used to update the experience memory database by recalling the trajectory. The updated experience memory is used to continue generating prompts that correspond to the input question and drive the remote sensing agent.

8. The knowledge enhancement method according to claim 7, characterized in that, Detecting the tool's call trajectory includes: Real-time detection is performed after each tool call completes; and / or After all tools have been invoked, perform post-event testing.

9. The knowledge enhancement method according to claim 7, characterized in that, When an anomaly is detected, the tool is used to update the experience memory database by recalling the trajectory, including: The tool's trajectory is compressed to obtain a compressed trajectory; The compression trajectory is diagnosed based on preset failure discrimination rules; Generate experience entries based on failure diagnosis results; The experience entries are saved to the experience memory bank for updating the experience memory bank.

10. A knowledge enhancement device for remote sensing intelligent agents, characterized in that, include: The task card retrieval unit is used to retrieve task cards related to the user's input question from a preset hierarchical knowledge base, wherein the hierarchical knowledge base includes at least one task card. An experience retrieval unit is used to retrieve experience from a preset experience memory bank using the task card. The prompt word generation unit is used to combine the input question, the task card, and the experience retrieval results through a preset prompt word template to generate prompt words that drive the remote sensing agent.

11. An electronic device, characterized in that, include: processor; Memory, used to store computer programs; When the computer program is executed by the processor, the processor implements the knowledge enhancement method as described in any one of claims 1-9.

12. A non-transitory computer-readable storage medium having stored computer-readable instructions thereon, which, when executed by a processor, cause the processor to perform the knowledge enhancement method as described in any one of claims 1-9.

Images