Optimization Methods and Systems for Tool Calls in Large Language Models

Abstract

This invention provides a method and system for optimizing tool invocation in large language models, relating to the field of tool invocation optimization technology for large language models. The method involves obtaining the initial tool invocation planning chain generated by the large language model, decoupling its tool invocation dependencies, and constructing a parameter flow topology structure with parameter declarations as nodes. Within this topology, a set of tool identifiers without data source dependencies is detected and marked as parallel callable tool groups. The method then performs parameter binding processing on the tool input parameter declarations within each parallel callable tool group based on upstream nodes. Finally, according to the parameter flow dependency order between groups, the parameter binding instructions are arranged into a batched tool invocation instruction sequence and sent to the tool execution agent. This invention achieves parallel grouping of tools and precise parameter binding based on parameter dependency topology, improving the efficiency and reliability of tool invocation execution.

Description

Technical Field

[0001] This invention relates to the field of tool call optimization technology for large language models, and more specifically, to a tool call optimization method and system for large language models. Background Technology

[0002] When faced with complex user requests, large language models typically require external tools to perform tasks such as information retrieval, computation, and data processing, resulting in a tool call planning chain containing multiple tool invocation steps. Existing technologies primarily optimize this chain by simply rearranging the tool call order or removing redundant calls. For example, adjusting the call order based on the functional relevance between tools, or merging some calls based on estimated execution time. However, these methods only provide a rough approach at the tool functionality or time estimation level, failing to deeply analyze the data transfer and dependencies between the input parameter declarations of each tool in the tool call planning chain. They cannot identify which tool calls are truly data-coupled or which are independent from the perspective of parameter dependencies. Furthermore, existing technologies typically execute tools in the planning chain sequentially during tool calls. Even if some tool calls can be parallelized, a systematic parallel grouping mechanism is lacking, and precise data filling based on parameter dependency topology is not performed at the parameter binding level. This leads to low tool call execution efficiency and issues such as data inconsistency or dependency conflicts during parameter transfer. Summary of the Invention

[0003] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a tool invocation optimization method for large language models, the method comprising: Obtain the initial tool invocation planning chain generated by the large language model in response to the user request text sequence. The initial tool invocation planning chain contains multiple tool identifiers to be invoked arranged in execution order, and each tool identifier to be invoked is associated with a corresponding tool input parameter declaration. The initial tool call planning chain is decoupled from the tool call dependency. The parameter passing mapping relationship between the tool input parameter declarations associated with each tool identifier to be called is extracted. A parameter flow topology structure with parameter declarations as nodes is constructed. The connection edges between nodes in the parameter flow topology structure represent the data source dependency between parameter declarations. In the parameter flow topology, detect a set of tool identifiers to be invoked that have a common upstream parameter declaration node and no data source dependency between them, mark the set of tool identifiers to be invoked as a parallel callable tool group, and generate a parallel tool invocation group partitioning result. For each parallel callable tool group in the parallel tool call group partitioning result, parameter actual parameter binding processing is performed on the tool input parameter declaration. Based on the upstream parameter declaration node in the parameter flow topology, the actual parameter data body is obtained according to the tool input parameter declaration of each tool input parameter declaration. The actual parameter data body is used to replace the corresponding tool input parameter declaration to obtain the actual parameter binding tool call group instruction. Based on the parameter flow dependency order among the parallel callable tool groups in the parallel tool call group partitioning result, the actual parameter binding tool call group instructions are arranged into a batch tool call instruction sequence according to the dependency order, and the batch tool call instruction sequence is sent to the tool execution agent to trigger the parallel batch tool call operation.

[0004] Furthermore, embodiments of the present invention also provide a tool invocation optimization system for large language models, comprising: A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the aforementioned tool-invocation optimization method for large language models by executing the machine-executable instructions.

[0005] Based on the above, this paper obtains an initial tool invocation planning chain generated by a large language model, containing multiple tool identifiers to be invoked and their associated tool input parameter declarations arranged in execution order. Tool invocation dependency decoupling is then performed on this chain, extracting the parameter transfer mapping relationships between each tool input parameter declaration and constructing a parameter flow topology with parameter declarations as nodes. This structurally represents the implicit parameter data dependencies in the tool invocation planning chain in the form of an explicit topology graph, overcoming the shortcomings of existing technologies that rely solely on tool function or execution order for coarse optimization while ignoring parameter-level dependencies, resulting in insufficient parallelization recognition accuracy. Based on this topology, a set of tool identifiers to be invoked that share a common upstream parameter declaration node and have no data source dependency among themselves is detected and marked as a group of parallel callable tools. This achieves refined parallel grouping of tool invocations from the parameter dependency dimension, enabling tool invocations that were originally executed serially to be fully parallelized without violating data dependency constraints. Furthermore, parameter argument binding is performed on the tool input parameter declarations within each parallel callable tool group. The parameter data body is obtained and replaced based on the upstream parameter declaration node in the parameter flow topology, ensuring that all input parameters required by the parallel tool group during execution are filled based on a defined data source. This eliminates the risk of execution failure or data inconsistency due to unclear parameter sources during parallel execution. Finally, based on the parameter flow dependency order between parallel callable tool groups, the parameter-bound tool call group instructions are arranged into a batched tool call instruction sequence according to the dependency order and sent to the tool execution agent. This transforms the entire tool call process from the original single-chain serial execution to grouped parallel batch execution based on parameter dependency topology, significantly improving the execution efficiency, parameter passing accuracy, and call process reliability of large language model tool calls. Attached Figure Description

[0006] Figure 1 This is a schematic diagram of the execution flow of the tool call optimization method for large language models provided in the embodiments of the present invention.

[0007] Figure 2 The paper demonstrates the parameter flow topology and parallel group partitioning interface of the tool call optimization method for large language models of this invention during operation.

[0008] Figure 3 The invention demonstrates the batch scheduling sequence and redundant copy management interface during the scheduling execution phase.

[0009] Figure 4 The interactive configuration interface of this invention is shown, which involves functions such as group partitioning results, redundant copy injection, side effect virtual barrier management, and semantic equivalent parameter node replacement. Detailed Implementation

[0010] Figure 1 This is a flowchart illustrating a tool invocation optimization method for large language models provided in one embodiment of the present invention. This method can be applied to e-commerce operation automation and multi-platform collaborative processing scenarios. For example, a typical application is when catering enterprises update product information and configure operational activities across multiple online sales channels. This requires coordinating the invocation of multiple external tools, such as product management interfaces, price adjustment interfaces, inventory synchronization interfaces, marketing activity interfaces, and store display interfaces. These tools have complex data dependencies; for instance, product identifiers need to be obtained through the product creation interface, price settings depend on product identifiers, inventory synchronization depends on both product identifiers and store identifiers, and marketing activities depend on both product identifiers and price information. This method constructs a parameter flow topology, parses the data dependencies between the tools to be invoked in the initial tool invocation planning chain generated by the large language model, divides the tools into parallel executable tool groups, and arranges batch tool invocation instruction sequences according to dependency order, thereby maximizing parallel scheduling efficiency. In this embodiment, all tool invocation execution is completed in a controlled sandbox environment, strictly adhering to data security and privacy protection standards.

[0011] Step S110: Obtain the initial tool invocation planning chain generated by the large language model in response to the user request text sequence. The initial tool invocation planning chain contains multiple tool identifiers to be invoked arranged in execution order, and each tool identifier to be invoked is associated with a corresponding tool input parameter declaration.

[0012] The user request text sequence is input by the operations staff through a dialogue interface. For example, in a multi-channel new product launch scenario, the operations staff might input: "Simultaneously launch product X on platforms A, B, and C, set a unified price and inventory, configure discount activities, and synchronize display information across all stores." After receiving this user request text sequence, the large language model outputs a structured tool call plan text through an autoregressive generation method. This plan text contains all the tool call steps and their sequence required to complete the multi-channel new product launch task. Parsing this plan text yields an initial tool call plan chain, which is an ordered list data structure. Each element in the list is a description object of a tool to be called, containing a tool identifier field and a tool input parameter declaration list field. The tool identifier is a string type; for example, the identifier for the product creation tool is T1, the identifier for the price setting tool is T2, the identifier for the inventory synchronization tool is T3, the identifier for the marketing campaign creation tool is T4, the identifier for the store display synchronization tool is T5, and the identifier for the order management tool is T6. The tool input parameter declaration list field contains several parameter declaration records. Each record includes a parameter name, a parameter data type description, and a parameter source annotation. The parameter source annotation indicates whether the parameter value is provided by the output of an upstream tool or directly extracted from the user's request text. For example, T2's parameter declaration list includes a product identifier parameter, and its parameter source annotation points to the product identifier output parameter of T1; another parameter of T2 is a price value, and its parameter source annotation points to the uniform price value extracted from the user's request text. The description objects of each tool to be called in the initial tool call planning chain are arranged in the execution sequence planned by the large language model.

[0013] Step S120: Perform tool call dependency decoupling processing on the initial tool call planning chain, extract the parameter transfer mapping relationship between the tool input parameter declarations associated with each tool identifier to be called, and construct a parameter flow topology with parameter declarations as nodes. The connection edges between nodes in the parameter flow topology represent the data source dependency between parameter declarations.

[0014] Step S121: Traverse each tool identifier to be invoked in the initial tool invocation planning chain, parse the tool input parameter declaration associated with the tool identifier to be invoked, instantiate each tool input parameter declaration as a parameter node, and record the tool identifier to which the parameter node belongs as the parent tool identifier.

[0015] Iterate through each tool description object in the initial tool invocation planning chain, reading the value of the tool identifier field as the current tool identifier. For each parameter declaration record in the tool input parameter declaration list associated with the current tool identifier, create a parameter node object and assign a globally unique parameter node identifier to it. The parameter node object contains a parameter name field, a parameter data type field, and a parent tool identifier field, with the parent tool identifier field set to the current tool identifier. In the multi-channel new product launch scenario, the output parameter product identifier of the T1 product creation tool is instantiated as parameter node P1; the input parameter product identifier of the T2 price setting tool is instantiated as parameter node P2; the input parameter price value of the T2 price setting tool is instantiated as parameter node P3; the input parameter product identifier of the T3 inventory synchronization tool is instantiated as parameter node P4; the input parameter store identifier of the T3 inventory synchronization tool is instantiated as parameter node P5; the input parameter product identifier of the T4 marketing campaign creation tool is instantiated as parameter node P6; and the input parameter price information of the T4 marketing campaign creation tool is instantiated as parameter node P7. All parameter nodes are stored in a parameter node collection.

[0016] Step S122: Perform parameter source tracing and comparison processing on any two parameter nodes. When the parameter declaration represented by the first parameter node is identified as an output parameter from the parent tool identifier of the second parameter node, establish a directed connection edge from the second parameter node to the first parameter node.

[0017] Iterate through all parameter node pairs in the parameter node set. For each parameter node pair, read the parameter source annotation field of the first parameter node. If the parameter source annotation of the first parameter node indicates that the parameter value comes from the output parameter of a certain parent tool identifier, and the parent tool identifier field of the second parameter node is equal to that parent tool identifier, and the second parameter node represents the corresponding output parameter of that parent tool identifier, then create a directed connection edge from the second parameter node to the first parameter node. The directed connection edge contains two fields: the starting parameter node identifier and the ending parameter node identifier. In the multi-channel new product scenario, the parameter source annotation of parameter node P2 points to the output parameter product identifier of T1, and the parent tool identifier of parameter node P1 is T1, and P1 represents the product identifier parameter. Therefore, a directed connection edge is established from P1 to P2. Similarly, the parameter source annotation of parameter node P4 points to the output parameter product identifier of T1, and a directed connection edge is established from P1 to P4. The parameter source annotation of parameter node P6 points to the output parameter product identifier of T1, and a directed connection edge is established from P1 to P6. The parameter source label of parameter node P7 points to the output parameter price information of T2. A directed connection edge is established from the T2 output parameter node corresponding to P2 to P7.

[0018] Step S123: After instantiating all tool input parameter declarations associated with the tool identifiers to be invoked in the initial tool invocation planning chain into parameter nodes and completing the parameter source tracing and comparison process, an initial parameter flow network with parameter nodes as the basic constituent units is formed.

[0019] The initial parameter flow network uses the set of parameter nodes as the node set and all directed connections generated in step S122 as the edge set, forming a directed graph data structure. The adjacency list of the initial parameter flow network stores the outgoing and incoming edge lists for each parameter node. In the multi-channel new product scenario, the initial parameter flow network includes the input and output parameter nodes corresponding to tools T1 to T5, as well as the aforementioned directed connections.

[0020] Step S124: Perform redundant edge pruning on the initial parameter flow network, detect multi-hop transit dependency paths between parameter nodes, and when a direct directed connection edge and an indirect transit path simultaneously connect the same two parameter nodes, remove the direct directed connection edge, retain the intermediate parameter nodes and corresponding connection edges traversed by the indirect transit path, and obtain a simplified parameter flow network.

[0021] For each pair of directed edges connecting the starting and ending parameter nodes in the initial parameter flow network, a breadth-first search or depth-first search is used to check if an indirect propagation path exists from the starting parameter node through at least one intermediate parameter node to the ending parameter node. If an indirect propagation path exists, the direct directed edge between the starting and ending parameter nodes is considered redundant and is removed from the edge set of the initial parameter flow network. The simplified parameter flow network retains the intermediate parameter nodes and their connecting edges on the indirect propagation path, allowing the parameter dependencies to be expressed in their simplest form.

[0022] Step S125: Label the parent tool identifier of each parameter node in the simplified parameter flow network as a node attribute, and aggregate parameter nodes that share the same parent tool identifier according to the labeled parent tool identifier to generate a parameter flow topology with the tool as the external view. The connecting edges between nodes in the parameter flow topology represent the parameter data source dependency across tools.

[0023] The simplified parameter flow network iterates through all parameter nodes and groups them by their parent tool identifier field. Parameter nodes sharing the same parent tool identifier are aggregated into a single tool-level node, whose identifier is the parent tool identifier. Directed connections between parameter nodes with different parent tool identifiers are upgraded to directed connections between tool-level nodes, i.e., from the tool-level node of the source parameter node to the tool-level node of the target parameter node. If multiple directed connections exist between the same pair of tool-level nodes, they are merged into one, and the merged directed connection records the list of parameter node pairs involved. The parameter flow topology uses tool-level nodes as nodes and cross-tool directed connections as edges, clearly showing the data source dependencies between tools. In the multi-channel new product launch scenario, the output product identifier of the T1 product creation tool is relied upon by the T2 price setting tool, the T3 inventory synchronization tool, and the T4 marketing campaign creation tool. Therefore, the parameter flow topology contains directed connections from the T1 node to the T2, T3, and T4 nodes, respectively.

[0024] Step S130: In the parameter flow topology, detect a set of tool identifiers to be invoked that have a common upstream parameter declaration node and no data source dependency between them, mark the set of tool identifiers to be invoked as a parallel invokeable tool group, and generate a parallel tool invocation group partitioning result.

[0025] Step S131: Perform upstream traversal for each parameter node in the parameter flow topology, and trace all ancestor parameter nodes of the parameter node in reverse along the directed connection edges in the parameter flow topology to generate a set of ancestor parameter nodes for each parameter node.

[0026] For each parameter node corresponding to each tool-level node in the parameter flow topology, perform a depth-first traversal in reverse along the directed connection edges of the parameter flow topology, recording all ancestor parameter nodes traversed along the traversal path. The depth-first traversal terminates when a parameter node without any incoming edges (i.e., the root parameter node) is encountered, or when a visited parameter node is encountered. After the traversal is complete, collect all visited parameter nodes to form the set of ancestor parameter nodes for that parameter node.

[0027] Step S132: Perform a union operation on the set of ancestor parameter nodes of all parameter nodes belonging to the same tool identifier to be invoked, to obtain the tool-level upstream dependency parameter node set of the tool identifier to be invoked. The tool-level upstream dependency parameter node set contains all parameter declarations that must be ready before the tool identifier to be invoked is executed.

[0028] For each tool identifier to be invoked, collect the set of ancestor parameter nodes of all parameter nodes within the tool-level node corresponding to that tool identifier. Perform a union operation on these sets, and the merged set is the tool-level upstream dependency parameter node set. Each parameter node in the tool-level upstream dependency parameter node set represents a parameter declaration that must have been generated and passed to the upstream tool before the tool identifier to be invoked is executed. In the multi-channel new product launch scenario, the tool-level upstream dependency parameter node set of the T2 price setting tool includes the parameter node P1 corresponding to the output parameter product identifier of the T1 product creation tool.

[0029] Step S133: Perform pairwise comparisons on the tool-level upstream dependency parameter node sets of all tool identifiers to be invoked. When there is an intersection between the tool-level upstream dependency parameter node sets of two tool identifiers to be invoked, it is determined that there is a parameter dependency relationship between the two tool identifiers to be invoked.

[0030] Iterate through all pairs of tool identifiers to be invoked, and calculate the intersection of the sets of upstream dependency parameter nodes for each tool identifier. If the intersection is not empty, the two tool identifiers share upstream parameter nodes, indicating that both depend on the output of the same upstream tool. However, this shared dependency does not constitute a direct parameter passing relationship between them. Further analysis of the parameter flow topology is needed to determine whether a direct parameter passing path exists between them. If a directed path exists in the parameter flow topology from one node corresponding to one tool identifier to the other, then a parameter dependency relationship exists between them.

[0031] Step S134: When the tool-level upstream dependency parameter node sets of two tool identifiers to be invoked do not intersect, further check whether the two tool identifiers to be invoked exist in the tool identifier set associated with each other's tool-level upstream dependency parameter node set. If they do not contain each other, it is determined that the two tool identifiers to be invoked have no data source dependency on each other.

[0032] For two tool identifiers Tx and Ty to be invoked, extract the tool identifiers associated with each parameter node in the upstream dependency parameter node set of Tx, forming the dependency tool set Dx of Tx. Similarly, extract the dependency tool set Dy of Ty. Check whether Ty belongs to Dx and whether Tx belongs to Dy. If neither condition is true, then Tx and Ty have no data source dependency on each other, meaning they can be executed in parallel without waiting for the other to complete.

[0033] Step S135: Group the identifiers of the tools to be called that have no data source dependency on each other and whose upstream dependency parameter node sets have common parameter nodes into the same parallel callable tool group, assign a batch partitioning identifier to each parallel callable tool group, and generate the parallel tool call group partitioning result.

[0034] Collect all pairs of tool identifiers determined to have no data source dependency and construct an undirected graph. Nodes in the graph represent tool identifiers to be invoked, and edges connect pairs of tool identifiers with no data source dependency. Find connected components within this undirected graph; the tool identifiers within each connected component constitute a parallel invokeable tool group. Tool identifiers within the same parallel invokeable tool group have no data dependency and can be invoked in parallel within the same batch. Assign a batch partitioning identifier to each parallel invokeable tool group. The batch partitioning identifier is an incrementing integer, initially set to 1. The parallel tool invocation group partitioning result includes the batch partitioning identifier for each parallel invokeable tool group and a list of tool identifiers to be invoked within the group. In the multi-channel new product launch scenario, both the T2 price setting tool and the T3 inventory synchronization tool depend on the output product identifier of T1, but there is no data dependency between T2 and T3. Therefore, they can be grouped into the same parallel invokeable tool group, and a batch partitioning identifier of 2 is assigned to them.

[0035] Step S140: Perform parameter parameter binding processing on the tool input parameter declarations in each parallel callable tool group in the parallel tool call group division result. Obtain the parameter data body from the upstream parameter declaration node in the parameter flow topology according to each tool input parameter declaration. Replace the corresponding tool input parameter declaration with the parameter data body to obtain the parameter-bound tool call group instruction.

[0036] Step S141: For each tool identifier to be invoked in the currently processed parallel callable tool group in the parallel tool call group partitioning result, extract all tool input parameter declarations associated with the tool identifier to be invoked, and construct a group-level parameter declaration summary set.

[0037] Each group of parallel callable tools is processed sequentially in ascending order of batch identifiers. For the currently processed group of parallel callable tools, each tool identifier to be invoked within the group is traversed. The tool input parameter declaration list for that tool identifier is extracted from the initial tool invocation planning chain, and all parameter declaration records in the list are aggregated into a group-level parameter declaration summary set. Each record in the group-level parameter declaration summary set contains the parameter declaration content, the tool identifier to which it belongs, and the parameter source label.

[0038] Step S142: Traverse each tool input parameter declaration in the group-level parameter declaration summary set, locate the parameter node corresponding to the tool input parameter declaration in the parameter flow topology, and trace back to the direct upstream parameter declaration node along the incoming edge direction of the parameter node.

[0039] For each tool input parameter declaration in the group-level parameter declaration summary set, locate the corresponding parameter node in the parameter flow topology based on its parameter name and the identifier of the tool to be invoked. Read the incoming edge list of that parameter node and trace along the incoming edges to the directly upstream parameter declaration node. The directly upstream parameter declaration node provides the data source for that parameter node. If the parameter node has no incoming edges, it means that its parameter value comes from the user request text or an external constant, and is directly extracted from the user request text or uses a preset default value as the actual parameter data body.

[0040] Step S143: Extract the actual parameter data body from the output result storage area of ​​the tool that has been called and is corresponding to the direct upstream parameter declaration node. The actual parameter data body is the specific parameter value output after the upstream tool has been executed.

[0041] After each upstream tool completes execution in the previous batch level, its output parameter key-value pair set is written to the tool call global output buffer. The tool call global output buffer uses the parameter node identifier as the key and the corresponding actual parameter data body as the value. The tool call global output buffer is queried using the parameter node identifier of the directly upstream parameter declaration node as the key to retrieve the corresponding actual parameter data body. The actual parameter data body contains the specific parameter values ​​and parameter data type labels. In a multi-channel new product launch scenario, when processing the T2 price setting tool in batch 2, the actual parameter data body corresponding to the upstream parameter node P1 of parameter node P2 is the specific value of the product identifier returned after the T1 product creation tool is executed.

[0042] Step S144: Establish a binding mapping record between the tool input parameter declaration and the extracted actual parameter data body, mark the tool input parameter declaration in the tool call instruction as a placeholder, and fill the corresponding actual parameter data body into the parameter value position to obtain a single tool call instruction with completed actual parameter binding.

[0043] Create a binding mapping record containing the tool input parameter declaration identifier and the storage location index of the actual parameter data body. When generating a single tool invocation command, the position of the parameter declaration in the command template is marked with a parameter placeholder. Then, the corresponding actual parameter data body is found from the binding mapping record, and the specific value of the actual parameter data body is filled into the parameter value field of the command. If the actual parameter data body is a composite data type, such as a nested object, it is recursively expanded and filled according to the parameter data type description.

[0044] Step S145: Summarize all individual tool call instructions that have completed parameter binding within the parallel callable tool group into the parameter-bound tool call group instruction.

[0045] Within a group of parallel callable tools, all individual tool invocation instructions are grouped by the identifier of the tool to be invoked, with each group forming an independent tool invocation request object. Each tool invocation request object contains a tool identifier field, a tool input parameter dictionary field, and a group identifier field. All tool invocation request objects within a group of parallel callable tools constitute an argument-bound tool invocation group instruction.

[0046] Step S150: Based on the parameter flow dependency order among the parallel callable tool groups in the parallel tool call group division result, arrange the actual parameter binding tool call group instructions into a batch tool call instruction sequence according to the dependency order, and send the batch tool call instruction sequence to the tool execution agent to trigger the parallel batch tool call operation.

[0047] Step S151: Extract the set of tool-level upstream dependency parameter nodes for each parallel callable tool group in the parallel tool call group partitioning result, and determine the set of preceding dependency groups for the parallel callable tool group based on the identifier of the tool to be called associated with the set of tool-level upstream dependency parameter nodes.

[0048] For each parallel callable tool group, iterate through the union of the sets of upstream dependency parameter nodes of all tool-level tool identifiers within that group, extract the sets of tool identifiers to which these parameter nodes belong, and then find which parallel callable tool groups each tool identifier belongs to in the parallel tool call group partitioning results. These groups are then used as the set of preceding dependency groups for that parallel callable tool group. In the multi-channel new deployment scenario, the set of preceding dependency groups for the parallel callable tool groups containing T2 and T3 is the group containing T1.

[0049] Step S152: Construct an inter-group dependency graph based on the set of preceding dependent groups of each parallel callable tool group. In the inter-group dependency graph, each parallel callable tool group is used as a graph node, and directed connection edges are drawn from the dependent group node to the subsequent group nodes that depend on the dependent group node.

[0050] Create a node set for the inter-group dependency graph, where each node corresponds to a parallel callable tool group, and the node identifier is the batch partition identifier of that group. For each parallel callable tool group, traverse its set of preceding dependency groups. For each preceding dependency group in the set, create a directed edge from the corresponding node of that preceding dependency group to the corresponding node of the current group. The inter-group dependency graph is a directed acyclic graph.

[0051] Step S153: Perform topological sorting on the inter-group dependency graph, extract the group nodes with an in-degree of zero as the first priority batch, and remove the corresponding batch group nodes and their outgoing edges from the graph. Iterate the topological sorting process until all group nodes are assigned a batch level, and obtain the group batch level sequence.

[0052] Calculate the in-degree of each node in the inter-group dependency graph. Extract all nodes with an in-degree of 0 to form the current batch level, and record the parallel callable tool groups corresponding to these nodes as the current batch level group. Remove the current batch level group nodes and all their outgoing edges from the inter-group dependency graph, and update the in-degree of the remaining nodes. Repeat this operation until the inter-group dependency graph is empty. Record one batch level in each iteration, starting from 1 and incrementing. All batch level groups form a group batch level sequence in order.

[0053] Step S154: According to the order of the group batch hierarchy sequence, arrange the actual parameter binding tool call group instructions of the parallel callable tool group corresponding to each batch level in the order of batch hierarchy. The actual parameter binding tool call group instructions with the same batch level are placed in the same batch to generate the batch tool call instruction sequence.

[0054] The batch toolcall instruction sequence is an ordered list, with each batch level constituting a batch unit. All argument-bound toolcall group instructions within the same batch unit are separated by a parallel marker, indicating that they can be executed in parallel. Different batch units are separated by a serial marker, indicating that the next batch cannot begin until the previous batch has completely completed.

[0055] Step S155: The batch tool call instruction sequence is sent to the tool execution agent. The tool execution agent allocates parallel execution threads for the parameter binding tool call group instructions within the same batch, and serially schedules the parameter binding tool call group instructions across batches according to the batch hierarchy, triggering parallel batch tool call operations.

[0056] The tool execution agent maintains a thread pool with a configurable size. Upon receiving a sequence of batch tool call instructions, it processes each batch unit in hierarchical order. For all tool call request objects within the current batch unit, the tool execution agent distributes them to idle threads in the thread pool for parallel execution. Each thread independently initiates a call request to the corresponding tool interface and waits for a response. After all calls within the current batch unit are completed, the tool execution agent collects all output results for that batch and writes them to the global output buffer for tool calls, then continues processing the next batch unit. In a multi-channel new product launch scenario, the first batch first calls the product creation tools of each platform in parallel; the second batch, after product creation is completed, calls the price setting tool, inventory synchronization tool, and marketing campaign creation tool in parallel; and the third batch, after the preceding tools are completed, calls the store display synchronization tool, ultimately achieving multi-platform collaborative new product launches.

[0057] Step S210: During the process of the tool execution agent executing the batch tool call instruction sequence, the tool call response data stream of each tool call execution instance in the tool execution agent is collected in real time during the call lifecycle. The tool call response data stream includes the tool call status code sequence and the number of time-by-time output parameter bytes arriving.

[0058] The tool execution agent allocates a monitoring agent thread to each tool call execution instance when it is initiated. This monitoring agent thread intercepts the network data stream from the tool call client, collecting the tool call response data stream in real time throughout the call's lifecycle. The tool call status code sequence is a list of status code change records arranged by timestamps. Each record contains a timestamp and a status code value, which includes enumerated values ​​such as connection establishment, waiting for response, data transmission in progress, and transmission completed. The time-by-time output parameter byte arrival count is a sequence of the cumulative output parameter byte arrival counts recorded at equally spaced sampling periods, with the sampling period being a preset number of milliseconds.

[0059] Step S220: Perform cumulative curve fitting processing on the amount of output parameter bytes arriving at each time step to generate an output parameter data arrival progress curve for each tool call execution instance. The horizontal axis of the output parameter data arrival progress curve is the unit of measurement for call time, and the vertical axis is the cumulative value of output parameter bytes that have been transmitted.

[0060] For each tool call execution instance, the time-by-time sequence of output parameter byte arrivals is plotted as follows: with the first sampling time as the time origin, the call duration relative to the time origin at each sampling time is plotted on the horizontal axis, and the cumulative arrival amount at each sampling time is plotted on the vertical axis. A piecewise linear interpolation method is used to connect the discrete sampling points into a continuous output parameter data arrival progress curve. The domain of the output parameter data arrival progress curve is the entire call duration interval from the start of the call to the completion of the transmission.

[0061] Step S230: Calculate the output parameter data arrival progress difference between each tool call execution instance based on the output parameter data arrival progress curve. When the vertical axis difference between the output parameter data arrival progress curve of the first tool call execution instance and the output parameter data arrival progress curve of the second tool call execution instance at the same call time unit is lower than the preset progress difference threshold, establish the output rhythm synchronization correlation between the first tool call execution instance and the second tool call execution instance.

[0062] For each pair of tool call execution instances within the same batch level, the absolute value of the vertical axis difference between the two output parameter data arrival progress curves is calculated at the same call duration sampling point. If the absolute value of the vertical axis difference is lower than the preset progress difference threshold at sampling points exceeding a preset proportion, the output rhythm of the two tool call execution instances is determined to be synchronized, and an output rhythm synchronization correlation is established between them. The output rhythm synchronization correlation is recorded in the form of a triple, containing the identifier of the first tool call execution instance, the identifier of the second tool call execution instance, and a synchronization type flag.

[0063] Step S240: The tool call execution instances that have established output rhythm synchronization associations are grouped into the same output synchronization tool instance group, and the output result data bodies of each tool call execution instance in the same output synchronization tool instance group are aggregated and received. After the output result data bodies of all tool call execution instances in the same output synchronization tool instance group have arrived completely, the entire group of output result data bodies is submitted to the tool call global output buffer area at once.

[0064] A disjoint-set data structure is used to merge tool call execution instances with output rhythm synchronization relationships into output synchronization tool instance groups. The tool execution agent sets a synchronization reception barrier for the output result data body within the same output synchronization tool instance group. When the output result data bodies of all tool call execution instances in the group have arrived completely, the barrier is released, and the entire group of output result data bodies is packaged into a batch data block and written to the storage location of the corresponding parameter node in the tool call global output buffer at once.

[0065] Step S250: Perform cross-reference verification on the output result data body within the same output synchronization tool instance group. Detect whether there are parameter value conflicts pointing to the same entity in the output parameter key-value pair set of different tool call execution instances. When a parameter value conflict is detected, select the output parameter value of the tool call execution instance that is closer to the final output node in the node level of the parameter flow topology according to the tool identifier of the tool call execution instance that caused the parameter value conflict.

[0066] For the set of output parameter key-value pairs within the same output synchronization tool instance group, compare the key names to find those with the same or equivalent key names. If the parameter values ​​corresponding to the same key name are different, a parameter value conflict is determined. In the parameter flow topology, find the tool-level nodes corresponding to the tool identifiers of the two conflicting tool call execution instances, and calculate the shortest path length from each node to the final output node in the parameter flow topology. Take the output parameter value of the tool call execution instance corresponding to the tool-level node with the smaller shortest path length as the authoritative parameter value.

[0067] Step S260: Replace the corresponding conflicting parameter values ​​in the output parameter key-value pair set of other tool call execution instances within the output synchronization tool instance group with the authoritative parameter values ​​after conflict resolution, generate the tool instance group output dataset with resolved parameter conflicts, and write the tool instance group output dataset with resolved parameter conflicts into the tool call global output buffer.

[0068] Iterate through the set of key-value pairs of output parameters for each tool call execution instance within the output synchronization tool instance group, replace conflicting parameter values ​​with the authoritative parameter values ​​determined in step S250, and generate a tool instance group output dataset with resolved parameter conflicts. Write this dataset to the corresponding storage location in the tool call global output buffer according to the parameter node identifier, overwriting the original conflicting values.

[0069] Step S310: Perform parameter declaration syntax tree parsing on the tool input parameter declaration associated with each tool identifier to be invoked in the initial tool invocation planning chain, and extract the parameter name identifier, parameter data type description and parameter nesting structure level of each tool input parameter declaration.

[0070] A recursive descent parser is used to parse the parameter definition text of each tool input parameter declaration, constructing a parameter declaration syntax tree. The root node of the parameter declaration syntax tree is the parameter root object, and the child nodes are the parameter name identifier leaf nodes, the parameter data type description leaf nodes, and the parameter nesting structure subtree. The parameter data type descriptions include basic types such as string, numeric, and boolean types, as well as composite types such as array and nested object types. The parameter nesting structure level is the number of path edges from the root node to the deepest leaf node in the parameter declaration syntax tree, used to quantify the complexity of the parameter structure.

[0071] Step S320: Based on the parameter data type description and parameter nesting structure hierarchy, perform parameter template abstraction processing on the tool input parameter declaration, replace the parameter name identifier of the tool input parameter declaration with the same parameter nesting structure hierarchy with parameter type placeholders to obtain the parameter abstract template. The parameter abstract template retains the parameter nesting structure hierarchy and parameter data type description, but removes the specific parameter name identifier.

[0072] Tool input parameter declarations with the same nested parameter structure are grouped. For each group, the structural skeleton of its parameter declaration syntax tree is extracted. The parameter name identifier leaf nodes are replaced with parameter type placeholder nodes, which store the original parameter data type description. The resulting parameter declaration syntax tree skeleton is the parameter abstract template. The parameter abstract template is stored as a serialized string, containing a hierarchical description of the parameter nesting structure and a description of the parameter data type at each level.

[0073] Step S330: Perform template similarity matching processing between the parameter abstract template and the input parameter pattern definition of the registered tools in the tool execution agent, calculate the overlap of parameter nesting structure hierarchy and the consistency of parameter data type description between the parameter abstract template and the input parameter pattern definition of each registered tool, and filter out a set of candidate replacement tools based on the overlap of parameter nesting structure hierarchy and the consistency of parameter data type description.

[0074] The tool execution agent reads the input parameter pattern definition of each registered tool from the tool registry and converts it into a parameter abstract template representation. The parameter nesting structure overlap is the ratio of the number of levels where two parameter abstract templates have identical structures at the same level to the total number of levels. The parameter data type description consistency is the ratio of the number of parameter data type descriptions that are identical at corresponding levels in two parameter abstract templates to the total number of data type descriptions. The weighted sum of these two metrics is used as the comprehensive similarity score. Registered tools with a comprehensive similarity score exceeding a preset similarity threshold are selected to form a candidate set of replaceable tools.

[0075] Step S340: Select alternative tool identifiers from the set of alternative tool candidates that have different tool call response time characteristics from the original tool identifier to be called, and generate a dual-channel tool call alternative scheme that includes the original tool identifier to be called and the alternative tool identifier.

[0076] The tool execution agent queries the tool performance monitoring module for the historical average response time and response time variance of the original tool identifier to be invoked and each alternative tool identifier in the candidate set of replacement tools. The alternative tool identifier with the lowest historical average response time or the smallest response time variance is selected as the preferred alternative. The dual-channel tool invocation alternative scheme consists of two parts: the original tool channel configuration and the alternative tool channel configuration. Each part contains the tool identifier and its corresponding parameter binding mapping.

[0077] Step S350: When performing the parameter binding process, the parameter data body binding operation is performed on the original tool identifier to be called and the alternative tool identifier to generate the original parameter binding tool call instruction and the alternative parameter binding tool call instruction respectively.

[0078] The parameter binding processing steps S141 to S145 are executed on the original tool identifier to be invoked and the alternative tool identifier, respectively, to generate the original parameter-bound tool invocation instruction and the alternative parameter-bound tool invocation instruction. The two instructions have the same logical input parameters but different tool identifiers and tool interface addresses.

[0079] Step S360: Simultaneously send the original parameter binding tool call instruction and the alternative parameter binding tool call instruction to the mutually isolated execution channels in the tool execution agent for parallel competitive call execution, and receive the output result data body of the tool call instruction corresponding to the execution channel that first returns a complete tool execution output result data body as the final output result data body of the tool call node.

[0080] The tool execution agent allocates two independent execution channels for the original instruction and the replacement instruction. These channels share resources but are isolated from each other, operating independently. Both channels initiate tool calls simultaneously, each waiting for a response independently. The tool execution agent listens for the arrival of responses from both channels, taking the response from the channel that first returns a complete tool execution output data body as the final output of that tool call node. Subsequent responses are discarded, and the corresponding execution channel releases its resources.

[0081] Step S410: During the process of the tool execution agent executing the batched tool call instruction sequence, the set of output parameter key-value pairs of each tool call execution instance that has been stored in the tool call global output buffer is marked with output parameter lifecycle markers. For each output parameter key-value pair, an additional parameter effective batch identifier and parameter validity period batch count are added. The parameter effective batch identifier is the batch level number when the output parameter is generated, and the parameter validity period batch count is the number of remaining valid batches that the output parameter can be referenced by subsequent batch levels.

[0082] The tool accesses each output parameter key-value pair record in the global output buffer, which includes a parameter key-value pair data field and a lifecycle metadata field. The parameter activation batch identifier is the batch level number where the output parameter was written to the buffer. The parameter validity batch count is a preset initial validity period value, indicating how many subsequent batch levels can reference the parameter from the batch in which it was generated. For example, an initial parameter validity batch count of N means that the output parameter can be referenced in batches M+1 to M+N after being generated in batch M, and becomes invalid from batch M+N+1 onwards.

[0083] Step S420: When it is detected that the tool input parameter declaration associated with the tool identifier to be invoked in the subsequent batch level needs to reference the target output parameter key-value pair in the tool invocation global output buffer, read the parameter validity period batch count attached to the target output parameter key-value pair. If the parameter validity period batch count is greater than 0, then the tool identifier to be invoked is allowed to read the target output parameter value from the tool invocation global output buffer, and the parameter validity period batch count of the target output parameter key-value pair is decremented and updated.

[0084] Before retrieving the actual parameter data body from the global output buffer in step S143, the lifecycle metadata field of the target output parameter key-value pair is read first. It is determined whether the current value of the parameter validity period batch count is greater than 0. If it is greater than 0, a read operation is performed, and after reading, the parameter validity period batch count is decremented by 1 and written back. If the parameter validity period batch count is equal to 0, the process proceeds to step S430.

[0085] Step S430: If the batch count of the parameter validity period is equal to 0, then the tool identifier to be called is prohibited from reading the target output parameter value from the tool call global output buffer, triggering the tool call re-execution operation of the upstream tool call execution instance corresponding to the target output parameter value, and inserting the tool call re-execution instruction into the supplementary re-execution batch before the current batch level.

[0086] The tool invocation re-execution operation involves submitting a tool invocation request identical to the original upstream tool invocation execution instance to the tool execution agent, generating a new tool invocation execution instance. The supplementary re-execution batch is inserted between the current batch level and the previous batch level, has an independent supplementary batch level number, and executes with priority over the current batch level. After the tool invocation execution instance in the supplementary re-execution batch completes, it writes the new output parameters to the tool invocation global output buffer.

[0087] Step S440: After the tool call re-execution operation is completed, replace the expired original output parameter key-value pairs in the tool call global output buffer with the newly generated output parameter key-value pairs, and reset the parameter validity period batch count for the new output parameter key-value pairs.

[0088] The new output parameter key-value pair overwrite tool calls the storage entry of the corresponding parameter node identifier in the global output buffer, updates the parameter effective batch identifier in its lifecycle metadata field to the number of the supplementary re-execution batch, and resets the parameter validity period batch count to the initial validity period value.

[0089] Step S450: Based on the dependency path length between each parameter node in the parameter flow topology, dynamically adjust the initial value of the parameter validity period batch count, so that the output parameter key-value pairs corresponding to parameter nodes with longer dependency path lengths are assigned larger initial values ​​for parameter validity period batch counts.

[0090] The dependency path length between parameter nodes is defined as the number of edges contained in the longest directed path from the parameter node to all downstream parameter nodes that reference the parameter in the parameter flow topology. A longer dependency path length indicates a larger batch span where the parameter is referenced downstream. The initial value of the parameter validity batch count is proportional to the dependency path length, with the scaling factor being a preset constant.

[0091] Step S510: After obtaining the initial tool call planning chain, the user request text sequence is split into multiple independent semantic fragment units, and the single tool call requirement corresponding to each independent semantic fragment unit is identified.

[0092] A text segmentation algorithm based on delimiters and semantic boundary detection is used to process user request text sequences. A predefined set of task delimiters, such as "simultaneously," "in addition," and "furthermore," is used. The occurrence positions of task delimiters are retrieved in the user request text sequence, and these delimiters are used as segmentation boundaries. For each segment, a pre-trained intent classification model is used to identify whether the segment contains a single tool call request. The intent classification model is a Transformer encoder-based text classification model, and its output is a probability distribution over a predefined set of tool categories. The tool category with the highest probability is taken as the single tool call request for that segment.

[0093] Step S520: Perform independent tool call planning generation processing on the single tool call requirement corresponding to each independent semantic fragment unit, and generate an independent tool call planning sub-chain for each independent semantic fragment unit, which contains multiple independent tool identifiers to be called arranged in the execution sequence.

[0094] The text content of each independent semantic segment unit and its corresponding single tool invocation requirement are input into the large language model. The large language model generates an independent tool invocation planning sub-chain for each independent semantic segment unit. Each independent tool invocation planning sub-chain contains a sequence of tool identifiers to be invoked and their parameter declarations required for the semantic segment to complete the task. The data structure of the independent tool invocation planning sub-chain is the same as that of the initial tool invocation planning chain.

[0095] Step S530: Perform cross-subchain deduplication and merging processing on the independent tool identifiers to be called in each independent tool call planning subchain, identify redundant tool identifiers to be called in different independent tool call planning subchains that have the same tool identifier and the same tool input parameter declaration characteristics, and merge the redundant tool identifiers to be called in into a common tool call node.

[0096] Iterate through all independent tool call planning subchains. For each pair of tool identifiers from different subchains, compare their tool identifiers with the parameter name identifier list declared in the tool input parameter declaration. If the tool identifiers are the same and the overlap ratio of the parameter name identifier lists exceeds a preset overlap threshold, then the two tool identifiers are determined to be redundant. Create a shared tool call node for each cluster of redundant tool identifiers. The parameter declaration of the shared tool call node is the union of the original parameter declarations.

[0097] Step S540: Perform cross-subchain interleaving and orchestration processing on the non-redundant tool identifiers to be invoked in each independent tool invocation planning subchain according to their invocation dependency order in the original independent tool invocation planning subchain. The tool identifiers to be invoked from different independent tool invocation planning subchains are interleaved according to the data source dependency relationship in the parameter flow topology to generate a cross-subchain interleaved tool invocation planning chain.

[0098] The non-redundant tool call identifiers retained in each independent tool call planning sub-chain and the merged shared tool call nodes are uniformly incorporated into a new tool call planning chain. The parameter flow topology of these tool call identifiers is constructed using the methods in steps S120 to S125. The tool call identifiers are then interleaved according to the topology sorting result, generating a cross-sub-chain interleaved tool call planning chain. Tool call nodes from different sub-chains in the cross-sub-chain interleaved tool call planning chain are naturally interleaved according to data dependencies, eliminating the original sub-chain boundaries.

[0099] Step S550: Replace the initial tool call planning chain with the cross-subchain interleaved tool call planning chain as the input for the tool call dependency decoupling process, and re-execute the subsequent parallel tool call group partitioning and batch scheduling process.

[0100] Assign the cross-subchain interleaving tool call planning chain to the initial tool call planning chain variable, and continue executing step S120 and all subsequent processing flows.

[0101] For example, in step S610: during the process of the tool execution agent executing the batch tool call instruction sequence, the computing power resources consumed by each tool call execution instance executed in parallel within the same batch level are sampled in real time to generate computing power resource consumption time series data for each tool call execution instance. The computing power resource consumption time series data includes a central processing unit occupancy sampling sequence and a memory working set occupancy sampling sequence.

[0102] The tool execution agent samples the CPU utilization and working set memory usage of the process or thread where each tool execution instance resides via the operating system performance monitoring interface at a preset sampling frequency. The CPU utilization sampling sequence is a one-dimensional floating-point sequence arranged by timestamps, with each value between 0 and 1. The working set memory usage sampling sequence is a one-dimensional integer sequence arranged by the same timestamps, with the unit being bytes. Together, these two sequences constitute the time-series data of computing resource consumption.

[0103] Step S620: Perform fluctuation pattern similarity analysis on the sampling sequence of CPU utilization of each tool call execution instance within the same batch level, and identify tool call execution instance pairs with complementary CPU utilization fluctuation patterns. The complementary relationship means that the peak time of CPU utilization of the first tool call execution instance coincides with the trough time of CPU utilization of the second tool call execution instance on the time axis.

[0104] For the CPU utilization sampling sequences of two tool call execution instances, peak and trough times are extracted separately. A peak time is defined as the moment when the sampled value is greater than the average of the sampled values ​​within the preceding and following preset windows. A trough time is defined as the moment when the sampled value is less than the average of the sampled values ​​within the preceding and following preset windows. The temporal overlap between the peak time set of the first sequence and the trough time set of the second sequence, as well as the temporal overlap between the trough time set of the first sequence and the peak time set of the second sequence, are calculated. A complementary relationship is determined when both overlap values ​​exceed a preset overlap threshold.

[0105] Step S630: Perform high-low alternating analysis on the memory working set occupancy sampling sequence of each tool call execution instance within the same batch level to identify tool call execution instance pairs that exhibit an interleaved occupancy pattern. The interleaved occupancy pattern refers to the overlap of the rising interval of the memory working set occupancy of the first tool call execution instance and the falling interval of the memory working set occupancy of the second tool call execution instance on the time axis.

[0106] For the memory working set occupancy sampling sequences of the two tool call execution instances, rising and falling interval detection are performed separately. The rising interval is the segment in a series of sampling points where the value of a later sampling point is greater than the value of a previous sampling point. The falling interval is the segment in a series of sampling points where the value of a later sampling point is less than the value of a previous sampling point. The overlap length of the rising interval of the first sequence and the falling interval of the second sequence on the time axis, as well as the overlap length of the falling interval of the first sequence and the rising interval of the second sequence, are calculated. If the sum of the two overlapping interval lengths exceeds a preset overlap threshold, it is determined to be an interleaved occupancy pattern.

[0107] Step S640: Pair and label tool call execution instances that simultaneously satisfy the complementary relationship of the CPU utilization fluctuation mode and the memory working set occupancy interleaved occupancy mode as computing power resource complementary tool pairs, and allocate a shared computing power resource pool for the computing power resource complementary tool pairs in the thread scheduler of the tool execution agent.

[0108] Iterate through all tool call execution instance pairings within the same batch level. Pairs that simultaneously satisfy the complementary relationship in step S620 and the interleaved occupancy pattern in step S630 are marked as computing resource complementary tool pairs. The thread scheduler creates a shared computing resource pool object for each computing resource complementary tool pair, containing a shared CPU time slice quota and a shared memory page quota.

[0109] Step S650: The CPU time slices and memory page resources in the shared computing power resource pool are dynamically tilted and allocated within the computing power resource complementary tool pair. During the peak and trough alternation time window of the complementary relationship of CPU utilization fluctuation mode, CPU time slices are preferentially allocated to tool call execution instances in the peak phase, and memory page resources are preferentially allocated to tool call execution instances in the rising range of memory working set utilization.

[0110] Within each scheduling time slice, the thread scheduler dynamically adjusts resource allocation weights based on the real-time collected CPU utilization and memory working set usage of the two tool call execution instances. When it detects that the first tool call execution instance is at a peak CPU utilization level while the second tool call execution instance is at a trough, the allocation weight of the shared CPU time slice is tilted towards the first tool call execution instance. When it detects that the first tool call execution instance is in an increasing range of memory working set usage while the second tool call execution instance is in a decreasing range, the allocation weight of shared memory pages is tilted towards the first tool call execution instance.

[0111] Step S710: After generating the parallel tool call group partitioning result, the tool execution cost corresponding to each tool identifier to be called in the parameter flow topology is marked, and the estimated tool call time and tool call failure probability value of each tool identifier to be called are obtained.

[0112] The tool execution agent retrieves the average tool call time for each tool identifier within a preset time window from its historical performance statistics module. This average time is used as the estimated tool call time. The ratio of failed tool calls to the total number of calls is used as the tool call failure probability. The estimated tool call time is in milliseconds, and the tool call failure probability is a floating-point number between 0 and 1.

[0113] Step S720: The estimated time consumption and failure probability of the tool call are added as edge weights to the dependency connection edges between parallel callable tool groups in the parallel tool call group partitioning result to construct a weighted group dependency graph.

[0114] The structure is copied from the inter-group dependency graph. For each dependency connection edge, the upstream and downstream tool call nodes involved in the parameter passing relationship corresponding to that dependency connection edge are found. The estimated tool call time of the upstream tool call node is taken as the time weight of the dependency connection edge, and the tool call failure probability value of the upstream tool call node is taken as the failure probability weight of the dependency connection edge. The weighted group dependency graph adds a weight attribute to each directed connection edge on the basis of the inter-group dependency graph.

[0115] Step S730: Perform critical dependency path identification processing on the weighted group dependency graph, calculate the product of the cumulative estimated tool call time and the cumulative tool call failure probability of all possible dependency paths from the first group node of the execution batch level to the last group node of the execution batch level, and mark the dependency path with the highest product of the cumulative estimated tool call time and the cumulative tool call failure probability as a fragile tool call dependency link.

[0116] In a weighted group dependency graph, there may be multiple dependency paths between the group node at the first execution batch level and the group node at the last execution batch level. For each dependency path, the total estimated time of the cumulative tool call is the sum of the time weights of all directed edges on that path. The failure probability of the cumulative tool call is 1 minus the product of (1 - failure probability weights) of all directed edges on that path. The vulnerability score for each path is calculated as the cumulative time multiplied by the cumulative failure probability. The path with the highest vulnerability score is marked as a vulnerable dependency link for the tool call.

[0117] Step S740: Backtrack along the fragile dependency chain of the tool call to locate the single tool call node with the largest contribution of the cumulative tool call failure probability product on the fragile dependency chain of the tool call, and mark the single tool call node as the single point of failure bottleneck node of the tool call.

[0118] The marginal contribution of the failure probability of each tool call node on a fragile dependency link to the cumulative failure probability of the path is calculated. The marginal contribution is the reduction in the cumulative failure probability of the path after removing the node. The tool call node with the largest marginal contribution is marked as the single point of failure bottleneck node of the tool call.

[0119] Step S750: Perform redundant copy injection processing on the single point of failure bottleneck node of the tool call. Add a redundant copy tool call node of the single point of failure bottleneck node of the tool call to the parallel callable tool group where the single point of failure bottleneck node of the tool call is located. The redundant copy tool call node has the same tool identifier and tool input parameter declaration as the single point of failure bottleneck node of the tool call.

[0120] Create a new tool identifier to be invoked, identical to the tool identifier for the single-point-of-failure bottleneck node, but with the addition of a replica suffix. Copy all tool input parameter declarations for the single-point-of-failure bottleneck node to this redundant replica tool invoking node. Add the redundant replica tool invoking node to the list of tool identifiers to be invoked for this group of parallel invokeable tools.

[0121] Step S760: Modify the data source dependency connection edge of the subsequent parameter node in the parameter flow topology that depends on the output parameter of the tool call single point of failure bottleneck node, and point the data source dependency of the subsequent parameter node to both the tool call single point of failure bottleneck node and the redundant replica tool call node, forming a parameter dual source dependency structure.

[0122] In the parameter flow topology, for each directed connection edge originating from the output parameter node of the bottleneck node in the tool call, a parallel directed connection edge is created. The starting point of this parallel edge is the output parameter node corresponding to the redundant replica tool call node, and the ending point is the same as the original edge. In the parameter dual-source dependency structure, subsequent parameter nodes depend on both the primary output parameter node and the replica output parameter node.

[0123] Step S770: In the parameter actual parameter binding process stage, perform actual parameter data body binding operations on the single-point failure bottleneck node and the redundant replica tool call node in the parameter dual-source dependency structure respectively, and generate the primary actual parameter binding tool call instruction and the replica actual parameter binding tool call instruction.

[0124] Following steps S141 to S145, a primary parameter binding tool call instruction is generated for the single-point-of-failure bottleneck node, and a replica parameter binding tool call instruction is generated for the redundant replica tool call node. The parameter data body binding mapping content of the two instructions is the same, but the instruction identifier and execution instance identifier are different.

[0125] Step S780: Submit the master parameter binding tool call instruction and the replica parameter binding tool call instruction to the same batch level of the batch tool call instruction sequence. The tool execution agent receives the output result of the master or replica instruction that first returns the complete tool execution output result data body as the valid output result of the tool call node.

[0126] The tool execution agent executes the primary and replica instructions simultaneously within the same batch level. When either instruction returns a complete output result first, that result is written as a valid output result to the tool's global output buffer. The result of the other instruction is discarded directly after it returns.

[0127] Step S810: After the parameter flow topology is constructed, parameter semantic labeling is performed on each parameter node in the parameter flow topology. The semantic features of the tool input parameter declaration represented by each parameter node are extracted, and a parameter semantic label is attached to each parameter node. The parameter semantic label describes the business meaning category of the data carried by the parameter node.

[0128] A pre-trained parameter semantic classification model is used to classify and label the parameter name and data type description of each parameter node. The parameter semantic classification model is a multi-label classification model based on a Transformer encoder, and its output is the probability distribution of the parameter node belonging to each preset business meaning category. Category labels with probabilities exceeding a preset threshold are taken as the parameter semantic labels for that parameter node. Business meaning categories include product identification, price value, inventory quantity, store identification, and marketing rules, etc.

[0129] Step S820: Perform semantic clustering on all parameter nodes in the parameter flow topology based on the parameter semantic tags, and group parameter nodes with the same or similar parameter semantic tags into the same semantically equivalent parameter node set. The parameter nodes in the semantically equivalent parameter node set can be interchanged with each other in terms of business meaning.

[0130] The semantic labels of all parameter nodes in the parameter flow topology are compared pairwise. Parameter nodes whose intersection-union ratio (IU) exceeds a preset threshold are grouped into the same semantically equivalent parameter node set. Parameter nodes within the semantically equivalent parameter node set are equivalent in terms of business meaning and can theoretically be substituted for each other, but their data representation may differ.

[0131] Step S830: Perform parameter data representation form analysis processing on each semantically equivalent parameter node set to identify the differences in data representation forms of data carried by different parameter nodes in the same semantically equivalent parameter node set. The differences in data representation forms include differences in data structure and differences in data encoding methods.

[0132] Data structure differences refer to the differences in the nesting hierarchy of parameters in the parameter data type description of parameter nodes, such as the difference between a flat key-value pair structure and a nested JSON structure. Data encoding differences refer to the differences in the encoding format of parameter values ​​during transmission and storage, such as the difference between string encoding and numeric encoding, or the difference between date and time formats.

[0133] Step S840: In the parameter binding process, when the parameter node corresponding to the tool input parameter declaration of a certain tool call node belongs to a set of semantically equivalent parameter nodes, and the data representation form of the upstream output parameter value pointed to by the parameter node does not match the data representation form required by the tool input parameter declaration, a substitute parameter node that matches the data representation form of the upstream output parameter value is selected from the set of semantically equivalent parameter nodes.

[0134] After locating the direct upstream parameter declaration node in step S142, the data representation form of the upstream output parameter value is obtained. This data representation form is compared with the data representation form required by the current tool input parameter declaration. If they are completely identical, no replacement is needed. If they are inconsistent, the parameter node whose data representation form best matches the upstream output parameter value's data representation form is searched in the semantically equivalent parameter node set and used as the replacement parameter node.

[0135] Step S850: Establish a parameter semantic transfer mapping from the upstream output parameter value to the alternative parameter node, and fill the upstream output parameter value into the tool input parameter declaration corresponding to the alternative parameter node after data representation form adaptation and conversion. The data representation form adaptation and conversion includes data structure reorganization operation and data encoding format transcoding operation.

[0136] Data structure reorganization operations include converting flat key-value pair structures into nested object structures or vice versa, achieved through preset structure mapping rules. Data encoding format conversion operations include numeric type conversion, string encoding conversion, and date format conversion. The adapted parameter value data representation format is consistent with the input data representation format required by the substitute parameter node.

[0137] Step S860: After completing the data representation form adaptation and conversion, replace the original parameter node in the parameter flow topology with the alternative parameter node, and update all data source dependent connection edges related to the parameter node in the parameter flow topology.

[0138] The parameter flow redirects directed edges in the topology that point to the original parameter node to the replacement parameter node, and updates the starting point of directed edges originating from the original parameter node to the replacement parameter node. The updated parameter flow maintains connectivity and acyclicity in the topology.

[0139] Step S910: After generating the batch tool call instruction sequence, extract the inter-batch data transfer amount between each batch level in the batch tool call instruction sequence. The inter-batch data transfer amount is the total amount of data body of the output parameter values ​​transferred from the previous batch level to the immediately following batch level.

[0140] For each pair of adjacent batch levels in a batched tool call instruction sequence, the total data size, in bytes, is calculated for the output parameters of each tool call node in the previous batch level that are referenced by the parameter values ​​in the subsequent batch level. The data size is the number of bytes for each output parameter value after serialization.

[0141] Step S920: Compare the inter-batch data transfer volume between two adjacent batch levels with the preset upper limit of inter-batch data transfer volume. When the inter-batch data transfer volume between two adjacent batch levels exceeds the preset upper limit of inter-batch data transfer volume, mark the two adjacent batch levels as an inter-batch data transfer congestion interval.

[0142] The preset upper limit for inter-batch data transfer is set based on the network bandwidth and data transfer buffer capacity between the tool's execution agent and the batch execution environment. If the inter-batch data transfer volume exceeds the upper limit, it is determined that there is a risk of data transfer congestion between adjacent batch levels.

[0143] Step S930: Perform intra-batch tool call node output parameter transmission path rearrangement processing on the previous batch level involved in the inter-batch data transmission congestion interval, analyze which tool call nodes in subsequent batch levels reference the output parameters of each tool call node in the previous batch level, and generate a mapping relationship table from output parameters to consumer tool nodes.

[0144] Extract each output parameter from each tool call node in the previous batch hierarchy, and search the parameter flow topology for all subsequent batch hierarchy tool call nodes that reference that output parameter, forming a consumer tool node list. Map the output parameter identifiers to the consumer tool node list to generate a mapping table.

[0145] Step S940: Based on the mapping table from the output parameters to the consumer tool nodes, group and arrange the execution completion notification signals of each tool calling node in the previous batch level, so that the execution completion notification signals of the tool calling nodes whose output parameters are depended by the tool calling nodes in the same subsequent batch level are arranged into the same notification signal sending batch for centralized sending.

[0146] Output parameters with the same set of consumer tool nodes in the mapping table are grouped together. For output parameters within the same group, the execution completion notification signals of the tool calling node to which it belongs are grouped into the same notification signal sending batch. After all tool calling nodes in the group have completed execution, all execution completion notification signals in the group are sent in a centralized manner.

[0147] Step S950: After sending the execution completion notification signal in a centralized manner, the tool execution agent packages the output parameter value data body corresponding to the batch of notification signal sending into an inter-batch data transmission data packet, and transmits the inter-batch data transmission data packet to the execution environment where the tool calling node of the subsequent batch level is located in one go, so as to reduce the number of inter-batch data transmissions.

[0148] The tool execution agent creates an inter-batch data transmission packet for each notification signal sending batch. This packet contains a metadata header and a payload. The metadata header includes the sending batch number, the receiving batch number, and a list of output parameter identifiers. The payload is a serialized concatenation of all output parameter value data. The packet is sent all at once through the inter-batch data transmission channel to the execution environment of subsequent batch levels. The receiving end parses the packet and distributes it to each consumer tool invocation node according to the parameter identifier list.

[0149] Step S1010: After the initial tool call planning chain is generated, tool call side effect analysis is performed on the tool call nodes in the initial tool call planning chain to identify the set of tool call nodes with external state modification capabilities, and each tool call node in the set of tool call nodes with external state modification capabilities is marked as a tool node with side effects.

[0150] The tool side effect description corresponding to each tool identifier to be invoked is read from the tool registry of the tool execution agent. The tool side effect description indicates whether the tool invocation will modify external state resources outside the tool execution environment, as well as the resource identifier of the modified external state resources and the modification operation type. Modification operation types include create, update, and delete. Tool invocation nodes that indicate the ability to modify external state in the side effect description are marked as tool nodes with side effects.

[0151] Step S1020: Perform side effect impact range analysis on the tool nodes with side effects, extract the resource identifier and modification operation type of the external state resources modified by each tool node with side effects, and detect whether there are conflicting modification operations on external state resources with the same resource identifier between different tool nodes with side effects.

[0152] Iterate through all utility nodes with side effects, extracting the resource identifier and modification operation type for each. For each pair of utility nodes with side effects, compare their resource identifiers. If the resource identifiers are the same, further check whether the modification operation types might conflict. The condition for determining a conflicting modification operation is that either one of the modification operations is a delete, or both modification operations are updates that update the same resource attribute field.

[0153] Step S1030: When it is detected that a first side-effect tool node and a second side-effect tool node are performing conflicting modification operations on external state resources with the same resource identifier, a virtual barrier node is inserted into the parameter flow topology. The virtual barrier node serves as the sequential execution constraint mark between the first side-effect tool node and the second side-effect tool node.

[0154] In the parameter flow topology, a virtual barrier node is created and assigned a unique identifier. The virtual barrier node is not a real tool invocation node and does not generate actual tool invocations; it is only used to represent sequence constraints in the topology. A directed connection is created between the tool-level node corresponding to the first tool node with side effects and the virtual barrier node, and a directed connection is created between the virtual barrier node and the tool-level node corresponding to the second tool node with side effects.

[0155] Step S1040: The virtual barrier node mandates that the first side-effect tool node and the second side-effect tool node be assigned to different batch levels in the parallel tool call group partitioning result, and the batch level where the first side-effect tool node is located must be executed before the batch level where the second side-effect tool node is located.

[0156] During the parallel tool call group partitioning process in steps S130 to S135, virtual barrier nodes are treated as having mandatory order constraints with data dependencies. Since there are directed connections between the tool-level node containing the virtual barrier node and the first and second tool nodes with side effects, the topology sorting naturally ensures that the batch level of the first tool node with side effects comes first, followed by the batch level of the second tool node with side effects.

[0157] Step S1050: When generating the parallel tool call group partitioning result, the virtual barrier node is used as a mandatory dependency edge in the inter-group dependency graph. Even if there is no parameter data source dependency between the first side-effect tool node and the second side-effect tool node, the batch hierarchical partitioning must be performed in accordance with the order constraint of the mandatory dependency edge.

[0158] When constructing the inter-group dependency graph, the dependency edges corresponding to the virtual barrier nodes are added as mandatory dependency edges. In step S152, when constructing the inter-group dependency graph, a directed connection edge is forcibly added from the group node containing the first side-effect tool node to the group node containing the second side-effect tool node. This mandatory dependency edge ensures that the two are assigned to different, ordered batch levels in the topology sorting.

[0159] Figure 2 This document illustrates a specific application interface during the execution of steps S110 to S130 of an embodiment of the present invention. As shown in the figure, the system first responds to the user request and obtains the initial tool call planning chain generated by the large language model. Based on this, the system performs the tool call dependency decoupling processing in step S120. The "Parameter Flow Topology" area on the left side of the interface visually displays the completed parameter flow topology structure. Among them, "Basic Product Information," "Channel Configuration List," and "Material Resource Reference" are identified as "Common Upstream Parameter Declaration Nodes," which correspond to the parameter flow topology structure with tools as the external view constructed in step S125, clearly revealing the path of data flow from the source to each downstream tool. Subsequently, the system performs the parallel tool call group partitioning operation in step S130. The interface clearly distinguishes between "Parallel Callable Tool Group A" and "Parallel Callable Tool Group B." Specifically, for "Group A," which includes both "Channel A Publishing Tool" and "Channel B Synchronization Tool," and marked "No Mutual Data Dependency" within the dashed box, this directly corresponds to the process in step S135 of grouping the identifiers of the tools to be called into the same parallel callable tool group based on the absence of mutual data source dependencies. Meanwhile, Figure 2 The “Redundant edges have been pruned” status label shown intuitively reflects the result of redundant edge pruning of the initial parameter flow network in step S124, so that the parameter dependency relationship is expressed in the simplest form, which is convenient for subsequent processing.

[0160] Figure 3 This document illustrates an execution status interface during steps S150 and S750 to S780 of an embodiment of the present invention. After completing the division of parallel tool call groups, the system executes step S150, generating a batch tool call instruction sequence based on the dependencies between groups. Figure 3The "Batch Scheduling Instruction Sequence" panel on the right clearly displays the results of the topology sorting, forming a strict execution order of "Batch 1: Parallel Group A", "Batch 2: Parallel Group B", and "Batch 3: Output Aggregation". This corresponds to step S153, which performs topology sorting on the dependency graph between groups to obtain the group batch hierarchy sequence. The progress bar (e.g., 68% progress for "Batch 2") and status icon (e.g., "Completed" for "Batch 1") in the batch cards reflect the real-time progress of the parallel batch tool call operation in step S155, where the tool execution agent executes the operation. It is particularly noteworthy that within the "Batch 2" group, the system performs "vulnerable link detection" on the "Channel C Launch Tool" and injects a "copy". This corresponds to steps S720 to S750: The system first calculates and labels the tool call cost (step S710), then identifies the fragile dependency link of the tool call (step S730), locates the single point of failure bottleneck node (step S740), and finally executes the tool call redundant copy injection (step S750), forming the "parameter dual-source dependency structure" shown in the figure. Figure 3 The "Optimization of inter-batch data transfer" prompt on the right corresponds to steps S910 to S950. That is, after the system detects that the amount of inter-batch data transfer exceeds the threshold, it packages the output parameters into an inter-batch data transfer data packet and transfers it to the subsequent batches at once to reduce the number of data transfers and improve the overall scheduling efficiency.

[0161] Figure 4This section illustrates the configuration and confirmation interfaces for key decision points during the execution of this embodiment of the invention, showcasing the manual intervention and fine-tuning mechanisms involved in the system beyond steps S130 to S150. The "Parallel Tool Call Group Partition Result" modal in the upper left corner displays the group partitioning statistics generated in step S135 and provides an entry point for "Re-partitioning," allowing users to manually adjust the partitioning based on automatic partitioning. The "Tool Call Redundant Copy Injection" modal in the upper right corner is the specific operation interface for executing steps S770 to S780. Here, users confirm the injection of a redundant copy into the single-point-of-failure bottleneck node "Channel C Uploading Tool" and confirm its dual-source dependency structure, ensuring that the system can receive the data body that returns the first complete output result during subsequent execution. The "Side Effect Virtual Barrier Management" modal in the lower left corner corresponds to the execution of steps S1010 to S1050. When the system detects conflicting modification operations on the same external state resource by "Channel A Publishing Tool" and "Channel C Listing Tool" in steps S1010 and S1020, it prompts the user through this interface and inserts a virtual barrier node (step S1030). This barrier node acts as a mandatory dependency edge (step S1050), ensuring that the two tools are assigned to different batch levels and executed in a strict order in the subsequent parallel tool call group partitioning results (step S1040). The "Semantic Equivalent Parameter Node Replacement" modal in the lower right corner corresponds to the execution of steps S810 to S860. This interface is used to configure the semantic equivalent parameter set and, when the data representation format does not match (such as the upstream output data format being inconsistent with the downstream tool requirements), performs data representation format adaptation conversion (step S850), ultimately replacing the original node with a substitute parameter node and updating the parameter flow topology (step S860).

[0162] In an exemplary embodiment, a tool invocation optimization system for large language models is provided. This system can be a terminal, server, etc., and its internal structure includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computational and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements a tool invocation optimization method for large language models. The display unit is used to form a visually visible image and can be a display screen, projection device, or virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the shell of the tool call optimization system for large language models, or an external keyboard, touchpad, or mouse, etc.

[0163] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A tool invocation optimization method for large language models, characterized in that, The method includes: Obtain the initial tool invocation planning chain generated by the large language model in response to the user request text sequence. The initial tool invocation planning chain contains multiple tool identifiers to be invoked arranged in execution order, and each tool identifier to be invoked is associated with a corresponding tool input parameter declaration. The initial tool call planning chain is decoupled from the tool call dependency. The parameter passing mapping relationship between the tool input parameter declarations associated with each tool identifier to be called is extracted. A parameter flow topology structure with parameter declarations as nodes is constructed. The connection edges between nodes in the parameter flow topology structure represent the data source dependency between parameter declarations. In the parameter flow topology, detect a set of tool identifiers to be invoked that have a common upstream parameter declaration node and no data source dependency between them, mark the set of tool identifiers to be invoked as a parallel callable tool group, and generate a parallel tool invocation group partitioning result. For each parallel callable tool group in the parallel tool call group partitioning result, parameter actual parameter binding processing is performed on the tool input parameter declaration. Based on the upstream parameter declaration node in the parameter flow topology, the actual parameter data body is obtained according to the tool input parameter declaration of each tool input parameter declaration. The actual parameter data body is used to replace the corresponding tool input parameter declaration to obtain the actual parameter binding tool call group instruction. Based on the parameter flow dependency order among the parallel callable tool groups in the parallel tool call group partitioning result, the actual parameter binding tool call group instructions are arranged into a batch tool call instruction sequence according to the dependency order, and the batch tool call instruction sequence is sent to the tool execution agent to trigger the parallel batch tool call operation.

2. The tool invocation optimization method for large language models according to claim 1, characterized in that, The initial tool invocation planning chain is decoupled from its invocation dependency. The parameter passing mapping relationship between the tool input parameter declarations associated with each tool identifier to be invoked is extracted. A parameter flow topology is constructed with parameter declarations as nodes. The connecting edges between nodes in the parameter flow topology represent the data source dependency between parameter declarations, including: Iterate through each tool identifier to be invoked in the initial tool invocation planning chain, parse the tool input parameter declaration associated with the tool identifier to be invoked, instantiate each tool input parameter declaration as a parameter node, and record the tool identifier to which the parameter node belongs as the parent tool identifier; Perform parameter source tracing and comparison processing on any two parameter nodes. When the parameter declaration represented by the first parameter node is identified as an output parameter from the parent tool identifier of the second parameter node, establish a directed connection edge from the second parameter node to the first parameter node. After instantiating all tool input parameter declarations associated with the identifiers of the tools to be invoked in the initial tool invocation planning chain into parameter nodes and completing the parameter source tracing and comparison process, an initial parameter flow network with parameter nodes as the basic constituent units is formed. Redundant edge pruning is performed on the initial parameter flow network. Multi-hop transit dependency paths between parameter nodes are detected. When a direct directed connection edge and an indirect transit path simultaneously connect the same two parameter nodes, the direct directed connection edge is removed, and the intermediate parameter nodes and corresponding connection edges traversed by the indirect transit path are retained to obtain a simplified parameter flow network. The parent tool identifier of each parameter node in the simplified parameter flow network is labeled as a node attribute. Parameter nodes that share the same parent tool identifier are aggregated based on the labeled parent tool identifier to generate a parameter flow topology with the tool as the external view. The connecting edges between nodes in the parameter flow topology represent the parameter data source dependency across tools.

3. The tool invocation optimization method for large language models according to claim 1, characterized in that, The process involves detecting a set of tool identifiers to be invoked in the parameter flow topology that share a common upstream parameter declaration node and have no data source dependency among them, marking the set of tool identifiers to be invoked as a parallel invokeable tool group, and generating a parallel tool invocation group partitioning result, including: For each parameter node in the parameter flow topology, perform an upstream tracing traversal, and trace all ancestor parameter nodes of the parameter node in reverse along the directed connection edges in the parameter flow topology to generate a set of ancestor parameter nodes for each parameter node. Perform a union operation on the set of ancestor parameter nodes of all parameter nodes belonging to the same tool identifier to be invoked to obtain the tool-level upstream dependency parameter node set of the tool identifier to be invoked. The tool-level upstream dependency parameter node set contains all parameter declarations that must be ready before the tool identifier to be invoked is executed. For all tool identifiers to be invoked, perform pairwise comparisons of the tool-level upstream dependency parameter node sets. When two tool identifiers to be invoked have an intersection of their tool-level upstream dependency parameter node sets, it is determined that there is a parameter dependency relationship between the two tool identifiers to be invoked. When the tool-level upstream dependency parameter node sets of two tool identifiers to be invoked do not intersect, it is further checked whether the two tool identifiers to be invoked exist in the tool identifier set associated with each other's tool-level upstream dependency parameter node set. If they do not contain each other, it is determined that the two tool identifiers to be invoked have no data source dependency on each other. The identifiers of the tools to be invoked that have no data source dependency on each other and whose upstream dependency parameter node sets have common parameter nodes are grouped into the same parallel callable tool group. A batch partitioning identifier is assigned to each parallel callable tool group to generate the parallel tool invocation group partitioning result.

4. The tool invocation optimization method for large language models according to claim 1, characterized in that, The process of binding actual parameters to the tool input parameter declarations within each parallel callable tool group in the parallel tool call group partitioning result, obtaining the actual parameter data body from the upstream parameter declaration node in the parameter flow topology based on each tool input parameter declaration, and replacing the corresponding tool input parameter declaration with the actual parameter data body to obtain the actual parameter bound tool call group instruction, includes: For each tool identifier to be invoked in the currently processed parallel callable tool group in the parallel tool call group partitioning result, extract all tool input parameter declarations associated with the tool identifier to be invoked, and construct a group-level parameter declaration summary set; Traverse each tool input parameter declaration in the group-level parameter declaration summary set, locate the parameter node corresponding to the tool input parameter declaration in the parameter flow topology, and trace back to the direct upstream parameter declaration node along the incoming edge direction of the parameter node; Extract the actual parameter data body from the output result storage area of ​​the completed tool corresponding to the direct upstream parameter declaration node. The actual parameter data body is the specific parameter value output after the upstream tool has finished executing. Establish a binding mapping record between the declared tool input parameters and the extracted actual parameter data body, mark the declared tool input parameters in the tool call instruction as placeholders, and fill the corresponding actual parameter data body into the parameter value position to obtain a single tool call instruction with completed actual parameter binding; All individual tool call instructions that have completed argument binding within the parallel callable tool group are aggregated into the argument-bound tool call group instruction.

5. The tool invocation optimization method for large language models according to claim 1, characterized in that, The step of arranging the actual parameter binding tool call group instructions into a batch tool call instruction sequence according to the parameter flow dependency order among the parallel callable tool groups in the parallel tool call group partitioning result, and sending the batch tool call instruction sequence to the tool execution agent to trigger the parallel batch tool call operation includes: Extract the set of tool-level upstream dependency parameter nodes for each parallel callable tool group from the parallel tool call group partitioning results, and determine the set of preceding dependency groups for the parallel callable tool group based on the identifier of the tool to be called associated with the set of tool-level upstream dependency parameter nodes. Based on the set of preceding dependent groups of each parallel callable tool group, a dependency graph between groups is constructed. In the dependency graph between groups, each parallel callable tool group is used as a graph node, and directed connection edges are drawn from the dependent group node to the subsequent group node that depends on the dependent group node. The topological sorting process is performed on the inter-group dependency graph. Group nodes with an in-degree of zero are taken out as the first priority batch, and the corresponding batch group nodes and their outgoing edges are removed from the graph. This topological sorting process is iterated until all group nodes are assigned a batch level, resulting in a group batch level sequence. According to the order of the group batch hierarchy sequence, the actual parameter binding tool call group instructions of the parallel callable tool group corresponding to each batch level are arranged in the order of the batch hierarchy. The actual parameter binding tool call group instructions with the same batch level are placed in the same batch to generate the batch tool call instruction sequence. The batch tool call instruction sequence is sent to the tool execution agent. The tool execution agent allocates parallel execution threads for the parameter-bound tool call group instructions within the same batch, and serially schedules the parameter-bound tool call group instructions across batches according to the batch hierarchy, triggering parallel batch tool call operations.

6. The tool invocation optimization method for large language models according to claim 1, characterized in that, The method further includes: During the execution of the batched tool call instruction sequence by the tool execution agent, the tool call response data stream of each tool call execution instance in the tool execution agent is collected in real time during the call lifecycle. The tool call response data stream includes a tool call status code sequence and the number of time-by-time output parameter bytes arriving. The cumulative curve fitting process is performed on the number of output parameter bytes arriving at each time step to generate the output parameter data arrival progress curve for each tool call execution instance. The horizontal axis of the output parameter data arrival progress curve is the unit of measurement for call time, and the vertical axis is the cumulative value of output parameter bytes that have been transmitted. The output parameter data arrival progress difference between each tool call execution instance is calculated based on the output parameter data arrival progress curve. When the vertical axis difference between the output parameter data arrival progress curve of the first tool call execution instance and the output parameter data arrival progress curve of the second tool call execution instance is lower than the preset progress difference threshold at the same call time unit, a synchronous correlation relationship of output rhythm is established between the first tool call execution instance and the second tool call execution instance. Tool call execution instances that have established output rhythm synchronization relationships are grouped into the same output synchronization tool instance group. The output result data bodies of each tool call execution instance in the same output synchronization tool instance group are aggregated and received. After the output result data bodies of all tool call execution instances in the same output synchronization tool instance group have arrived completely, the entire group of output result data bodies is submitted to the tool call global output buffer area at once. The output result data body within the same output synchronization tool instance group is subjected to cross-reference verification of output parameters. The system detects whether there are parameter value conflicts pointing to the same entity in the output parameter key-value pair set of different tool call execution instances. When a parameter value conflict is detected, the system selects the output parameter value of the tool call execution instance that is closer to the final output node in the node level of the parameter flow topology according to the tool identifier of the tool call execution instance that caused the parameter value conflict. Replace the corresponding conflicting parameter values ​​in the output parameter key-value pair set of other tool call execution instances within the output synchronization tool instance group with the authoritative parameter value after conflict resolution, generate the tool instance group output dataset with resolved parameter conflicts, and write the tool instance group output dataset with resolved parameter conflicts into the tool call global output buffer.

7. The tool invocation optimization method for large language models according to claim 1, characterized in that, The method further includes: The parameter declaration syntax tree is parsed for the tool input parameter declaration associated with each tool identifier to be invoked in the initial tool invocation planning chain, and the parameter name identifier, parameter data type description and parameter nesting structure level of each tool input parameter declaration are extracted. Based on the parameter data type description and parameter nesting structure hierarchy, the tool input parameter declaration is subjected to parameter template abstraction processing. The parameter name identifier of the tool input parameter declaration with the same parameter nesting structure hierarchy is replaced with a parameter type placeholder to obtain a parameter abstract template. The parameter abstract template retains the parameter nesting structure hierarchy and parameter data type description, but strips away the specific parameter name identifier. The parameter abstract template is matched with the input parameter pattern definition of the registered tools in the tool execution agent. The overlap of parameter nesting structure and the consistency of parameter data type description between the parameter abstract template and the input parameter pattern definition of each registered tool are calculated. A set of candidate replacement tools is selected based on the overlap of parameter nesting structure and the consistency of parameter data type description. Select alternative tool identifiers with different tool call response time characteristics from the alternative tool candidate set, and generate a dual-channel tool call alternative scheme that includes the original tool identifier to be called and the alternative tool identifier; When performing the parameter binding process, the parameter data body binding operation is performed on the original tool identifier to be called and the alternative tool identifier to generate the original parameter binding tool call instruction and the alternative parameter binding tool call instruction respectively. The original argument-bound tool call instruction and the alternative argument-bound tool call instruction are simultaneously sent to mutually isolated execution channels in the tool execution agent for parallel competitive execution. The output result data body of the tool call instruction corresponding to the execution channel that returns the complete tool execution output result data body first is received as the final output result data body of the tool call node.

8. The tool invocation optimization method for large language models according to claim 1, characterized in that, The method further includes: During the execution of the batched tool call instruction sequence by the tool execution agent, the set of output parameter key-value pairs of each tool call execution instance that has been stored in the global output buffer of the tool call is marked with output parameter lifecycle. For each output parameter key-value pair, an additional parameter effective batch identifier and parameter validity period batch count are added. The parameter effective batch identifier is the batch level number when the output parameter is generated, and the parameter validity period batch count is the number of remaining valid batches that the output parameter can be referenced by subsequent batch levels. When it is detected that the tool input parameter declaration associated with the tool identifier to be invoked in the subsequent batch level needs to reference the target output parameter key-value pair in the tool invocation global output buffer, the parameter validity batch count attached to the target output parameter key-value pair is read. If the parameter validity batch count is greater than zero, the tool identifier to be invoked is allowed to read the target output parameter value from the tool invocation global output buffer, and the parameter validity batch count of the target output parameter key-value pair is decremented and updated. If the batch count of the parameter validity period is zero, then the tool identifier to be invoked is prohibited from reading the target output parameter value from the tool call global output buffer, triggering the tool call re-execution operation of the upstream tool call execution instance corresponding to the target output parameter value, and inserting the tool call re-execution instruction into the supplementary re-execution batch before the current batch level; After the tool call re-execution operation is completed, the newly generated output parameter key-value pairs will replace the expired original output parameter key-value pairs in the tool call global output buffer, and the parameter validity batch count will be reset for the new output parameter key-value pairs. Based on the dependency path length between each parameter node in the parameter flow topology, the initial value of the parameter validity period batch count is dynamically adjusted so that the output parameter key-value pairs corresponding to parameter nodes with longer dependency path lengths are assigned larger initial values ​​for parameter validity period batch counts.

9. The tool invocation optimization method for large language models according to claim 1, characterized in that, The method further includes: After obtaining the initial tool call planning chain, the user request text sequence is split into multiple independent semantic fragment units, and the single tool call requirement corresponding to each independent semantic fragment unit is identified. For each independent semantic fragment unit, an independent tool call planning generation process is performed on the single tool call requirement corresponding to each independent semantic fragment unit, and an independent tool call planning sub-chain containing multiple independent tool identifiers to be called arranged in execution order is generated for each independent semantic fragment unit; The independent tool identifiers to be invoked in each independent tool invocation planning subchain are deduplicated and merged across subchains. Redundant tool identifiers to be invoked with the same tool identifier and the same tool input parameter declaration characteristics in different independent tool invocation planning subchains are identified and merged into a common tool invocation node. The non-redundant tool identifiers to be invoked in each independent tool invocation planning sub-chain are interleaved and arranged across sub-chains according to their invocation dependency order in the original independent tool invocation planning sub-chain. The tool identifiers to be invoked from different independent tool invocation planning sub-chains are interleaved according to the data source dependency relationship in the parameter flow topology to generate a cross-sub-chain interleaved tool invocation planning chain. The initial tool call planning chain is replaced by the cross-subchain interleaved tool call planning chain as input to the tool call dependency decoupling process, and the subsequent parallel tool call group partitioning and batch scheduling processes are re-executed.

10. A tool invocation optimization system for large language models, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the tool invocation optimization method for large language models according to any one of claims 1 to 9 by executing the machine-executable instructions.

Images