Multi-step tool invocation data processing method and system based on large language model

Abstract

This application relates to a multi-step tool invocation data processing method and system based on a large language model, belonging to the fields of artificial intelligence and data processing. It includes: responding to a call instruction of a first tool, executing the first tool to obtain a first complete result; writing the first complete result into a runtime storage area independent of the large language model context, and generating a corresponding first reference identifier; returning a result summary and the first reference identifier of the first complete result to the large language model, so that the large language model can generate invocation parameters for a second tool based on the result summary; and controlling the second tool to read the first complete result from the runtime storage area through the first reference identifier in response to the invocation parameters containing the first reference identifier. This application achieves decoupling of intermediate results from the model context and deterministic transformation of data structures in multi-step tool invocation, reducing resource consumption and improving execution stability.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence and data processing, and in particular to a multi-step tool-invoking data processing method and system based on a large language model. Background Technology

[0002] With the rapid development of large language model technology, the application of intelligent agents based on tool invocation is becoming increasingly widespread. In the process of handling complex tasks, large language models usually need to sequentially invoke multiple tools to complete data analysis or business execution. In multi-step tool invocation scenarios, existing technologies typically feed the complete execution results of upstream tools directly back into the context window of the large language model as text, so that the model can understand and generate parameters for subsequent steps.

[0003] However, the above approach has significant drawbacks: on the one hand, when the amount of data returned by the tool is large, the context window will expand rapidly, resulting in excessive consumption of token resources and increased inference latency; on the other hand, when large language models process long texts or unstructured data, they are prone to information omission, truncation or illusion, leading to mismatch or distortion of input parameters for downstream tools.

[0004] Furthermore, when the data structures of upstream and downstream tools do not match, existing technologies often rely on models for implicit text inference and format conversion, lacking a deterministic intermediate processing mechanism, which further reduces the success rate of multi-step calls and the stability of the system. Summary of the Invention

[0005] To address the issues of low data flow efficiency and poor parameter transmission accuracy in existing multi-step tool calls, and to achieve decoupling of intermediate results from the model context and deterministic transformation of data structures, thereby reducing resource consumption and improving execution stability, this application provides a multi-step tool call data processing method and system based on a large language model.

[0006] Firstly, this application provides a multi-step tool-calling data processing method based on a large language model, employing the following technical solution: A multi-step tool invocation data processing method based on a large language model includes: In response to a call instruction for a first tool, the first tool is executed to obtain a first complete result, the first complete result including the complete output data generated after the execution of the first tool; Write the first complete result to a runtime storage area independent of the large language model context, and generate the corresponding first reference identifier; Return a result summary of the first complete result and the first reference identifier to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary; In response to the inclusion of the first reference identifier in the call parameters, the second tool is controlled to read the first complete result from the runtime storage area through the first reference identifier.

[0007] By adopting the above technical solution, a runtime storage area independent of the large language model context is established. The tool output is saved in the same standard structure and the summary and citation identifiers are used as stable indexes. This enables intermediate results to be reused, tracked and verified in the current execution process, thus achieving physical decoupling of data flow and model inference. At the same time, since the downstream tool reads the upstream results from the runtime storage area through the citation identifiers instead of relying on the natural language context, the accuracy of parameter passing is significantly improved and the token consumption is reduced.

[0008] In one specific implementation, the result summary of the first complete result and the first citation identifier are returned to the large language model, including: The first complete result is cropped based on a preset truncation rule to generate a result summary that includes some preview data; Controlling the second tool to read the first complete result from the runtime storage area via the first reference identifier includes: In response to the read request from the second tool, a compatibility check is performed on the first complete result based on the output structure description or metadata recorded in the runtime storage area. If the verification passes, the first complete result is unpacked to extract the real data for the second tool to consume.

[0009] By adopting the above technical solution, a truncation rule is used to generate a summary after the tool is executed, returning only a partial preview data instead of the complete result, effectively controlling the context bloat of large language models. Through the linkage control of summary generation and on-demand unpacking, invalid data is further restricted from entering the context while ensuring that the model has the necessary perception capabilities. At the same time, downstream tools perform compatibility checks and unpacking processing when reading results, ensuring that the data structure matches before consumption, avoiding execution errors caused by structure mismatch.

[0010] In one specific implementation, the reference identifier included in the call parameters includes at least one of the following reference patterns: The single-result global reference mode is used to specify the storage index of a single tool execution result in the runtime storage area; A parameter-level source reference mode is used to indicate that the value of a specific input parameter of the second tool originates from a specified result in the runtime storage area; The dataset array reference mode is used in structured analysis scenarios to reference multiple saved results in the runtime storage area through an array of dataset description items, in order to combine them into the input dataset of the analysis engine.

[0011] By adopting the above technical solutions, the three referencing modes cover typical scenarios such as single result referencing, parameter-level referencing, and batch dataset referencing, providing a unified, lightweight, and verifiable referencing method for cross-tool data transfer, enabling downstream tools to flexibly consume upstream results.

[0012] In one specific implementation, the parameter-level source reference mode adopts a naming rule of parameter name followed by reference suffix, which is used to indicate that the value of the corresponding input parameter comes from the output data of the corresponding reference identifier in the runtime storage area.

[0013] By adopting the above technical solution, the parameter-level source reference pattern enables downstream tools to clearly identify which parameter values ​​come from the results in the runtime storage area rather than directly passed constant values ​​through standardized naming rules, thereby improving the readability and maintainability of parameter passing.

[0014] In one specific implementation, in the dataset array reference pattern, each dataset description item includes at least: a reference identifier field, corresponding to the saved result name; and a dataset name field, used to display the dataset name during analysis.

[0015] By adopting the above technical solution, the dataset array reference mode supports referencing multiple saved results through the reference identifier array in structured analysis scenarios. After the analysis tool traverses the array, it reads the corresponding data from the runtime storage area, supporting flexible referencing and analysis of large-scale datasets.

[0016] In a specific feasible implementation, field extraction operations are also included: When the output data structure of the first tool does not match the input data structure of the second tool, a field extraction operation is performed. The field extraction operation includes: determining the target field and extracting target data from the first complete result based on the target field, so as to serve as the input of the second tool or generate a new reference identifier.

[0017] By adopting the above technical solution, the data structure transformation and adaptation were achieved by identifying target fields and extracting target data. Field extraction was completed by independent operations, rather than by the model manually copying data from the preview text. By replacing the model's implicit inference with explicit field extraction operations, the error rate of field extraction was significantly reduced, ensuring the determinism of data transfer across tools.

[0018] In one specific implementation, the field extraction operation includes: In the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the field semantics of the first complete result; During the deterministic extraction execution phase, the first complete result is read from the runtime storage area according to the target field, the record list in the first complete result is traversed to extract the field value corresponding to the target field, and the extracted field value is deduplicated and nulled to obtain the target data. The target data is saved to the runtime storage area, and a corresponding new reference identifier is generated and returned to the large language model.

[0019] By adopting the above technical solution, the field extraction process is decoupled into two stages: semantic decision-making and deterministic execution. This avoids the uncertainty caused by the model directly processing the raw data and ensures the accuracy of the data transformation results. Since semantic alignment decisions can be completed in various ways, such as by a large language model or a predefined mapping table, and the deterministic extraction execution stage runs independently, the system can maintain stable field extraction performance in different scenarios.

[0020] In one specific implementation scheme, during the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the field semantics of the first complete result, including at least one of the following implementation methods: The large language model is used for inference to determine the target field name: the parameter description document of the second tool, the structural summary of the first complete result, and the field structure of the saved result are used as the inference context input to the large language model, and the large language model outputs the name of the target field. Determined by matching according to predefined rules: Query a predefined field mapping table, which records the mapping relationship between downstream parameter names and upstream field names, and directly match the target field based on the mapping relationship; Domain-specific dictionary matching: Using a thesaurus or pattern matching rules for a specific business domain, the similarity between the semantics of the input parameters and the semantics of the fields is calculated, and the fields whose similarity meets a preset threshold are determined as the target fields.

[0021] By adopting the above technical solutions, semantic alignment decision-making offers multiple implementation methods, which can be flexibly selected according to the actual scenario. It uses large language model inference to determine suitability for unknown scenarios, predefined rule matching to determine suitability for known mapping relationships, and domain dictionary matching to determine suitability for specific industry domains. These multiple methods complement each other, balancing flexibility in open scenarios with engineering stability in closed scenarios.

[0022] In a specific feasible implementation, the architecture applied to a collaborative architecture that includes a routing layer and an execution layer also includes: The routing layer receives user requests, identifies the task category to which the user request belongs, and delegates the user request to the corresponding target execution unit based on the task category. The target execution unit, as part of the execution layer, independently executes a tool call loop around the runtime storage area, including data query, field extraction, structured analysis, and conclusion generation. After the loop is completed, it returns the final result to the routing layer for output. The routing layer does not directly mount the business query tool; it is only responsible for task identification, execution unit selection, and task delegation.

[0023] By adopting the above technical solution, the decoupling design of the routing layer and the execution layer enables different types of tasks to complete data loops around a shared runtime storage area within independent execution units, thereby improving the system's scalability and concurrent processing capabilities. Since the routing layer does not directly mount complex business query tools but is only responsible for task identification and execution unit selection, the system architecture is clearer, and each execution unit can be developed and optimized independently.

[0024] Secondly, this application provides a multi-step tool-calling data processing system based on a large language model, employing the following technical solution: A multi-step tool invocation data processing system based on a large language model includes: A tool execution module is configured to execute the first tool in response to a call instruction from the first tool to obtain a first complete result; The storage management module is used to write the first complete result into a runtime storage area independent of the large language model context, and generate a corresponding first reference identifier; The summary return module is used to return a result summary of the first complete result and the first reference identifier to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary; The data reading module is used to control the second tool to read the first complete result from the runtime storage area through the first reference identifier in response to the call parameters containing the first reference identifier.

[0025] In a specific feasible implementation, it also includes: The field extraction module is used to perform a field extraction operation when the output data structure of the first tool does not match the input data structure of the second tool. The field extraction operation includes: determining a target field and extracting target data from the first complete result based on the target field, so as to serve as the input of the second tool or generate a new reference identifier.

[0026] Thirdly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above, a multi-step tool-calling data processing method based on a large language model.

[0027] In summary, this application includes at least one of the following beneficial technical effects: By establishing a runtime storage area independent of the large language model context, and writing the complete results of tool execution to this storage area instead of directly backfeeding the model, the path of large data volume crowding out the context window is cut off from the physical level; and combined with the return mechanism of summary and citation identifier, the model only needs to consume a very small number of tokens to perceive the data overview and generate the correct citation parameters, thereby significantly reducing resource consumption and inference latency in the multi-step tool call process. By introducing field extraction operations, the implicit data structure transformation that relies on large language models in traditional technologies is transformed into a deterministic programmatic processing flow. Through a two-stage separation design of semantic alignment decision and deterministic extraction execution, the flexibility of the model in semantic understanding is preserved, while the precision of code execution in data processing is utilized. This effectively eliminates parameter mismatch problems caused by model illusion or text truncation, and significantly improves the success rate and reliability of complex data analysis processes. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating the multi-step tool call data processing method based on a large language model in Embodiment 1 of this application. Detailed Implementation

[0029] The following is in conjunction with the appendix Figure 1 This application will be described in further detail.

[0030] Example 1

[0031] This embodiment discloses a multi-step tool call data processing method based on a large language model.

[0032] Reference Figure 1 The multi-step tool invocation data processing method based on a large language model includes the following steps: S100: In response to the call instruction of the first tool, execute the first tool to obtain a first complete result, the first complete result including the complete output data generated after the execution of the first tool.

[0033] In this embodiment, the first tool can be any external functional unit invoked by the large language model, such as a data query interface, file parser, or API service. When the large language model generates an invocation instruction for the first tool according to the task plan, the system intercepts the instruction and triggers the actual execution of the first tool. The first complete result is the raw, unpruned, full data returned after the execution of the first tool, which may contain a large number of record entries, nested structures, or binary content. For example, in a general data analysis scenario, the first complete result may be a first object collection containing hundreds of records, each containing multiple attribute fields. It should be understood that although this embodiment uses structured data as an example, in other implementations, the first complete result can also be unstructured text, image data, or streaming data, as long as its data volume or complexity is sufficient to burden the context window of the large language model.

[0034] S200: Write the first complete result to the runtime storage area independent of the large language model context, and generate the corresponding first reference identifier.

[0035] Specifically, the runtime storage area is a dedicated data temporary storage space allocated by the system in memory or cache, which is completely isolated from the context window of the large language model in terms of physical address and logical management. Before executing data processing tasks, the system first establishes a runtime storage area during system runtime. The runtime storage area preferably uses a key-value mapping structure, specifically implemented using a character-based data structure, where reference identifiers serve as keys and result entries serve as values. The runtime storage area is used to store intermediate and analysis results from the current thread, current session, or current task context, and it is independent of the context of the large language model.

[0036] While writing the first complete result, the system generates a globally unique or session-unique first reference identifier, which serves as an address key pointing to a specific data block in the runtime storage area. For example, the first reference identifier can be a UUID string or an auto-incrementing index number. This physical isolation mechanism fundamentally cuts off the path for large amounts of data to be fed back into the model, making the token consumption of the model context only related to the task logic and decoupled from the data scale of intermediate results. This significantly reduces resource overhead and avoids the attention distraction problem caused by excessively long contexts.

[0037] After execution, the first tool in the upstream does not directly rely on the natural language context to pass the first complete result. Instead, it first encapsulates the first complete result according to a unified structure and then writes it to the runtime storage area with the first reference identifier as the index. If any downstream second tool needs to consume the output result of the upstream first tool, it reads the required result from the runtime storage area through the first reference identifier and performs unpacking, field extraction, type validation and structure adaptation when necessary.

[0038] In this embodiment, each result entry in the runtime storage area is encapsulated using a standardized data structure. Specifically, each result entry includes at least the following fields: a source tool identifier field, used to identify the name of the source tool that generated the result; a save time field, used to record the timestamp of the result entry being written to the storage area; an execution status field, used to identify the execution status of the result entry, whose values ​​include success, error, pending, or timeout; an actual output data field, used to store the complete output data generated after the tool execution; an output structure description field, used to describe the result type, element structure, field composition, or result purpose, so that downstream tools can perform structure adaptation when reading; a metadata field, used to record additional information such as time range, object range, source description, confidence level, freshness, and result type; and an error information field, used to record error details when the tool execution fails, including error code and stack summary information. This field is null when the tool execution succeeds.

[0039] S300: Returns a result summary and a first reference identifier of the first complete result to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary.

[0040] Specifically, after the upstream first tool saves the first complete result to the runtime storage area, the system does not directly feed the first complete result back to the model. Instead, it generates a lightweight result summary. At the same time, the first citation identifier is returned as a structured parameter. The result summary only contains meta-information or preview fragments sufficient for a large language model to understand the data overview, type, and statistical characteristics, such as the total number of records, a list of field names, or a sample preview of the first N data points. It does not contain the complete entity data used for subsequent calculations, allowing the model to perceive the data state with minimal token consumption. This avoids the problem of degraded inference performance or distraction caused by the context window being filled with massive intermediate results.

[0041] Furthermore, a result summary and a first citation identifier of the first complete result are returned to the large language model, including pruning the first complete result based on preset truncation rules to generate a result summary containing partial preview data.

[0042] Specifically, the preset truncation rules are not simply text length limits, but rather multi-dimensional strategies that can be dynamically configured based on data type. For example, for list-type data, the truncation rule can be set to retain the top K records and the total number of records; for dictionary or object-type data, it can be set to retain all key names and their corresponding value type signatures, but omit the actual long text values ​​or binary content; for extremely large data sets, a strict byte threshold can be set, with any excess automatically folded. This pruning mechanism ensures that the resulting summary contains only metadata sufficient for a large language model to understand the data overview, field structure, and sample characteristics, while keeping the real business data, which constitutes the majority of tokens, outside the model context.

[0043] After receiving the result summary and the first reference identifier, the large language model can perform semantic parsing on the result summary to form an understanding of the current data state, and incorporate the first reference identifier as an addressing credential pointing to the data entity into its reasoning context. Subsequently, the large language model combines the original task objective, the understanding of the current data state, and the function signature definition of available tools, and determines the second tool to be called next and its parameter configuration through chained reasoning. The first reference identifier is directly filled into the generated second tool call parameters, rather than attempting to extract specific data values ​​from the summary text. This allows the model to complete state perception and decision-making with minimal token consumption, and completely eliminates the risk of hallucination or truncation errors caused by copying long texts. It should be understood that the above parameter generation process is a reasoning behavior naturally completed by the large language model based on its pre-trained knowledge and tool calling capabilities. This invention does not limit the inference algorithm inside the model, but provides a low-noise, high-determinism input environment for the model's parameter generation process by constructing an external data flow protocol for summary return and reference identifier transmission, thereby enabling the model to complete the generation of call parameters with higher accuracy and lower resource consumption.

[0044] S400: In response to the fact that the call parameters contain a first reference identifier, control the second tool to read the first complete result from the runtime storage area through the first reference identifier.

[0045] After the large language model generates call parameters containing the first reference identifier, the system identifies the reference identifier in the call parameters before or during the dispatch of the call request to the second tool, and parses it as a direct read request to the runtime storage area. The second tool directly obtains a copy of the original data of the first complete result or an access handle from the runtime storage area through the reference identifier. The entire process completely bypasses the context window of the large language model, ensuring that even if the first complete result is on the order of megabytes, the downstream second tool can obtain the complete input without loss and with low latency, thus guaranteeing the data integrity of the multi-step call chain.

[0046] Furthermore, controlling the second tool to read the first complete result from the runtime storage area through the first reference identifier includes, in response to the second tool's read request, performing a compatibility check on the first complete result based on the output structure description or metadata recorded in the runtime storage area; if the check passes, unpacking the first complete result to extract the real data for the second tool to consume.

[0047] Because the data in the runtime storage area is written asynchronously by the upstream first tool, its actual structure may differ from the expectations of the downstream second tool. When responding to a read request, the system first reads the output structure description or metadata attached to the result entry and compares it with the input parameter schema declared by the second tool. For example, if the second tool expects to receive a list of strings, but the structure description of the corresponding entry in the storage area shows that it is a collection of nested objects, the verification fails. The system can directly return a structured error message or trigger automatic conversion logic, rather than passing erroneous data into the tool and causing runtime exceptions. Only after the verification passes will the system perform the unpacking operation, that is, peeling off the original business data payload from the standardized storage encapsulation object, thereby effectively preventing link interruptions caused by data type mismatches and improving the robustness and observability of multi-step tool calls.

[0048] In addition, to adapt to tool invocation scenarios of varying complexity, the reference identifiers included in the invocation parameters include at least one of the following reference patterns: The single-result global reference mode is used to specify the storage index of a single tool execution result in the runtime storage area. In some read-type tools, it can also represent the source name of the input result.

[0049] The parameter-level source reference mode is used to indicate that the value of a specific input parameter of the second tool comes from a specified result in the runtime storage area. The parameter-level source reference mode adopts the naming rule of parameter name followed by reference suffix, which is used to indicate that the value of the corresponding input parameter comes from the output data of the corresponding reference identifier in the runtime storage area.

[0050] The dataset array reference mode is used in structured analysis scenarios to reference multiple saved results in the runtime storage area through an array of dataset description items, in order to combine them into the input dataset for the analysis engine. Each dataset description item includes at least: a reference identifier field, corresponding to the name of the saved result; and a dataset name field, used to display the dataset name during analysis.

[0051] It is important to emphasize that, regardless of the referencing pattern used, the referencing identifier is essentially an address key pointing to the physical address or logical index of the runtime storage area, not a text variable generated by the large language model. The model only needs to fill in this key value in the parameter slot, and the system can complete the precise routing and injection of data at the underlying level.

[0052] Specifically, the single-result overall reference mode is suitable for scenarios where there is a one-to-one data transfer between upstream and downstream tools. For example, when the second tool needs to consume the complete output of the first tool, its call parameters directly include the first reference identifier, and the system loads the entire result entry and passes it to the second tool accordingly.

[0053] The parameter-level source referencing pattern solves the problem of finer-grained parameter binding. In some scenarios, a specific parameter of the second tool is not generated by the model in real time, but comes directly from a specific field or the entire content of an upstream result. In this case, a specific key name can be used in the call parameter to point to the corresponding entry in the runtime storage area. When the system parses the call parameter, it recognizes that the key name conforms to the predefined referencing protocol format, and automatically reads the data from the storage area and fills it into the parameter position, thus eliminating the illusionary risk that may arise from the model manually extracting data.

[0054] The dataset array reference pattern is a high-level abstraction for complex analysis tasks. In scenarios requiring multi-dimensional comparison or aggregation analysis, the analysis engine often needs to receive multiple datasets as input simultaneously. In this case, the call parameters include an array of dataset description items. Each element in the array does not directly carry data but contains a reference identifier pointing to the runtime storage area and an optional dataset alias. When the second tool (i.e., the analysis tool) receives this parameter, the system iterates through the array, sequentially locating and reading the corresponding result entry from the runtime storage area based on the reference identifier in each element. It then unpacks the entry and converts it into a standard data structure recognizable by the analysis engine (such as key-value pairs containing names and data bodies) according to preset specifications. Finally, multiple discrete historical results are dynamically assembled into a complete input dataset and sent to the analysis engine. This pattern allows large language models to handle large-scale, multi-source heterogeneous data without needing to understand complex data concatenation logic; they only need to orchestrate reference identifiers to complete the scheduling and analysis of large-scale, multi-source heterogeneous data, greatly expanding the capabilities of the tool call framework in handling complex data analysis tasks. It should be understood that the above three reference patterns can be used individually or in combination within the same call request to adapt to flexible and changing business needs.

[0055] Example 2

[0056] In practical multi-step tool calls, data contracts between upstream and downstream tools often differ. Existing technologies typically rely on large language models to read the complete results and then manually concatenate parameters, which is prone to errors. This embodiment explicitly presents this transformation process as an independent field extraction operation. Building upon Embodiment 1, this embodiment further details the internal execution logic of the field extraction operation.

[0057] When the output data structure of the first tool does not match the input data structure of the second tool, a field extraction operation is performed. The field extraction operation includes: determining the target field and extracting target data from the first complete result based on the target field, so as to serve as the input of the second tool or generate a new reference identifier.

[0058] Specifically, the field extraction operation includes: In the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the field semantics of the first complete result; During the deterministic extraction execution phase, the first complete result is read from the runtime storage area according to the target field. The record list in the first complete result is traversed to extract the field value corresponding to the target field. The extracted field value is then deduplicated and nulled to obtain the target data. The target data is saved to the runtime storage area, and a corresponding new reference identifier is generated and returned to the large language model.

[0059] During the semantic alignment decision-making phase, the system does not expose the original data payload of the first complete result to the decision-maker. Instead, it only uses the structural summary of the first complete result and the parameter description document of the second tool as the input context. Its output is only one or more standardized target field names, without containing any actual business data values. This restricts the highly uncertain semantic understanding task to the lightweight metadata level, which avoids the waste of token resources caused by transmitting the full amount of data and effectively prevents the decision-maker from being distracted by massive amounts of irrelevant data, thereby significantly improving the accuracy and response speed of field matching.

[0060] The deterministic extraction execution phase is a completely deterministic data-level operation. The execution entity for this phase is typically a pre-built code interpreter, data processing script, or dedicated ETL engine, rather than a probabilistic large language model. Using the target field name output from the previous phase as the address key, the system directly loads a copy of the original data from the runtime storage area, and iterates, projects, and filters the record list through deterministic program logic. During this process, the system also automatically executes data cleaning strategies, such as removing duplicate field values, filtering out empty strings or null values, and correcting data type formats, ultimately outputting a target data set that conforms to the input specifications of the second tool. Because the deterministic extraction execution phase completely eliminates the uncertainty of natural language inference, its execution results have strict reproducibility and accuracy, fundamentally eliminating the risks of illusions, truncation, or format mismatches caused by model copying data in traditional solutions.

[0061] This embodiment transforms data structure transformation from implicit reasoning in the model to two independent explicit execution stages: the semantic alignment decision stage and the deterministic extraction execution stage. By using the determinism of code execution to replace the fuzzy inference of the probabilistic model, it significantly improves the accuracy of parameter passing and the robustness of the system in complex data analysis links.

[0062] Finally, the target data obtained after the deterministic extraction execution phase is not directly injected into downstream tools as temporary variables, but is treated as a new independent data asset. It is written to the runtime storage area according to the standard encapsulation protocol described in the previous embodiment and assigned a new reference identifier. Upon receiving this new reference identifier, the large language model can use it as the basis for parameter passing in subsequent steps. This means that the field extraction result itself is also incorporated into a unified reference management system, which can be consumed by the current second tool or reused on demand by other downstream tools in the chain, thereby ensuring the consistency and traceability of data flow throughout the entire data processing chain. It should be understood that although this embodiment uses a two-stage serial execution as an example, in other implementations, if the target field has been predefined through a configuration file or directly specified through static rules, the system can also skip the semantic alignment decision phase and directly enter the deterministic extraction execution phase to adapt to application scenarios that are sensitive to latency or have highly fixed structures.

[0063] Furthermore, in the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the semantics of the fields of the first complete result, including at least one of the following implementation methods: determining by reasoning through a large language model, determining by matching through predefined rules, or determining by matching through a domain dictionary.

[0064] Inference is determined using a large language model: the parameter description document of the second tool, the structural summary of the first complete result, and the field structure of the saved result are used as the inference context input to the large language model, and the large language model outputs the name of the target field.

[0065] In this process, the context input to the model is strictly limited to the metadata level, excluding the actual business data values ​​from the first complete result. For example, the system constructs structured prompt templates to guide the model to focus on semantic relationship analysis between field names. Because it only needs to process lightweight structural description information, the token consumption of the inference process is extremely low and the response speed is fast, while effectively preventing the risk of attention distraction or privacy leakage caused by the model being exposed to a large amount of irrelevant data.

[0066] Determining the target field through predefined rule matching: Query the predefined field mapping table, which records the mapping relationship between downstream parameter names and upstream field names, and directly match the target field based on the mapping relationship.

[0067] Field mapping tables are typically stored as key-value pairs, where the key is a standardized parameter identifier for the second tool, and the value is the corresponding upstream field path or alias set. During matching, the system prioritizes finding exact matches; if no match is found, it can further attempt regular expression matching or wildcard matching. Once a match is successful, the system immediately returns the target field name. The entire process requires no calls to any external model services, offering millisecond-level response speed and 100% determinism. Furthermore, this approach supports a configurable fallback mechanism. When a corresponding entry is not found in the mapping table, a fallback strategy is automatically triggered, switching to requesting large model inference or logging pending manual confirmation, thus ensuring system availability even with incomplete rule coverage.

[0068] Domain-specific dictionary matching: Using a thesaurus or pattern matching rules for a specific business domain, the similarity between the semantics of the input parameters and the semantics of the fields is calculated, and the fields whose similarity meets a preset threshold are identified as target fields.

[0069] The domain dictionary not only includes standard thesaurus mappings but can also include semantic indexes based on vector embeddings. When calculating similarity, the system can comprehensively consider multiple metrics such as string edit distance, Jaccard similarity coefficient, or semantic vector cosine similarity, and set dynamic or static confidence thresholds. A match is considered valid only when the highest similarity score exceeds this threshold; otherwise, it is considered a failed match and proceeds to the next priority strategy.

[0070] Example 3

[0071] Building upon Embodiments 1 and 2, this embodiment further details the system architecture supporting multi-step tool invocation. As one implementation method, the multi-step tool invocation data processing method based on a large language model is applied to a collaborative architecture that includes a routing layer and an execution layer.

[0072] The routing layer receives user requests, identifies the task category to which the user request belongs, and delegates the user request to the corresponding target execution unit based on the task category.

[0073] Upon receiving a user request, the routing layer first uses an intent recognition model or rule engine to parse the request semantics and categorize it into a predefined task type (such as general query, anomaly detection, trend analysis, etc.). Then, based on a pre-defined routing strategy table, the routing layer encapsulates the request into a standardized task instruction package and sends it to the target execution unit matching the task type. During this process, the routing layer only transmits the task description, context parameters, and necessary authentication information; it never carries any business entity data or historical intermediate results.

[0074] Furthermore, the target execution unit, as part of the execution layer, independently executes a closed loop of tool calls around the runtime storage area, including data querying, field extraction, structured analysis, and conclusion generation. After the closed loop is completed, the final result is returned to the routing layer for output.

[0075] Upon receiving a task instruction from the routing layer, the target execution unit obtains an access handle or scope identifier pointing to the runtime storage area. The access handle restricts the execution unit's read and write permissions to the runtime storage area within the current task's lifecycle, ensuring data isolation security while providing a channel for cross-step data sharing. During the execution loop, whether it's the raw dataset obtained by the query tool, the identifier list generated by the field extraction tool, or the statistical reports produced by the analysis tool, all are written to the runtime storage subspace pointed to by the access handle. Subsequent steps directly read the previous results from this subspace using the reference identifier. The entire data flow is completed within the execution layer, without needing to send intermediate data back to the routing layer or serialize it into the context window of the large language model. Only when all processing steps are completed and a final response is generated for the user will the execution unit return the final result (usually lightweight data that has been summarized or formatted) to the routing layer for unified external output.

[0076] In traditional architectures, the routing layer often integrates numerous tool interfaces, resulting in a large codebase, complex dependencies, and difficult upgrades. In this embodiment, however, the routing layer does not directly mount business query tools; it is only responsible for task identification, execution unit selection, and task delegation. When a new data analysis capability needs to be added or a new external data source needs to be connected, only a new target execution unit needs to be deployed and registered with the routing layer; no modification to the routing layer's code or a service restart is required.

[0077] Example 4

[0078] This embodiment uses a specific business scenario in the heating industry—where an intelligent agent queries the energy consumption of a subordinate center of an operations department for a certain month compared to the same period last year and draws a conclusion—to illustrate the complete execution flow of the system in detail. It should be understood that this embodiment is merely an illustrative example, intended to verify the effectiveness of the aforementioned general technical solutions in solving specific technical problems, and does not constitute a limitation on the scope of protection of this invention. In this embodiment, the system adopts the collaborative architecture described in the foregoing embodiments, which includes a routing layer and an execution layer, and completes the data flow loop around a runtime storage area independent of the large language model context.

[0079] After receiving a data analysis task request from a user, the routing layer identifies that the request belongs to the general heating data analysis task category. The routing layer does not directly execute specific business query operations; instead, it is responsible for category identification and execution unit selection, delegating the data processing task to the corresponding general data analysis execution unit. Once the execution unit receives the task, it calls the organizational query tool to retrieve a list of records from all centers under that operations department; this list constitutes the first complete result.

[0080] The execution unit writes the first complete result to the runtime storage area and generates a corresponding first reference identifier. Simultaneously, it returns a result summary and the first reference identifier to the large language model, containing only the total number of records, a list of field names, and previews of the first three samples. In a specific implementation, the first complete result may contain hundreds of central records, each with more than ten attribute fields. Directly feeding this data back into the model would consume thousands of tokens. However, through the summary return mechanism in this embodiment, the model only needs to consume approximately 50 tokens to perceive the data overview and obtain the reference credentials, reducing the resource consumption of the context window by approximately 98%.

[0081] Because the downstream energy consumption statistics tool requires a list of center name strings, while the upstream output is a collection of objects containing multi-dimensional attributes, the data structures of the two are mismatched, and the system automatically triggers a field extraction operation. First, in the semantic alignment decision stage, the system inputs the parameter description document of the downstream tool and the structural summary of the upstream results into the large language model. The model determines the target field as "dept_name" based on metadata inference. Subsequently, in the deterministic extraction execution stage, the system reads the first complete result from the runtime storage area according to the target field name, traverses the record list to extract the "dept_name" field value, and performs deduplication and empty removal processing to obtain a clean list of center names, which is saved as a new naming result and a second reference identifier is generated.

[0082] The large language model generates a call command for the energy consumption statistics tool based on the second reference identifier. The system controls the tool to directly read the list of center names from the runtime storage area through the second reference identifier, and query the energy consumption data for this month and the same period last year respectively. The two complete energy consumption datasets are written to the runtime storage area in sequence, generating the third reference identifier and the fourth reference identifier.

[0083] The large language model generates calling parameters for the structured analysis tool. These parameters include an array of descriptive items representing the dataset array reference pattern, with two elements pointing to the third and fourth reference identifiers, respectively. Upon receiving these parameters, the analysis tool iterates through the descriptive item array, sequentially locating and unpacking the two energy consumption datasets from runtime storage, converting them into a standard input format recognizable by the analysis engine, executing year-on-year calculations and anomaly detection algorithms, and ultimately generating an analysis report containing comparative charts and business insights.

[0084] It should be understood that although this embodiment takes a data analysis scenario as an example, the technical solution of this application can also be adopted in other embodiments and other application scenarios, as long as it involves multi-step tool calls, multi-agent collaboration, or the management and transmission of intermediate results in complex data processing links. This application does not impose strict limitations on this.

[0085] Example 5

[0086] This embodiment discloses a multi-step tool call data processing system based on a large language model. The system in this embodiment is a physical embodiment of Embodiment 1, and its modular architecture design ensures the complete implementation of the technical solution at the product level.

[0087] A multi-step tool call data processing system based on a large language model includes a tool execution module, a storage management module, a summary return module, a data reading module, and a field extraction module.

[0088] The tool execution module is used to execute the first tool in response to the call command of the first tool to obtain the first complete result.

[0089] When a call instruction is received from a large language model or other scheduling components, the tool execution module is responsible for parsing the instruction parameters, establishing connections with external APIs or local functions, handling authentication and network requests, and encapsulating the raw response returned from the external source into a first complete result object in a unified format within the system.

[0090] The storage management module is used to write the first complete result to a runtime storage area independent of the large language model context and generate the corresponding first reference identifier.

[0091] The storage management module manages the runtime storage area, ensuring its complete isolation from the inference context of the large language model in both address space and management logic. Upon receiving the first complete result from the tool execution module, the storage management module serializes it and stores it in the runtime storage area, creating a first reference identifier using a built-in unique ID generator. Simultaneously, the storage management module maintains the lifecycle state of result entries, provides reference identifiers and metadata interfaces to the summary return module, and offers efficient addressing and retrieval services to the data reading module.

[0092] The summary return module is used to return a result summary and a first citation identifier of the first complete result to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary.

[0093] The summary return module retrieves the metadata and preview fragments of the result entries from the storage management module and dynamically generates a lightweight result summary based on a preset truncation strategy. The result summary retains only the structural features and statistical information sufficient to support the model's next decision, while shielding the full dataset from the model's view. Subsequently, the summary return module assembles the result summary and the first citation identifier into a standardized feedback message and sends it to the large language model.

[0094] The data reading module is used to control the second tool to read the first complete result from the runtime storage area in response to the first reference identifier contained in the call parameters.

[0095] When a valid reference identifier is detected in the call parameters of a downstream tool, the data reading module directly intercepts the request and transforms it into a native read operation on the runtime storage area. Before executing the read, the data reading module can also perform compatibility checks and unpack the target data as needed according to the preset schema definition to ensure that the data passed to the second tool strictly conforms to its input contract.

[0096] The field extraction module is used to perform a field extraction operation when the output data structure of the first tool does not match the input data structure of the second tool. The field extraction operation includes: determining the target field and extracting target data from the first complete result based on the target field, so as to serve as the input of the second tool or generate a new reference identifier. The field extraction module comprises a semantic alignment subunit and a deterministic execution subunit. When the system determines a difference between upstream and downstream structures, the field extraction module is activated. First, the semantic alignment subunit determines the target field name based on metadata reasoning or rule matching. Then, the deterministic execution subunit loads the original data from the runtime storage area based on this field name and extracts the target data through procedural logic such as traversal, projection, and deduplication. The extracted target data can be directly injected into downstream tools or saved as a new named result by the storage management module.

[0097] Example 6

[0098] This embodiment discloses a computer device.

[0099] Specifically, the computer device includes a memory and a processor, the memory storing a computer program that can be loaded by the processor and executed any of the aforementioned multi-step tool-calling data processing methods based on a large language model.

[0100] This application also discloses a computer-readable storage medium.

[0101] Specifically, the computer-readable storage medium stores a computer program that can be loaded and executed by a processor, such as any of the multi-step tool call data processing methods based on a large language model as described above. The computer-readable storage medium includes, for example, various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0102] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of the claims of the present invention.

Claims

1. A multi-step tool invocation data processing method based on a large language model, characterized in that, include: In response to a call instruction for a first tool, the first tool is executed to obtain a first complete result, the first complete result including the complete output data generated after the execution of the first tool; Write the first complete result to a runtime storage area independent of the large language model context, and generate the corresponding first reference identifier; Return a result summary of the first complete result and the first reference identifier to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary; In response to the inclusion of the first reference identifier in the call parameters, the second tool is controlled to read the first complete result from the runtime storage area through the first reference identifier.

2. The multi-step tool invocation data processing method based on a large language model according to claim 1, characterized in that, Returning a result summary of the first complete result and the first citation identifier to the large language model, including: The first complete result is cropped based on a preset truncation rule to generate a result summary that includes some preview data; Controlling the second tool to read the first complete result from the runtime storage area via the first reference identifier includes: In response to the read request from the second tool, a compatibility check is performed on the first complete result based on the output structure description or metadata recorded in the runtime storage area. If the verification passes, the first complete result is unpacked to extract the real data for the second tool to consume.

3. The multi-step tool invocation data processing method based on a large language model according to claim 1, characterized in that, The reference identifier included in the call parameters includes at least one of the following reference patterns: The single-result global reference mode is used to specify the storage index of a single tool execution result in the runtime storage area; A parameter-level source reference mode is used to indicate that the value of a specific input parameter of the second tool originates from a specified result in the runtime storage area; The dataset array reference mode is used in structured analysis scenarios to reference multiple saved results in the runtime storage area through an array of dataset description items, in order to combine them into the input dataset of the analysis engine.

4. The multi-step tool invocation data processing method based on a large language model according to claim 3, characterized in that, The parameter-level source reference mode adopts a naming rule of parameter name followed by reference suffix, which is used to indicate that the value of the corresponding input parameter comes from the output data of the corresponding reference identifier in the runtime storage area.

5. The multi-step tool invocation data processing method based on a large language model according to claim 3, characterized in that, In the dataset array reference mode, each dataset description item includes at least: a reference identifier field, corresponding to the saved result name; and a dataset name field, used to display the dataset name during analysis.

6. The multi-step tool invocation data processing method based on a large language model according to claim 1, characterized in that, It also includes field extraction operations: When the output data structure of the first tool does not match the input data structure of the second tool, a field extraction operation is performed. The field extraction operation includes: determining the target field and extracting target data from the first complete result based on the target field, so as to serve as the input of the second tool or generate a new reference identifier.

7. The multi-step tool invocation data processing method based on a large language model according to claim 6, characterized in that, The field extraction operation includes: In the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the field semantics of the first complete result; During the deterministic extraction execution phase, the first complete result is read from the runtime storage area according to the target field, the record list in the first complete result is traversed to extract the field value corresponding to the target field, and the extracted field value is deduplicated and nulled to obtain the target data. The target data is saved to the runtime storage area, and a corresponding new reference identifier is generated and returned to the large language model.

8. The multi-step tool invocation data processing method based on a large language model according to claim 7, characterized in that, In the semantic alignment decision stage, the target field is determined based on the semantics of the input parameters of the second tool and the field semantics of the first complete result, including at least one of the following implementation methods: The large language model is used for inference to determine the target field name: the parameter description document of the second tool, the structural summary of the first complete result, and the field structure of the saved result are used as the inference context input to the large language model, and the large language model outputs the name of the target field. Determined by matching according to predefined rules: Query a predefined field mapping table, which records the mapping relationship between downstream parameter names and upstream field names, and directly match the target field based on the mapping relationship; Domain-specific dictionary matching: Using a thesaurus or pattern matching rules for a specific business domain, the similarity between the semantics of the input parameters and the semantics of the fields is calculated, and the fields whose similarity meets a preset threshold are determined as the target fields.

9. The multi-step tool invocation data processing method based on a large language model according to claim 1, characterized in that, Applied to collaborative architectures that include routing and execution layers, it also includes: The routing layer receives user requests, identifies the task category to which the user request belongs, and delegates the user request to the corresponding target execution unit based on the task category. The target execution unit, as part of the execution layer, independently executes a tool call loop around the runtime storage area, including data query, field extraction, structured analysis, and conclusion generation. After the loop is completed, it returns the final result to the routing layer for output. The routing layer does not directly mount the business query tool; it is only responsible for task identification, execution unit selection, and task delegation.

10. A multi-step tool call data processing system based on a large language model, characterized in that, A method for performing a multi-step tool invocation data processing method based on a large language model as described in any one of claims 1 to 9, comprising: A tool execution module is configured to execute the first tool in response to a call instruction from the first tool to obtain a first complete result; The storage management module is used to write the first complete result into a runtime storage area independent of the large language model context, and generate a corresponding first reference identifier; The summary return module is used to return a result summary of the first complete result and the first reference identifier to the large language model, so that the large language model can generate calling parameters for the second tool based on the result summary; The data reading module is used to control the second tool to read the first complete result from the runtime storage area through the first reference identifier in response to the call parameters containing the first reference identifier.

Images