Model tool calling method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a model tool calling method and device, a nonvolatile storage medium and electronic equipment. The method comprises the steps that a tool topological graph corresponding to a tool library is determined; after receiving a task description text of the target task, iteratively determining a candidate tool set corresponding to the target task according to the task description text and the tool topological graph; and in the process of iteratively determining the candidate tool set corresponding to the target task, after the candidate tool set is determined each time, indicating the model to select a target tool for executing the target task from the candidate tool set. According to the method and the device, the technical problems of high computing power resource consumption, low tool selection accuracy and unstable parameter generation caused by blind exposure of all tools in a multi-tool scene in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and more specifically, to a method, apparatus, non-volatile storage medium, and electronic device for invoking model tools. Background Technology

[0002] The existing ReAct architecture, when facing multi-tool scenarios, blindly exposes all tools to the Large Language Model (LLM), resulting in high token consumption, low accuracy in tool selection, and unstable parameter generation. These issues are particularly problematic when dealing with a large number of tools and complex, variable tasks, severely impacting system performance and user experience. Furthermore, the lack of online learning and dynamic optimization mechanisms based on historical execution results prevents the system invocation strategy from adaptively improving, leading to long-term performance limitations.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a model tool invocation method, apparatus, non-volatile storage medium, and electronic device to at least solve the technical problems of high computational resource consumption, low tool selection accuracy, and unstable parameter generation caused by blindly exposing all tools when facing multi-tool scenarios.

[0005] According to one aspect of the embodiments of this application, a model tool invocation method is provided, comprising: determining a tool topology graph corresponding to a tool library, wherein nodes in the tool topology graph correspond to tools in the tool library, edges between nodes are used to represent execution invocation relationships between nodes, and tools are used to execute preset data processing methods; after receiving a task description text of a target task, iteratively determining a set of candidate tools corresponding to the target task based on the task description text and the tool topology graph; during the iterative determination of the set of candidate tools corresponding to the target task, after each determination of the set of candidate tools, instructing the model to select a target tool from the set of candidate tools to execute the target task.

[0006] Optionally, based on the task description text and the tool topology graph, the iterative determination of the candidate tool set corresponding to the target task includes: in the first iteration, determining an initial candidate tool set from the tool library based on the semantic information of the task description text; in subsequent iterations, determining the target candidate tool set corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, wherein the nodes corresponding to the candidate tools in the target candidate tool set and the nodes corresponding to the target tool are connected by edges in the tool topology graph.

[0007] Optionally, after determining the target candidate tool set corresponding to this iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the edge weights corresponding to each candidate tool in the target candidate tool set; normalizing the edge weights to obtain the tool weights corresponding to the candidate tools, wherein the tool weights are used to reflect the priority of the candidate tools, and the larger the tool weights, the higher the priority.

[0008] Optionally, after determining the set of target candidate tools for this iteration based on the target tools selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the target tools selected in each iteration when the iteration termination condition is met and the processing results do not match the task description text; determining the edges to be adjusted in the tool topology graph based on the target tools selected in each iteration, wherein the edges to be adjusted are the edges connecting the nodes corresponding to the target tools in the tool topology graph; and reducing the edge weights of the edges to be adjusted.

[0009] Optionally, the input configuration information corresponding to the tools in the tool library is determined, wherein the input configuration information includes the input parameter model class and input indication information corresponding to the tool, and the input indication information is used to indicate the field type of the candidate tool that is prohibited from input; the input parameter validation standard corresponding to the tool is determined based on the input configuration information, and the input parameter validation standard and the input configuration information are bound together.

[0010] Optionally, instructing the model to select a target tool from the candidate tool set to perform the target task includes: obtaining a tool invocation instruction generated by the model; determining whether the tool indicated by the tool invocation instruction is a tool in the candidate tool set, and if it is confirmed to be a tool in the candidate tool set, determining the tool indicated by the tool invocation instruction as the target tool, and verifying the input parameters of the target tool according to the input parameter verification standard corresponding to the target tool.

[0011] Optionally, a target tool sequence is determined, wherein the target tool sequence includes all target tools invoked during the execution of the target task; execution feedback information corresponding to each target tool in the target tool sequence is determined; and edge weights in the tool topology graph are updated based on the execution feedback information.

[0012] According to another aspect of the embodiments of this application, a model tool invocation device is also provided, comprising: a first processing module, configured to determine a tool topology graph corresponding to a tool library, wherein nodes in the tool topology graph correspond to tools in the tool library, edges between nodes are used to represent execution invocation relationships between nodes, and tools are used to execute preset data processing methods; a second processing module, configured to, after receiving a task description text of a target task, iteratively determine a set of candidate tools corresponding to the target task based on the task description text and the tool topology graph; and a third processing module, configured to, during the iterative determination of the set of candidate tools corresponding to the target task, instruct the model to select a target tool from the set of candidate tools to execute the target task after each determination of the set of candidate tools.

[0013] According to another aspect of the embodiments of this application, a non-volatile storage medium is also provided, wherein a program is stored in the non-volatile storage medium, and the program controls the device where the non-volatile storage medium is located to execute a model tool invocation method during runtime.

[0014] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program executes a model tool invocation method during runtime.

[0015] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of a model tool invoking method.

[0016] In this embodiment, a tool topology graph corresponding to the tool library is determined. Nodes in the tool topology graph correspond to tools in the tool library, and edges between nodes represent execution call relationships. Tools are used to execute preset data processing methods. After receiving the task description text of the target task, a set of candidate tools corresponding to the target task is iteratively determined based on the task description text and the tool topology graph. During the iterative determination of the set of candidate tools corresponding to the target task, after each determination of the candidate tool set, the model is instructed to select a target tool from the candidate tool set to execute the target task. By dynamically generating candidate subsets and using an online learning feedback mechanism, the scope of tool selection is limited and the reliability of parameter generation is improved. This achieves the technical effects of reducing token consumption, improving tool selection accuracy, and enhancing system robustness and adaptability. Furthermore, it solves the technical problems of high computational resource consumption, low tool selection accuracy, and unstable parameter generation caused by blindly exposing all tools in multi-tool scenarios. Attached Figure Description

[0017] Figure 1This is a schematic diagram of the hardware structure of a computer terminal (or mobile device) according to an embodiment of this application;

[0018] Figure 2 This is a schematic diagram of a model tool invocation method provided in an embodiment of this application;

[0019] Figure 3 This is a schematic diagram of a partial structure of a tool topology diagram according to an embodiment of this application;

[0020] Figure 4 This is a flowchart illustrating a task processing procedure according to an embodiment of this application;

[0021] Figure 5 This is a flowchart illustrating another task execution process provided according to an embodiment of this application;

[0022] Figure 6 This is a flowchart illustrating yet another task execution process provided according to an embodiment of this application;

[0023] Figure 7 This is a schematic diagram of a model tool calling device provided according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] To better understand the embodiments of this application, the technical terms involved in the embodiments of this application are explained below:

[0027] Large Language Model (LLM): A deep learning model trained on a large-scale corpus that can understand and generate natural language text. In this invention, the LLM serves as the core inference engine, responsible for selecting the appropriate tool based on the user's task and generating the calling parameters.

[0028] The Reasoning and Action Framework (ReAct, Reason + Act) is a reasoning and tool-calling architecture for large language models. Its core idea is to simultaneously generate "reasoning" and "acting" during dialogue, enhancing the model's capabilities by calling external tools. This invention improves upon ReAct by introducing tool graphs and online learning mechanisms.

[0029] Tool Graph: A directed weighted graph structure used to represent dependencies and preferred invocation paths between tools. Nodes represent tools, edges represent feasible invocation sequences, and edge weights represent path priority. This invention uses the tool graph to constrain the range of tool selection, achieving candidate subset control.

[0030] Candidate Subset: This refers to the set of successor nodes provided by the tool graph that the LLM is allowed to select tools from at each step of inference. This invention utilizes candidate subset constraints to avoid exposing all tools to the model, reducing token consumption and false call rate.

[0031] Function Calling: An interface form in LLM that allows the model to directly generate call requests and parameters that conform to the function signature of the utility. This invention utilizes Function Calling to limit the range of utility selection and generate structured parameters.

[0032] Pydantic Schema: A Python-based method for data validation and model definition. This invention uses Pydantic v2 to define tool parameter schemas and sets extra="forbid" to strictly prohibit redundant fields and ensure the validity of called parameters.

[0033] Heuristic Fallback Strategy: When the LLM fails to generate a valid tool call, this invention selects a tool using a heuristic algorithm based on semantic relevance and tool graph weights, and automatically generates minimum feasible parameters to ensure that the system process is not interrupted.

[0034] Online Learning Feedback: A mechanism that dynamically adjusts the edge weights of the tool graph based on the tool call results (success or failure). Successful paths have stronger edge weights, while failed paths have weaker edge weights, achieving adaptive optimization of the system.

[0035] Edge Weight: The weight value of an edge in the tool graph, representing the priority from one tool node to another. This invention uses an online learning mechanism to interpolate and update edge weights, gradually optimizing the tool selection strategy.

[0036] Stopping Condition: The conditions under which the system determines whether a task is completed, including reaching the maximum number of steps or obtaining a numerical result that meets the requirements. This invention controls the convergence of the inference process through stopping conditions.

[0037] In related technologies, Large Language Models (LLMs) such as the ReAct framework typically provide the model with the descriptions and signatures of all tools when handling tasks involving tool calls, allowing the model to select the appropriate tool and parameters based on the input and context. This method works effectively when the number of tools is small. However, as the toolset expands and task complexity increases, LLMs face problems such as excessively long prompts leading to a surge in token costs. Furthermore, in unconstrained tool selection, the model is prone to making erroneous calls, selecting tools irrelevant to the task or invalid ones. In addition, the lack of rigorous validation in parameter generation often results in call requests with mismatched types, redundant or missing fields. These factors combined not only reduce inference efficiency but also significantly increase the call failure rate, challenging system stability and security. Therefore, the problems of low tool call efficiency, high erroneous call rate, and unreliable parameter calls exist. To address these issues, this application provides relevant solutions, which are detailed below.

[0038] According to an embodiment of this application, a method embodiment for invoking a model tool is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0039] The methods and embodiments provided in this application can be executed on mobile terminals, computer terminals, or similar computing devices. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a model tool invocation method is shown. Figure 1As shown, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0040] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the model tool invocation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned model tool invocation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0042] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0043] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0044] Under the above operating environment, this application embodiment provides a method for invoking model tools, such as... Figure 2 As shown, the method includes the following steps:

[0045] Step S202: Determine the tool topology graph corresponding to the tool library, wherein the nodes in the tool topology graph correspond to the tools in the tool library, the edges between nodes are used to represent the execution call relationship between nodes, and the tools are used to execute preset data processing methods;

[0046] In some embodiments of this application, to determine the tool topology of the tool library, all tools and their data processing methods can be listed first. Then, the execution call order between tools can be determined through static code analysis (such as call relationships, interface matching), dynamic runtime tracing (such as logs, debugging), or data flow analysis (such as input / output matching). Finally, each tool is treated as a node, and the call relationship is treated as a directed edge to construct the topology graph. The direction of the edge represents the execution order between two tools.

[0047] In some embodiments of this application, a portion of the tool topology graph structure is as follows: Figure 3 As shown. From Figure 3 As can be seen, some tool nodes are connected by two edges in opposite directions. This indicates that there are two different execution orders between the two tools.

[0048] In some embodiments of this application, to avoid infinite loops when calling tools, an upper limit on the number of steps in `is_done` combined with a scenario-based stopping condition can be used to limit any loop to a finite number of steps, thus preventing infinite loops. Additionally, online learning can be used to gradually reduce the weight of worthless loop paths, making the tool call paths corresponding to these low-weight paths less likely to be selected in actual operation.

[0049] In some embodiments of this application, input configuration information corresponding to tools in the tool library can also be determined. This input configuration information includes the input parameter model class and input indication information corresponding to the tool. The input indication information is used to indicate the field types that are prohibited from being input into candidate tools. Then, the input parameter validation standard corresponding to the tool can be determined based on the input configuration information, and the input parameter validation standard and input configuration information can be bound together.

[0050] Step S204: After receiving the task description text of the target task, iteratively determine the set of candidate tools corresponding to the target task based on the task description text and the tool topology diagram;

[0051] In some embodiments of this application, the step of iteratively determining the candidate tool set corresponding to the target task based on the task description text and the tool topology graph includes: in the first iteration, determining an initial candidate tool set from the tool library based on the semantic information of the task description text; in the iterations that are not the first iteration, determining the target candidate tool set corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, wherein the nodes corresponding to the candidate tools in the target candidate tool set and the nodes corresponding to the target tool are connected by edges in the tool topology graph.

[0052] Step S206: In the process of iteratively determining the set of candidate tools corresponding to the target task, after each determination of the set of candidate tools, the model is instructed to select the target tool from the set of candidate tools to perform the target task.

[0053] In some embodiments of this application, after determining the target candidate tool set corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the edge weights corresponding to each candidate tool in the target candidate tool set; normalizing the edge weights to obtain the tool weights corresponding to the candidate tools, wherein the tool weights are used to reflect the priority of the candidate tools, and the larger the tool weights, the higher the priority.

[0054] In some embodiments of this application, after determining the set of target candidate tools corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the target tool selected in each iteration when the iteration termination condition is met and the processing result obtained does not match the task description text; determining the edge to be adjusted in the tool topology graph based on the target tool selected in each iteration, wherein the edge to be adjusted is the edge connecting the node corresponding to the target tool in the tool topology graph; and reducing the edge weight of the edge to be adjusted.

[0055] Optionally, through a candidate subset constraint mechanism, the successor nodes of relevant tools can be exposed to the LLM (the model in step S206) only at each step, significantly reducing the length of prompt words and token consumption, while improving the accuracy of tool selection. The steps of the tool graph-based candidate subset constraint mechanism provided in this application embodiment are as follows:

[0056] Step 1 (Constructing the Tool Graph Topology): Define a directed weighted graph G=(V,E), where V represents the set of nodes, each node corresponds to a callable tool; E represents the set of edges, each edge (u,v) indicates that tool u can legally call tool v; each edge is assigned a weight w. [0,1] is used to represent the prior confidence or historical success rate of the call path.

[0057] Unlike related technologies that allow LLMs to work with all tools, tool graphs only allow LLMs to work with the successor set of the previous tool. This selection process significantly reduces the candidate size, improving both efficiency and accuracy. The candidate subset constraint formula is as follows:

[0058]

[0059] in, Indicates the first The "thought" generated by the LLM process. The parameter is Large language models Representing historical context (including past observations) ,think ,action (Triple sequence). Indicates the first Step-by-step environmental observation Indicates the first A subset of candidate tools for the step; The subset selection strategy is determined by the tool graph. This indicates the action selected in the previous round.

[0060] Step 2 (Initializing Edge Weights and Initial Candidate Set): Assign initial weights to each edge. Weight values ​​are determined based on domain expert experience or historical data analysis: high-frequency, reasonable paths are assigned higher weights (e.g., 0.7~0.9), low-frequency but potentially viable paths are assigned medium weights (e.g., 0.3~0.5), and unreasonable paths are not connected by edges. Simultaneously, define the initial candidate set. , indicates the set of tools that are allowed to be invoked as the first step in the initial stage of the task:

[0061] The task can legally begin

[0062] For example: search_docs,calc It can be configured using the function set_start(C_0).

[0063] like That is, if the initial candidate set is empty, then the first step candidate set... Dynamically generated by the task recall module, depending on the user task. Semantic matching:

[0064]

[0065] in, For tools Description text (including functional specifications, signature, etc.), similarity Indicates task The semantic similarity with the tool description (based on BoW + cosine similarity), TopK(·) represents taking the top K with the highest similarity. Tools (such as) ).

[0066] Step 3 (Dynamically Generate Candidate Subset): During task execution, dynamically generate a list of candidate tools for the next step based on the current state.

[0067] (1) If it is the first step of the task (i.e. there is no preceding tool or step=0), the initial candidate set is used as the candidate tool list, the initial weight of each tool is set to 1.0, and an ordered candidate pair list [(tool_name, weight), ...] is generated accordingly;

[0068] (2) If not the first step, then query all successor nodes of the current tool in the tool graph to form a candidate list. The successor function is defined as:

[0069]

[0070] in, This indicates the last tool that has been executed (i.e., the "current tool"). Indicate candidate tools, It is an edge set.

[0071] (3) If the current tool has no successor node, it will fall back to the initial candidate set, but the weight will be reduced to half of the original weight or other preset ratio, indicating "restart process";

[0072] (4) Normalize all candidate weights so that their sum is 1.0. The incremental weights are normalized to ensure that all weights from the candidate list are equal. The sum of the transition probabilities at the start is 1, ensuring the probabilistic meaning. The formula for the normalized neighbor increment is as follows:

[0073]

[0074] in, Indicates from node The set of all subsequent neighbors of the originating point. Represents a node The score accumulated in the nth iteration.

[0075] (5) Arrange the subsets in descending order of weight to generate the final candidate subset.

[0076] Step 4 (Passing the Candidate Subset to the Decision Module): Map the generated list of candidate tool names to the corresponding list of tool objects, and bind only these tools through the `bind_tools` interface of the large language model. Simultaneously, explicitly inform the model in the system prompt: "You can only choose from the following tools," along with a functional description, parameter signature, and priority (normalized weights) of each tool. The model's output `tool_calls` will be limited to the candidate set. The system validates the output tool names; if they are not in the candidate set, they are considered invalid choices, triggering fallback processing logic.

[0077] In some embodiments of this application, the initial weight of a tool is primarily used to reflect its relative importance or applicability in a specific task or scenario. This is a priori estimate of the tool's potential contribution or frequency of invocation at the start of the task. For example, for common knowledge retrieval tasks, the `search_docs` tool might be assigned a higher initial weight because it is often the preferred first step for quickly locating relevant information. This weight guides the Large Language Model (LLM) to favor tools with higher weights during the initial invocation, thereby reducing invalid invocations and improving process efficiency.

[0078] In some embodiments of this application, the relationship between the candidate weights and edge weights of tools is as follows: In each iteration, the tool graph constraint module dynamically generates a set of candidate tools based on the current execution state and the edge weights in the tool graph. The candidate weights here are actually normalized edge weights, used to reflect the priority of a candidate tool being called in the current state. Tools with higher edge weights will appear with higher weights in the candidate set, meaning that the LLM is more likely to consider these tools when selecting the next operation. Conversely, tools with lower edge weights, even if they appear in the candidate set, will have a correspondingly lower probability of being selected. Edge weights play a role in selecting the candidate tool set. Edge weights reflect the historical frequency, success rate, and domain expert experience assessments of tool calls, used to quantify the credibility or effectiveness of tool call paths. When generating the candidate tool set, edge weights are used to determine which tools can be subsequent steps of the current tool, and their call priorities. Specifically, if there is a series of successor tools to choose from starting with the current tool, then tools with higher edge weights will be given priority in being added to the candidate set, and their weight values ​​will directly affect the ranking of candidate tools.

[0079] In some embodiments of this application, the step of instructing the model to select a target tool from a set of candidate tools to perform a target task includes: obtaining a tool invocation instruction generated by the model; determining whether the tool indicated by the tool invocation instruction is a tool in the set of candidate tools, and if it is confirmed to be a tool in the set of candidate tools, determining that the tool indicated by the tool invocation instruction is the target tool, and verifying the input parameters of the target tool according to the input parameter verification standard corresponding to the target tool.

[0080] Optionally, strict parameter validation can be implemented using Pydantic Schema to ensure correct parameter types and complete fields, effectively preventing illegal calls caused by instability in LLM generation. When validating the input parameters of the target tool, a collaborative mechanism of large model decision-making and strict parameter validation can be adopted. The specific implementation steps are as follows:

[0081] Step 1 (Define a strongly typed schema for tool parameters): Define a corresponding input parameter model class for each callable tool, using the Pydantic v2 framework to inherit from BaseModel, and annotate the semantics of the fields using Field. The key configuration is model_config = ConfigDict(extra="forbid"), which indicates that undeclared additional fields are prohibited in the input. Then, use this schema as the standard for subsequent parameter validation and bind it to the corresponding tool object.

[0082] Step 2 (Binding Candidate Tools to the Large Language Model): Before each step, obtain the current list of valid candidate tools and register only these tools as available functionality using the `LLM.bind_tools(candidate_tools)` method. The system prompt explicitly states: "Only select from the following tools," along with the description, signature, and priority of each tool. This limits the output scope of the LLM, preventing it from calling illegal or irrelevant tools.

[0083] Step 3 (Generating Tool Call Requests from Large Model): Based on the user task, historical execution trajectory, and candidate tool information, the large language model generates a structured output of `tool_calls`, containing the tool name and a dictionary of arguments. For example:

[0084] {

[0085] "name": "calc",

[0086] "arguments": {"expr": "pi (3 2)"}

[0087] }

[0088] This process fully leverages the semantic understanding and contextual reasoning capabilities of LLM to achieve intelligent decision-making.

[0089] Step 4 (Initial Screening for Tool Name Validity): The system extracts the tool names from the LLM output and determines whether they exist in the current candidate tool set. If not, it is considered an invalid selection, rejected, and fallback logic is triggered; if it exists, it proceeds to the next step of parameter validation. This step serves as the first line of defense to prevent the model from "illusoryly" identifying non-existent tools.

[0090] Step 5 (Strict Parameter Structure Validation): Obtain the Pydantic Schema corresponding to the tool, and call the `model_validate(args)` method to perform completeness, type, and validity validation on the parameters. Specifically, this includes checking the existence of required fields, verifying field value types, checking numerical range or format constraints (such as positive numbers and valid units), and using the `extra="forbid"` mechanism to intercept any undeclared additional fields. If validation passes, call `model_dump()` to obtain the standardized parameter dictionary; if a `ValidationError` is thrown, it is considered invalid input, and the fallback process begins.

[0091] Step 6 (Execute the tool or enable a fallback strategy after successful verification): For parameters that pass verification, call `tool.invoke(coerced_args)` to execute the tool and record the result. If verification fails, enable the predefined `args_planner` function to generate the minimum feasible parameters (e.g., construct a default `expr` based on the task context), and attempt execution again after a full verification. The fallback strategy ensures that the task is not interrupted by a single failure, while all outputs remain constrained by the schema, ensuring system bottom-line safety.

[0092] In some embodiments of this application, a target tool sequence is determined, wherein the target tool sequence includes all target tools invoked during the execution of the target task; execution feedback information corresponding to each target tool in the target tool sequence is determined; and edge weights in the tool topology graph are updated based on the execution feedback information.

[0093] As an alternative implementation, an online learning feedback mechanism can be used to dynamically adjust the edge weights of the tool graph based on whether the call is successful or not, so that the system can gradually optimize the call path after multiple executions and has adaptive evolution capabilities.

[0094] In some embodiments of this application, the dynamic graph evolution process includes the following steps:

[0095] Step 1 (Record the complete execution path): During task execution, the system maintains an ordered list `path` to record the sequence of tool names called at each step. For example: ["search_docs", "calc", "unit_convert"]. This path is dynamically appended with each tool call, ultimately forming a complete execution trajectory, which serves as the foundational data for subsequent feedback analysis. Path information is stored separately from historical results, supporting independent playback and attribution analysis.

[0096] Step 2 (Constructing the Feedback Score Map): After the task is completed, a tool-level feedback score map (score_map) is generated based on the execution results to quantify the contribution or negative impact of each tool in this task.

[0097] (1) If a tool returns an error field, its score is -2 (strong negative feedback);

[0098] (2) If the task is successful as a whole, the tool score for the last step is increased by 2 (major contributor), and the tool score for the second to last step is increased by 1 (assistant contributor).

[0099] (3) Other tools have a default score of 0.

[0100] This scoring mechanism embodies the principles of "outcome orientation" and "attribution of responsibility" to ensure that feedback signals accurately reflect the value of the tool.

[0101] Step 3 (Torture the path and update edge weights): For each pair of consecutive calls (src → dst) in the execution path, update the edge weights based on the feedback score from the target tool dst. The edge weights are updated using an exponential smoothing formula:

[0102]

[0103] in, ∈(0,1) is the smoothing coefficient, with a recommended value of 0.7~0.8, to control the degree of retention of old knowledge. For nonlinear gain functions:

[0104]

[0105] in, Represents the fraction mapping function, This represents a hyperparameter that adjusts the update speed.

[0106] Step 4 (Persistent Update of Tool Graph Structure): Write the calculated new edge weights into the memory structure of the tool graph, and persistence can be achieved in the following ways:

[0107] (1) Write to a local JSON or YAML configuration file;

[0108] (2) Store in a database table (e.g., the edges table, fields: src_tool, dst_tool, weight);

[0109] (3) Broadcast to other nodes in the cluster via API to achieve multi-instance collaborative evolution.

[0110] It supports a hot update mechanism, which can take effect without restarting the service, ensuring that learning results can be applied immediately.

[0111] In some embodiments of this application, the following are also provided: Figure 4The diagram illustrates the question-and-answer task processing flow. Starting with a request initiated by a "user / engineer," the process begins by "obtaining the API / data source" and then "obtaining the requirement and context." This is followed by the core processing stage, sequentially completing "request parsing," "tool selection (calling downstream capabilities)," "LLM call (corresponding to the LLM interface in the tool call module)," "parameter filling / request encapsulation," and "tool execution." Simultaneously, the outputs of the "weather_api" and "LLM interface" from the top "tool call" module undergo "information completion and result organization" and "result completion / polishing," before converging into the core stage of "result parsing / content generation." Finally, the results are relayed to the "engineer (feedback)" through "result feedback." The process also includes "anomaly detection" and a "retry mechanism" to ensure execution stability. This flow achieves a closed-loop process from requirement access, tool scheduling, data processing to result output, automating requirement processing and feedback through LLM and various tool interfaces.

[0112] In some embodiments of this application, the following are also provided: Figure 5 The task processing flow is shown below. In this flow, the process starts with task reception, first recalling initial candidate tools, then obtaining a successor subset from the tool graph, and subsequently exposing only the candidate subset (bind_tools) to the LLM. Next, it checks if the LLM produces a valid tool call. If yes, parameter validation begins; if successful, the tool is executed; otherwise, a fallback strategy is triggered: heuristic tool selection and parameter construction are performed before execution. After tool execution, the history and state are written back, and the stopping condition is checked again. If not, the loop returns to obtaining a successor subset from the tool graph. If the LLM does not produce a valid tool call, feedback scoring is constructed, and after optimization through online learning (edge ​​weight interpolation), the loop also returns to obtaining a successor subset from the tool graph. When the stopping condition is satisfied, the final answer is generated.

[0113] Optionally, taking the task "Calculate the area of ​​a circle with a radius of 3 and convert it to square centimeters" as an example, the system first receives the natural language task and initializes its state. The candidate recall module, based on semantic matching, initially filters out `calc` (calculation), `unit_convert` (unit conversion), and `search_docs` (document retrieval) as relevant tools. The tool graph constraint module, based on a preset directed weighted relationship (e.g., `calc → unit_convert` with a weight of 0.7), determines that the currently callable successor tool is `calc`, exposing it only to the LLM. The model then selects the `calc` tool accordingly and generates the parameter {"expr": "pi (3 2) After the parameter passed the Pydantic Schema validation, the calculation yielded an intermediate result of 28.27 square meters. This step was recorded, and it was determined that the task was not yet complete (unit conversion was still required), so the next round of inference was initiated. The tool graph again provided the successor node of calc, unit_convert. The LLM selected this tool and generated the parameters {"value": 28.27, "src": "m^2", "dst": "cm^2"}. After the parameters passed the validation, the calculation was executed, returning the result of 282743 square centimeters. It was detected that the numerical calculation and unit conversion had been completed, satisfying the stopping condition, and the final answer "282743 cm²" was output. Subsequently, the online learning feedback module enhanced the edge weight of the successful path calc → unit_convert, increasing its call priority in similar tasks in the future, thus achieving optimization.

[0114] Optionally, in a scenario where the user inputs "Please convert 10 centimeters to meters," the LLM-generated parameters lack the target unit field `dst` during the tool's execution. Upon detecting this missing field, the parameter validation module triggers a heuristic fallback strategy. Combining task semantics and common configurations in the tool graph, it automatically completes and generates the full parameters: `{value: 10, "src": "cm","dst": "m"}`. The tool then executes successfully, completing the unit conversion. This mechanism effectively prevents call failures due to incomplete LLM output, ensuring process continuity and robustness.

[0115] Optionally, the scenario is that the user inputs "Please search for the formula for the area of ​​a circle and calculate the result for a radius of 5". First, the candidate recall module identifies relevant tools {search_docs, calc}. The tool graph constraint module prioritizes exposing the search_docs tool according to a preset path, performing document retrieval to obtain the formula for the area of ​​a circle, πr². Subsequently, the state is updated, and the tool graph, based on the current context, provides calc as a successor node to search_docs to the LLM. The calc tool is then invoked, passing in the expression "pi". (5 2) The area result was successfully calculated.

[0116] In some embodiments of this application, such as Figure 6As shown, a task processing flow based on LangGraph workflow is also provided. In this process, starting with the "user task," the workflow is first triggered by "StartGraph." After entering the LangGraph workflow, a node is selected using "Select_optimal_node" combined with "Score_map," while "check_stop_condition" is executed to determine whether to stop. If not stopped, tools are associated using "bind_tools," and then validated by "Predict_tool." If the validation is successful, "tool execution" is executed; otherwise, "heuristic tool selection" is triggered before the tool is executed. After the tool is executed, "Score_map" is updated, and the process returns to the "select optimal point" loop. When the stopping condition is met, the "final_node" and "Pretty_answer" processes the data before outputting the "final answer." In addition, the workflow also associates with tool components such as search_docs and calc (including identifiers such as wo-6 and wo-7), and supports feedback processing via "ToolGraph.apply_feedback." This process enables end-to-end management of user tasks, from startup, node selection, tool scheduling, cyclic execution to result output, and leverages the LangGraph framework to achieve intelligent processing and iterative optimization of tasks.

[0117] In summary, by determining the tool topology graph corresponding to the tool library, where nodes in the topology graph correspond to tools in the tool library, edges between nodes represent execution call relationships between nodes, and tools are used to execute preset data processing methods; after receiving the task description text of the target task, the system iteratively determines the set of candidate tools corresponding to the target task based on the task description text and the tool topology graph; during the iterative determination of the set of candidate tools corresponding to the target task, after each determination of the set of candidate tools, the system instructs the model to select the target tool from the set of candidate tools to execute the target task, adopting a dynamic generation of candidate subsets and an online learning feedback mechanism, thereby achieving the goal of limiting the range of tool selection and improving the reliability of parameter generation. This achieves the technical effects of reducing token consumption, improving the accuracy of tool selection, and enhancing the robustness and adaptability of the system, thus solving the technical problems of high computing resource consumption, low tool selection accuracy, and unstable parameter generation caused by blindly exposing all tools when facing multi-tool scenarios.

[0118] This application provides a model tool invocation device, such as... Figure 7 As shown, by Figure 7 As can be seen, the device includes: a first processing module 70, used to determine the tool topology graph corresponding to the tool library, wherein the nodes in the tool topology graph correspond to the tools in the tool library, the edges between the nodes are used to represent the execution call relationship between the nodes, and the tools are used to execute preset data processing methods; a second processing module 72, used to receive the task description text of the target task, and iteratively determine the set of candidate tools corresponding to the target task based on the task description text and the tool topology graph; and a third processing module 74, used to instruct the model to select the target tool from the candidate tool set to execute the target task after each determination of the candidate tool set during the iterative determination of the candidate tool set corresponding to the target task.

[0119] In some embodiments of this application, after the first processing module 70 determines the set of target candidate tools corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the target tool selected in each iteration when the iteration termination condition is met and the processing result obtained does not match the task description text; determining the edge to be adjusted in the tool topology graph based on the target tool selected in each iteration, wherein the edge to be adjusted is the edge connecting the node corresponding to the target tool in the tool topology graph; and reducing the edge weight of the edge to be adjusted.

[0120] In some embodiments of this application, the step of the second processing module 72 iteratively determining the candidate tool set corresponding to the target task based on the task description text and the tool topology graph includes: in the first iteration, determining an initial candidate tool set from the tool library based on the semantic information of the task description text; in the iterations that are not the first iteration, determining the target candidate tool set corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, wherein the nodes corresponding to the candidate tools in the target candidate tool set and the nodes corresponding to the target tool are connected by edges in the tool topology graph.

[0121] In some embodiments of this application, after the third processing module 74 determines the target candidate tool set corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the edge weights corresponding to each candidate tool in the target candidate tool set; normalizing the edge weights to obtain the tool weights corresponding to the candidate tools, wherein the tool weights are used to reflect the priority of the candidate tools, and the larger the tool weights, the higher the priority.

[0122] In some embodiments of this application, after the third processing module 74 determines the set of target candidate tools corresponding to the current iteration based on the target tool selected by the model in the previous iteration and the tool topology graph, the method further includes: determining the target tool selected in each iteration when the iteration termination condition is met and the processing result obtained does not match the task description text; determining the edge to be adjusted in the tool topology graph based on the target tool selected in each iteration, wherein the edge to be adjusted is the edge connecting the node corresponding to the target tool in the tool topology graph; and reducing the edge weight of the edge to be adjusted.

[0123] In some embodiments of this application, the step of the third processing module 74 instructing the model to select a target tool from the candidate tool set for performing the target task includes: obtaining a tool invocation instruction generated by the model; determining whether the tool indicated by the tool invocation instruction is a tool in the candidate tool set, and if it is confirmed to be a tool in the candidate tool set, determining that the tool indicated by the tool invocation instruction is the target tool, and verifying the input parameters of the target tool according to the input parameter verification standard corresponding to the target tool.

[0124] In some embodiments of this application, the third processing module 74 determines a target tool sequence, wherein the target tool sequence includes all target tools called during the execution of the target task; determines the execution feedback information corresponding to each target tool in the target tool sequence; and updates the edge weights in the tool topology graph based on the execution feedback information.

[0125] It should be noted that the modules in the above-mentioned model tool calling device can be program modules (e.g., a set of program instructions to implement a certain function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0126] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0127] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0128] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0129] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0130] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0131] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for calling a model tool, characterized in that, include: Determine the tool topology graph corresponding to the tool library, wherein the nodes in the tool topology graph correspond to the tools in the tool library, the edges between the nodes are used to represent the execution call relationship between the nodes, and the tools are used to execute preset data processing methods; After receiving the task description text of the target task, the set of candidate tools corresponding to the target task is determined iteratively based on the task description text and the tool topology graph. During the iterative process of determining the set of candidate tools corresponding to the target task, after each determination of the set of candidate tools, the model is instructed to select a target tool from the set of candidate tools to perform the target task.

2. The model tool invocation method according to claim 1, characterized in that, Based on the task description text and the tool topology graph, the candidate tool set corresponding to the target task is determined iteratively, including: During the first iteration, an initial set of candidate tools is determined from the tool library based on the semantic information of the task description text. In the iteration process that is not the first iteration, the target tool selected by the model in the previous iteration and the tool topology graph are used to determine the target candidate tool set corresponding to the current iteration. The nodes corresponding to the candidate tools in the target candidate tool set and the nodes corresponding to the target tool are connected by edges in the tool topology graph.

3. The model tool invocation method according to claim 2, characterized in that, Based on the target tools selected by the model in the previous iteration and the tool topology graph, after determining the target candidate tool set corresponding to the current iteration, the method further includes: Determine the edge weights corresponding to each candidate tool in the target candidate tool set; The edge weights are normalized to obtain the tool weights corresponding to the candidate tools. The tool weights are used to reflect the priority of the candidate tools. The larger the tool weight, the higher the priority.

4. The model tool invocation method according to claim 2, characterized in that, Based on the target tools selected by the model in the previous iteration and the tool topology graph, after determining the target candidate tool set corresponding to the current iteration, the method further includes: If the iteration termination condition is met and the obtained processing result does not match the task description text, determine the target tool selected in each iteration. Based on the target tool selected in each iteration, an edge to be adjusted is determined in the tool topology graph, wherein the edge to be adjusted is an edge connecting the node corresponding to the target tool in the tool topology graph; Reduce the edge weight of the edge to be adjusted.

5. The model tool invocation method according to claim 1, characterized in that, The method further includes: Determine the input configuration information corresponding to the tools in the tool library, wherein the input configuration information includes the input parameter model class and input indication information corresponding to the tool, and the input indication information is used to indicate the field type that is prohibited from being input to the candidate tool; The input parameter verification standard corresponding to the tool is determined based on the input configuration information, and the input parameter verification standard and the input configuration information are bound together.

6. The model tool invocation method according to claim 5, characterized in that, The indicator model selects target tools from the candidate tool set for performing the target task, including: Obtain the tool invocation instructions generated by the model; Determine whether the tool indicated by the tool invocation instruction is a tool in the candidate tool set, and if it is confirmed to be a tool in the candidate tool set, determine that the tool indicated by the tool invocation instruction is the target tool, and verify the input parameters of the target tool according to the input parameter verification standard corresponding to the target tool.

7. The model tool invocation method according to claim 1, characterized in that, The method further includes: Determine a target tool sequence, wherein the target tool sequence includes all the target tools invoked during the execution of the target task; Determine the execution feedback information corresponding to each target tool in the target tool sequence; Based on the execution feedback information, update the edge weights in the tool's topology graph.

8. A model tool invocation device, characterized in that, include: The first processing module is used to determine the tool topology graph corresponding to the tool library, wherein the nodes in the tool topology graph correspond to the tools in the tool library, the edges between the nodes are used to represent the execution call relationship between the nodes, and the tools are used to execute preset data processing methods; The second processing module is used to receive the task description text of the target task and, based on the task description text and the tool topology graph, iteratively determine the set of candidate tools corresponding to the target task. The third processing module is used to instruct the model to select a target tool from the candidate tool set to perform the target task after each determination of the candidate tool set during the iterative determination of the candidate tool set corresponding to the target task.

9. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a program, wherein when the program is executed, it controls the device where the non-volatile storage medium is located to execute the model tool invocation method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the model tool invocation method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the model tool invocation method according to any one of claims 1 to 7.

Images