Tool graph generation

Abstract

One or more embodiments of the present specification provide a tool graph generation method, an apparatus, a storage medium, and a program product. The method comprises: acquiring a plurality of tools available for invocation by an invoking entity, and perform initialization on the basis of the plurality of tools to obtain an initial tool graph, the initial tool graph comprising vertices for representing the tools and directed edges for representing dependency relationships between any two tools; using the initial tool graph as a tool graph to be optimized in a first round of an iterative process, and repeatedly performing the following iterative process to complete a tool graph optimization task: determining a plurality of tool invocation paths from the tool graph to be optimized, executing the respective tool invocation paths to obtain execution results, and modifying the directed edges in the tool graph to be optimized on the basis of the execution results, so as to obtain a modified tool graph; and, if an iteration termination condition is not satisfied, using the modified tool graph as a tool graph to be optimized in a next round of the iterative process. A target tool graph obtained upon satisfaction of the iteration termination condition is used to provide a reference for the invoking entity when using the tools in combination.

Description

Tool diagram generation Technical Field

[0001] This specification relates to the field of computer software technology, and more particularly to a tool diagram generation method, electronic device, computer-readable storage medium, and program product. Background Technology

[0002] In the context of deepening digital transformation, enterprises and organizations are increasingly relying on automation and intelligent tools to improve operational efficiency and address increasingly complex service demands. These tools refer to algorithms, software applications, models, modules, or databases, each with its own independent function. These tools can perform their respective roles, from data processing and intelligent analysis to decision support, helping users quickly respond to complex problems within vast information systems.

[0003] However, with the increasing variety of tools and their ever-expanding functionality, how to rationally combine and utilize these tools has become a major challenge. When faced with complex tasks, different tools often have multi-layered and multi-dimensional dependencies, and the order of operations and collaboration methods become increasingly complex. Users often find it difficult to intuitively understand these internal relationships, making it difficult to select the most suitable tool combination for the current scenario. This can not only lead to wasted resources but also affect the efficiency of the final decision-making process. Summary of the Invention

[0004] In view of the above, this specification provides a tool diagram generation method, an electronic device, a computer-readable storage medium, and a program product through one or more embodiments.

[0005] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions.

[0006] According to a first aspect of one or more embodiments of this specification, a tool graph generation method is proposed, comprising: acquiring multiple tools for a calling object to invoke, and initializing an initial tool graph based on the multiple tools, the initial tool graph including vertices representing tools and directed edges representing dependencies between any two tools; using the initial tool graph as the tool graph to be optimized in the first iteration process, and iteratively performing the following process to complete the tool graph optimization task: determining multiple tool calling paths from the tool graph to be optimized, executing each of the tool calling paths to obtain execution results, and modifying the directed edges in the tool graph to be optimized based on the execution results to obtain a modified tool graph; if the iteration termination condition is not met, using the modified tool graph as the tool graph to be optimized in the next iteration process; if the iteration termination condition is met, saving the modified tool graph obtained in the last iteration process as a target tool graph, the target tool graph being used to provide a reference for the calling object when combining tools.

[0007] According to a second aspect of the embodiments of this specification, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect.

[0008] According to a third aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the first aspect.

[0009] According to a fourth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0010] The technical solutions provided by the embodiments of this specification can include the following beneficial effects: In the embodiments of this specification, multiple tools for the calling object are obtained. By abstracting the tools as vertices and mapping dependencies as directed edges, a visual initial tool graph is formed, laying a structured foundation for subsequent optimization. Then, based on the initial tool graph, a tool graph optimization task is performed to achieve iterative optimization of the tool graph. In each iteration, multiple tool calling paths can be determined from the tool graph to be optimized. Then, each tool calling path is executed, and the execution results of each tool calling path are collected. Based on the execution results of the tool calling paths, the directed edges (i.e., the dependencies between tools) in the tool graph to be optimized are modified, thereby generating an updated tool graph. This iterative optimization method can continuously correct and improve the dependencies between tools based on actual execution results, ultimately obtaining a more efficient and reasonable tool combination scheme, providing a better decision basis for the calling object. By repeatedly optimizing the tool graph, the final target tool graph can provide the calling object with a more reasonable reference for the tool usage order and dependencies, which helps to improve overall performance and task execution accuracy, avoid redundant operations, and achieve more efficient resource utilization and task completion.

[0011] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0012] Figure 1 is a flowchart of a tool graph generation method provided in an exemplary embodiment.

[0013] Figure 2 is a flowchart of tool graph initialization and optimization provided in an exemplary embodiment.

[0014] Figure 3 is a schematic diagram of tool call path sampling provided in an exemplary embodiment.

[0015] Figure 4 is a schematic diagram of a tool call path execution provided in an exemplary embodiment.

[0016] Figure 5 is a schematic diagram of an exemplary embodiment for evaluating execution results.

[0017] Figure 6 is a schematic diagram of a directed edge weight update provided in an exemplary embodiment.

[0018] Figure 7 is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment. Detailed Implementation

[0019] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0020] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0021] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0022] The tools mentioned in this manual refer to algorithms, software applications, models, modules, or databases, etc., that have independent functions. For example, tools include, but are not limited to, the following.

[0023] ① File upload tool: Allows users to upload local files to a specific storage space, such as a remote server. It supports multiple file formats, implements security verification, and ensures the stability and efficiency of the upload process.

[0024] ② Online search tools: These tools connect to the internet, call search engines or related interfaces, and retrieve and return relevant information in real time. These tools play a crucial role in information retrieval and data collection.

[0025] ③ Database access tools: Specifically designed to connect to and operate various databases, supporting the storage and retrieval of related service data through querying, updating and managing data.

[0026] ④ Calculation tools: Designed for needs such as mathematical operations, statistical analysis, or big data processing, these tools can perform complex calculations and provide accurate results. For example, they can be used in scenarios such as financial statement analysis and scientific computing.

[0027] ⑤ Reasoning tools: These tools rely on pre-defined rules or models to perform logical analysis and judgment on input data, thereby drawing conclusions or making decisions. These tools are widely used in fields such as intelligent decision support and expert systems.

[0028] ⑥ Image processing tools: Used for image editing, filtering, cropping, feature extraction, and recognition. Suitable for image optimization, monitoring systems, and visual recognition scenarios.

[0029] ⑦ Natural Language Processing Tools: Focused on text analysis and processing, such as language translation, sentiment analysis, keyword extraction, automatic summarization, and question answering systems, to help the system better understand and generate natural language content.

[0030] ⑧ Data visualization tools: These tools transform complex data into charts, graphs, or dashboards, allowing users to intuitively discover patterns and trends within the data. They are commonly used in business intelligence and report presentations.

[0031] ⑨ Web crawler tools: Automatedly crawl publicly available data on the Internet, collect and organize information, and provide data support for subsequent data analysis and intelligence gathering.

[0032] ⑩ Log analysis tools: collect and parse system logs, error records, and other information to help developers discover system bottlenecks, causes of failures, and security vulnerabilities, thereby improving system maintenance efficiency.

[0033] Degree tools: used to coordinate and manage the execution order and timing of multiple tasks or services to ensure efficient resource utilization. They are commonly found in distributed systems and large-scale task scheduling.

[0034] Testing tools: Real-time tracking of system status and service indicators, timely detection of anomalies and alarm or automatic handling to ensure stable system operation.

[0035] Full detection tools: Perform vulnerability scanning and security assessments on systems or applications to prevent potential attacks and improve overall security protection capabilities.

[0036] Speech recognition and synthesis tools: These tools enable the conversion of speech to text or the synthesis of speech from text, and are widely used in scenarios such as intelligent assistants, customer service systems, and interactive voice responses.

[0037] Gateway tools: manage and route various service call requests, realize data interaction and unified management between different systems or modules, and optimize the interface call process.

[0038] These tools each perform different tasks and can be flexibly combined according to specific application scenarios to jointly build an efficient, intelligent, and reliable technology ecosystem.

[0039] Based on the problems in related technologies, please refer to Figure 1. This specification provides a tool graph generation method, which can be executed by an electronic device, including but not limited to physical servers, server clusters, cloud servers, smartphones / mobile phones, tablet computers, personal digital assistants (PDAs), laptop computers, and desktop computers. The method includes the following steps.

[0040] In S101, multiple tools for the calling object to invoke are obtained, and an initial tool graph is obtained based on the multiple tools. The initial tool graph includes vertices for representing tools and directed edges for representing the dependency relationship between any two tools.

[0041] In this step, the electronic device is initialized based on multiple tools to obtain an initial tool diagram. This structured representation can intuitively reflect the functions and interrelationships of each tool, laying the foundation for subsequent optimization and automated combination.

[0042] The initial tool graph is a directed graph G = (V, E) containing multiple tools and their relationships. Here, the vertex set (V = {set of tools}) is the set of all tools, with each tool corresponding to a vertex in the graph. The directed edge set (E = {(u, v)}) represents the directed edges between tool u and tool v. In some scenarios, the initial tool graph may also contain other information, such as assigning weights to each directed edge. In this case, the directed edge set (E = {(u, v, w)}) represents the directed edges between tool u and tool v, where the weight w represents the weight of the directed edge, reflecting the degree of dependency between tool u and tool v.

[0043] The invoking object refers to the entity that initiates the tool invocation request. Specifically, the invoking object can be a human user in the traditional sense (such as developers or analysts) or a non-human entity, such as a pre-trained language model or other intelligent agent system. Pre-trained language models, such as Large Language Models (LLMs), are artificial intelligence models based on deep learning techniques, especially trained using large corpora. They aim to understand and generate text similar to human language, possessing powerful natural language understanding and generation capabilities. The goal of pre-trained language models is to achieve various applications through natural language processing capabilities, such as text generation, translation, summarization, question answering, and dialogue systems, thereby helping to improve the efficiency and automation of human-computer interaction. However, they are not limited to this.

[0044] In one possible implementation, as shown in Figure 2, during initialization, the electronic device can construct directed edges from each vertex to other vertices, thus obtaining an initial tool graph, which is a fully connected graph. The fully connected graph ensures that all potential dependencies between tools are considered, preventing the omission of important interactions even in the absence of historical data or prior knowledge. This method is simple to implement, does not rely on additional data input, and facilitates the rapid generation of the initial tool graph, providing a complete set of candidate relationships for subsequent iterative optimization. In subsequent iterations, the electronic device can gradually adjust and filter out truly effective tool dependencies based on actual execution feedback.

[0045] In another possible implementation, the electronic device can acquire at least one of the following: historical call trajectory information of the calling object for the aforementioned multiple tools, reference call trajectory information of the aforementioned multiple tools input by the user, and reference call trajectory information of the aforementioned multiple tools generated by a pre-trained language model. It then establishes directed edges in the initial tool graph based on at least one of the historical call trajectory information and the reference call trajectory information. In this embodiment, by utilizing real historical trajectories and reference information provided by the user / pre-trained model, an initial tool graph that more closely reflects actual usage can be constructed, reducing invalid or redundant edges. Furthermore, the initial tool graph generated based on at least one of the historical call trajectory information and the reference call trajectory information often approaches actual needs more quickly, shortening the subsequent iterative optimization cycle.

[0046] In this embodiment, electronic devices can input the calling parameters, functional descriptions, and return parameters corresponding to multiple tools into a pre-trained language model. The pre-trained language model then understands these parameters to clarify the correlations between the tools, thereby generating reference calling trajectory information for each tool. This embodiment, through semantic analysis of the tool calling parameters, functional descriptions, and return parameters using a pre-trained language model, can capture the correlations between tools, providing a more scientific basis for subsequent iterative optimization.

[0047] In S102, (a) the initial tool graph is used as the tool graph to be optimized in the first round of iteration, and the following iteration process is performed in a loop to complete the tool graph optimization task: (b) multiple tool call paths are determined from the tool graph to be optimized, each tool call path is executed to obtain the execution result, and the directed edges in the tool graph to be optimized are modified based on the execution result to obtain the modified tool graph.

[0048] In this step, during each iteration, multiple tool call paths can be identified from the tool graph to be optimized, thus determining the calling order and combination methods between different tools. Then, each tool call path is executed, and the execution results are collected. Based on these results, the directed edges (i.e., the dependencies between tools) in the tool graph to be optimized are modified (e.g., strengthening or weakening the weight of certain edges, deleting certain edges, etc.), thereby generating an updated tool graph. This iterative optimization method can continuously correct and improve the dependencies between tools based on actual execution results, ultimately obtaining a more efficient and reasonable tool combination scheme, providing a better decision-making basis for the calling objects.

[0049] The following is an example of how to determine multiple tool call paths.

[0050] In one possible implementation, multiple tool call paths can be obtained by traversing each vertex and directed edge in the tool graph to be optimized, based on a preset path length range. The preset path length range refers to the range of the number of tools or directed edges in each tool call path. This method generates all possible tool call paths within the preset path length range by traversing each vertex and directed edge in the tool graph to be optimized, thus ensuring that no potential tool combinations or dependencies are missed. It is suitable for scenarios with a small number of tools and a simple graph structure; the full traversal approach can quickly enumerate all possible call paths, facilitating analysis and comparison.

[0051] For example, suppose there is a tool graph to be optimized containing 5 vertices, and the preset path length range specifies that the number of directed edges in the tool call path is between 1 and 10. If a traversal method is used, considering all values ​​in the path length range, then for each vertex, the directed edges connected to it can be traversed sequentially. Theoretically, 50 tool call paths can be determined. This method can completely capture all potential combinations between tools when the number of tools in the graph is small.

[0052] In another possible implementation, when the number of tools is large and the graph structure is complex, multiple tool call paths can be sampled from the tool graph to be optimized to improve optimization efficiency. The electronic device can determine at least one starting tool from among multiple tools, and then, based on the at least one starting tool and a preset path length range, sample multiple tool call paths from the tool graph to be optimized. By sampling a portion of the paths in the graph, the electronic device can quickly obtain sufficient feedback information for optimization without processing all possible paths, saving time and reducing resource consumption.

[0053] Referring to Figures 2 and 3, assume the electronic device selects the purple tool in the graph as the starting tool, and the preset path length range specifies that the number of directed edges in the tool call path is between 1 and 10. Starting from this starting tool, the electronic device considers all values ​​within the path length range. Based on the vertex connectivity in the graph to be optimized and the preset path length range, 10 tool call paths can be sampled. These sampled tool call paths represent the main calling strategies that the starting tool might adopt, thus providing effective guidance for subsequent tool graph optimization while avoiding the high computational burden of full graph traversal.

[0054] It is understood that this embodiment does not impose any restrictions on the selection of the starting tool, and can be specifically selected according to the actual application scenario. For example, the starting tool can be user-specified, or the starting tool can be a tool with a historical call count higher than a preset number, thereby enabling the sampling of representative tool call paths from the tool graph to be optimized.

[0055] For example, after determining multiple tool call paths, the electronic device can call each tool in the tool call path according to the following rules until the tool call path is completed or a tool call fails in the tool call path: (1) If the starting tool in the tool call path requires call parameters, the starting tool in the tool call path is called using the preset call parameter value of the starting tool. For example, in order to ensure that each tool call path can be started accurately, for the starting tool that requires call parameters, the call parameter value of the starting tool can be preset. The call parameter value can be input by the user, or it can be automatically generated by the automatic generation tool based on the format of the call parameter of the starting tool. This embodiment does not impose any restrictions on this. (2) If the starting tool in the tool call path does not require call parameters, the starting tool in the tool call path is called directly. (3) If the subsequent tools in the tool call path other than the starting tool require call parameters, the call parameter value is generated based on the return result of the preceding tool of the subsequent tool and the subsequent tool is called accordingly. (4) If the subsequent tools in the tool call path other than the starting tool do not require call parameters, the subsequent tools are called directly.

[0056] Through the above execution process, the dependencies between tools can be effectively verified. For example, if the execution of a tool depends on the return result of a preceding tool, then the calling parameter values ​​of that tool must be generated based on the return result of the preceding tool, which clarifies the data dependency between the two tools. Furthermore, by using directed edges to represent the calling order between tools, during execution, tool calls always proceed along the direction of the tool calling path, and there will be no reverse tool calls, thus ensuring the directionality of tool dependencies.

[0057] After each tool call path is completed, the electronic device can collect the execution results of each tool call path. For example, please refer to Figures 2 and 4, which show the execution status between each node in each tool call path: in path 1, the green tool call is successful; in path 10, the yellow tool call is successful and the pink tool call fails.

[0058] For example, the execution result of a tool call path includes at least one of the following: the call parameters, execution status, and return result of each tool in the tool call path.

[0059] By collecting the call parameters of each tool in the tool call path, it is easier to analyze whether the call meets expectations. Moreover, the call parameters of some tools need to be calculated based on the return results of the preceding tools, so recording these call parameters can check whether the parameter generation logic is correct. If some tool calls fail, the problem can also be found by analyzing these call parameters, such as whether the file path is valid or whether the storage format matches the database requirements.

[0060] The execution status of each tool includes whether the call was successful, failed, or encountered an exception, which can intuitively reflect the result of the tool's call.

[0061] The results returned by each tool can be used to verify the effectiveness of the tool. For example, the results returned by some tools will be used as input for subsequent tools, so these results need to be recorded to ensure that the data flow is transmitted correctly. Or, if the returned results do not meet expectations (such as incorrect format or missing data), the implementation of the tool can be checked based on the returned results.

[0062] In one possible implementation, after obtaining the execution results of each tool call path, the electronic device can directly modify the directed edges in the tool graph to be optimized based on these results. For example, if the electronic device pre-stores a mapping relationship between different execution results and modification methods, it can directly determine the modification method for the directed edges in the tool graph to be optimized based on the execution results of each tool call path and this mapping relationship, and then modify accordingly. The pre-defined mapping relationship eliminates the need for manual intervention during the modification process, automatically identifying and applying suitable modification methods, reducing the risk of human error, and thus achieving automated, accurate, and efficient optimization.

[0063] For example, the table below shows the mapping relationship between two different execution results and modification methods:

[0064] In another possible implementation, after obtaining the execution results of each tool call path, the electronic device can evaluate the dependencies between each tool in each tool call path and its preceding tool based on the execution results, thus obtaining the evaluation results of each tool call path. Then, based on the evaluation results corresponding to multiple tool call paths, the directed edges in the tool graph to be optimized are modified to obtain the modified tool graph. This embodiment, by evaluating the execution results of each tool call path, can automatically analyze the dependencies between tools and modify the directed edges in the tool graph in real time accordingly, so that the tool graph always reflects the latest actual dependency state. Furthermore, through automated evaluation, subjective bias and errors caused by manual analysis can be reduced, improving the consistency and objectivity of the overall evaluation and making the optimization process of the tool graph more reliable.

[0065] For example, the evaluation results of each tool call path include at least one of the following: parameter dependencies between each non-starting tool and its preceding tool, the execution status of each non-starting tool, and the correlation between each non-starting tool and its preceding tool. Here, a non-starting tool refers to any tool in the tool call path other than the starting tool.

[0066] The parameter dependencies between each non-starting tool and its preceding tools are used to evaluate whether the calling parameters of the non-starting tool truly depend on the return results of the preceding tools. This reflects the tightness of the dependency relationship; a strong dependency indicates that the output of the preceding tool is crucial to the current tool, while a weak dependency may indicate redundant or unnecessary dependencies.

[0067] The execution status logs for each non-initial tool record the tool's operation during the invocation process, including success, failure, or exceptions. By monitoring the execution status, problems that occur during the invocation process can be identified and located in a timely manner, facilitating subsequent adjustments to the tool invocation order or replacement of unstable tools, thereby improving the overall execution success rate.

[0068] The correlation between each non-starting tool and its predecessor is used to evaluate the logical and data matching between the output of the predecessor and the input of the current tool. High correlation indicates that the data flow or logical flow between tools is well connected, while low correlation suggests possible problems such as interface mismatch or incorrect data format, thus guiding electronic devices to adjust and optimize dependencies.

[0069] For example, to improve evaluation efficiency, the electronic device can generate evaluation prompts based on the execution results of each tool call path and input these prompts into a pre-trained language model. The pre-trained language model then evaluates the dependencies between each tool in each tool call path and its preceding tool, obtaining the evaluation results for each tool call path. In this embodiment, evaluation is performed using a pre-trained language model (such as a large language model). The pre-trained language model has powerful semantic understanding capabilities and can analyze the complex relationships between call parameters, execution states, and return results, thereby more accurately determining the strength of dependencies and the degree of matching between tools.

[0070] In one example, please refer to Figures 2 and 5, which illustrate the evaluation prompts input into the pre-trained language model and the evaluation results output by the pre-trained language model. It is understood that various tool call paths can be input into the pre-trained language model in a format that the pre-trained language model can accept; this embodiment does not impose any restrictions on this.

[0071] Of course, in addition to using pre-trained language models for evaluation, other automated evaluation methods can also be employed, and this embodiment does not impose any restrictions on this. For example, a series of rules and heuristic strategies based on execution results can be predefined to directly evaluate the dependencies between tools.

[0072] The following is an illustrative example of the process of modifying directed edges in the tool graph to be optimized.

[0073] In one possible implementation, after obtaining the evaluation results corresponding to multiple tool call paths, the electronic device can directly determine the outcome based on these results. If the evaluation results indicate that the dependency reflected by a directed edge does not meet expectations (e.g., parameter dependency, execution failure), the electronic device directly decides to delete the directed edge. In this embodiment, only a binary judgment (delete or retain) is needed based on the evaluation results. The implementation process is simple and direct, suitable for scenarios where the evaluation results are clear and a rapid response is required, and can quickly eliminate invalid or inefficient dependencies.

[0074] In another possible implementation, all directed edges in the initial tool graph are assigned the same weight, and the weight of the directed edge between any two tools is used to represent the degree of dependency between them. After obtaining the evaluation results corresponding to multiple tool call paths, the electronic device can modify the weights of the directed edges in the tool graph to be optimized based on these results, and delete directed edges with weights below a preset threshold, thus obtaining the modified tool graph. This embodiment, by assigning quantified weights to dependencies, can more precisely describe the strength of dependencies between tools, thereby retaining edges that, although weakly dependent, may still play a role, providing a reference for further optimization. The preset threshold can be specifically set according to the actual application scenario.

[0075] For example, the evaluation results of each tool call path include the evaluation content of each non-starting tool in the tool call path. The evaluation content includes at least one of the following: parameter dependency between each non-starting tool and the preceding tool, execution status of each non-starting tool, and correlation between each non-starting tool and the preceding tool. The electronic device can then modify the weights of the directed edges between the non-starting tool and the preceding tool in the tool graph to be optimized based on the evaluation content of each non-starting tool. The modified weights can accurately reflect the strength of the dependency relationship between the non-starting tool and the preceding tool, making the tool graph more consistent with the actual call situation. High-weight dependency edges indicate key tool combination relationships, which will help retain and strengthen effective call paths in subsequent iterations. Low-weight edges may be deleted, thereby removing redundant or unstable dependencies. Ultimately, only efficient and stable dependencies are retained, achieving refined optimization of the tool graph and providing a more accurate and effective tool combination guide for the calling object (such as a user or a large language model).

[0076] Please refer to Figures 2 and 6 for a schematic diagram of weight updates for each directed edge.

[0077] The parameter dependencies between various non-starting tools and preceding tools are illustrated as an example: the modified weights of the directed edges between each non-starting tool and its preceding tool are positively correlated with the parameter dependencies. That is, high parameter dependencies mean that if the output of the preceding tool changes, the behavior of subsequent tools will be significantly affected; therefore, this dependency should be strengthened, and the electronic device will increase the weight of the directed edge. Conversely, low parameter dependencies indicate that subsequent tools may not fully depend on the output of the preceding tool, thus the importance of this dependency is lower, and the electronic device will decrease the weight of the directed edge. Referring to Figure 6, in path 1, the green tool does not depend on the output of the purple tool; for example, the green tool can be called directly without parameters, so the weight of the directed edge between them is reduced. In path 10, the yellow tool depends on the output of the purple tool, so the weight of the directed edge between them is increased.

[0078] The execution states of various non-starting tools are used as an example to illustrate this. The modified weights of the directed edges between each non-starting tool and its preceding tool are positively correlated with the execution state. When the execution state of a non-starting tool is successful, it indicates that the preceding tool has provided valid and correct input for the subsequent tool, making the entire call flow smooth, and the weight of the corresponding directed edge will be increased. If the execution state fails or is abnormal, it indicates that the output of the preceding tool is insufficient to support the normal operation of the subsequent tool, or that there is a problem with the dependency relationship, and the weight of the directed edge will be decreased. As shown in Figure 6, in path 10, the pink tool call fails, so the weight of the directed edge between the yellow tool and the pink tool is decreased.

[0079] The correlation between each non-starting tool and its preceding tools is used as an example to illustrate this. The modified weights of the directed edges between each non-starting tool and its preceding tools are positively correlated with the correlation. When the correlation is high, it indicates that the output of the preceding tool and the input of the subsequent tool are highly matched in terms of data format, semantics, or logic, supporting the normal operation of the subsequent tool, and the weight of the corresponding directed edge will be increased. When the correlation is low, it indicates that the data format of the non-starting tool and the preceding tool are incompatible or the logic is disconnected, and the weight of the directed edge will be reduced.

[0080] Those skilled in the art will understand that when modifying directed edge weights, one can refer to only one of the above evaluation metrics, or one can consider two or more evaluation metrics for adjustment. This embodiment does not impose any limitations in this regard.

[0081] For example, before modifying the weights of the directed edges in the tool graph to be optimized, reference tool call paths can be selected from multiple tool call paths based on the evaluation results corresponding to each path. For instance, call paths exhibiting significant anomalies or inefficiencies in one or more evaluation metrics can be eliminated. Finally, the evaluation results of the reference tool call paths are used to modify the weights of the directed edges in the tool graph to be optimized. The selected reference tool call paths will have more representative and reliable evaluation results, facilitating subsequent reasonable modifications to the directed edge weights in the tool graph to be optimized, thereby enabling the tool graph to more accurately reflect the dependencies between actual tools.

[0082] In S103, determine whether the iteration termination condition is met.

[0083] After each iteration, the electronic device checks whether the current tool graph meets the preset termination conditions. This judgment can avoid over-iteration and ensure that the optimization process is terminated in time after reaching the ideal state, thereby improving efficiency and saving computing resources.

[0084] For example, the iteration termination condition includes at least one of the following.

[0085] (1) The modified tool graph obtained in the current iteration is the same as the modified tool graph obtained in at least one previous iteration; it is suitable for scenarios where the problem is relatively simple, the tool dependency is relatively clear, or the optimization space is limited, and it can converge quickly and ensure stable results.

[0086] (2) The difference between the modified tool graph obtained in the current iteration and the modified tool graph obtained in at least one previous iteration is less than the preset difference; this is suitable for problems that are relatively complex, where the tool combination has a certain degree of dynamism, and allows for convergence judgment within a certain tolerance range, ensuring convergence accuracy while avoiding infinite iteration due to small fluctuations. By setting a preset difference (tolerance value) to determine convergence, the trend of overall structural stability can be captured, while balancing the consumption of computational resources.

[0087] (3) The current iteration count has reached the maximum iteration count; as a protection mechanism, it prevents the iteration process from being extended indefinitely when convergence cannot be clearly achieved or the iteration change range has not reached the preset tolerance.

[0088] In S104, if the iteration termination condition is not met, the modified tool graph will be used as the tool graph to be optimized in the next iteration.

[0089] In this step, if the check finds that the iteration termination condition has not yet been met, the electronic device uses the updated tool graph as the basis for the next iteration, repeating the process of determining the call path, execution, and graph structure modification in step S102. Continuous iteration allows the electronic device to constantly absorb execution feedback and gradually improve the call relationships between tools. This adaptive adjustment ensures that the final output tool graph can better adapt to the needs of complex tasks, providing accurate and flexible tool combination suggestions regardless of how the needs of the calling objects change.

[0090] In S105, if the iteration termination condition is met, the modified tool graph obtained in the last iteration is saved as the target tool graph. The target tool graph is used to provide a reference for the calling object when combining tools.

[0091] In this step, once the iteration termination condition is met, the electronic device saves the modified tool graph obtained from the last iteration as the target tool graph. This graph, as the final result, provides an intuitive and reliable reference for the calling objects when combining tools in actual tasks. The saved target tool graph can directly guide the calling objects (users or large language models) to select better tool combinations, thereby reducing operational complexity, minimizing error risks, and improving overall execution efficiency and automation levels. When facing complex tasks, these calling objects obtain the calling order and dependencies between tools through the tool graph, thus helping them to more efficiently combine and use various tools, achieving automated and intelligent operation and decision-making.

[0092] In some embodiments, if a new tool is detected, new vertices indicating the new tool are added to the target tool graph, and directed edges are established between the new vertex and all vertices in the target tool graph. These directed edges initially represent the possible dependencies between the new tool and existing tools, forming a tool graph to be optimized. Then, the tool graph optimization task described above is re-executed using this tool graph. By evaluating the execution results of each tool call path, the dependencies between the new tool and other tools are dynamically adjusted, thereby generating a new target tool graph containing the new tool. In this embodiment, the new tool is quickly integrated into the tool graph by automatically adding new vertices and establishing fully connected directed edges, without manual intervention. This supports dynamic expansion and continuous updates of the system. By re-executing the optimization task, the entire tool graph can automatically adjust, re-evaluate and optimize the dependencies between the old and new tools, ensuring that the new tool can work collaboratively with existing tools and improving the overall flexibility of task execution. This mechanism ensures continuous learning and improvement, driving continuous optimization of service processes by constantly re-evaluating and optimizing the tool combination, and enabling rapid response to new demands and technological advancements.

[0093] In some embodiments, electronic devices may monitor the execution status of each tool during the tool invocation process, such as the success rate of invocation, the correctness of the returned results, and the response time. If the execution status of a tool does not meet expectations, the tool will be judged as a "failed tool". In other words, a failed tool refers to a tool that fails to achieve the expected effect during the actual invocation process, including but not limited to the following situations: (1) Execution failure: the tool frequently returns errors, abnormal information or timeouts during invocation and cannot complete the task normally. (2) Abnormal return results: the output results of the tool do not conform to the preset standard or expected format, causing subsequent tools to be unable to parse or process correctly. (3) Low stability: the tool exhibits inconsistency, such as large fluctuations in the results of multiple invocations under the same conditions or occasional success and occasional failure. (4) Poor response performance: the tool has a long delay during execution, which seriously affects the overall process efficiency.

[0094] If multiple tools are found to contain the aforementioned failed tools, the electronic device can use the target tool graph as the tool graph to be optimized. This ensures that the new optimization process is based on an existing, better structure. Adjustments only need to be made to address the impact of the failed tools, and the tool graph optimization task is re-executed. For example, the tool graph can be modified based on the evaluation results of the failed tools, such as deleting failed tool nodes or weakening or deleting directed edges related to them. Afterward, the electronic device will recalculate and optimize the dependencies between tools, generating an updated target tool graph, ensuring a more stable and efficient tool combination system. This embodiment removes or weakens the dependencies of failed tools, preventing them from affecting the entire tool invocation process, reducing error rates and failure risks. The re-optimized tool graph will only contain well-performing and stable tools, ensuring more reasonable and efficient dependencies between tools, thereby improving the success rate of task execution. The automated re-optimization mechanism allows the electronic device to continuously absorb execution feedback, continuously improve the tool graph structure, and reduce the complexity of subsequent maintenance and upgrades.

[0095] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0096] In some embodiments, this specification also provides an electronic device, including: a processor; and a memory for storing processor-executable instructions; wherein the processor implements the method described in any one of the above embodiments by executing the executable instructions.

[0097] Figure 7 is a schematic structural diagram of a device provided in an exemplary embodiment. Referring to Figure 7, at the hardware level, the device includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile memory 710, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 702 reads the corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0098] In some embodiments, the tool diagram generation apparatus can be applied to the device shown in FIG7 to implement the technical solution of this specification. The tool diagram generation apparatus may include the following modules.

[0099] An initialization module is used to obtain multiple tools for the calling object to invoke, and to initialize an initial tool graph based on the multiple tools. The initial tool graph includes vertices for representing tools and directed edges for representing the dependencies between any two tools.

[0100] The tool graph optimization module is used to take the initial tool graph as the tool graph to be optimized in the first round of iteration and perform the following iterative process to complete the tool graph optimization task: determine multiple tool call paths from the tool graph to be optimized, execute each tool call path to obtain the execution result, and modify the directed edges in the tool graph to be optimized based on the execution result to obtain the modified tool graph.

[0101] The tool graph optimization module is also used to use the modified tool graph as the tool graph to be optimized in the next iteration process if the iteration termination condition is not met.

[0102] The tool graph optimization module is also used to save the modified tool graph obtained in the last iteration as the target tool graph when the iteration termination condition is met. The target tool graph is used to provide a reference for the calling object when combining tools.

[0103] For example, the tool graph optimization module is specifically used to call each tool in the tool call path according to the following rules until the tool call path is completed or a tool call fails: If the starting tool in the tool call path requires call parameters, then the starting tool in the tool call path is called using the preset call parameter value of the starting tool; if the starting tool in the tool call path does not require call parameters, then the starting tool in the tool call path is called directly; if subsequent tools in the tool call path other than the starting tool require call parameters, then call parameter values ​​are generated based on the return results of the preceding tools of the subsequent tools and used to call the subsequent tools; if subsequent tools in the tool call path other than the starting tool do not require call parameters, then the subsequent tools are called directly.

[0104] For example, the tool graph optimization module is specifically used to evaluate the dependency relationship between each non-starting tool and its predecessor tool in each tool call path based on the execution result of each tool call path, and obtain the evaluation result of each tool call path; based on the evaluation results corresponding to the multiple tool call paths respectively, the directed edges in the tool graph to be optimized are modified to obtain the modified tool graph.

[0105] For example, the tool graph optimization module is specifically used to generate evaluation prompts based on the execution results of each of the tool call paths, and input the evaluation prompts into a pre-trained language model so that the pre-trained language model can evaluate the dependencies between each non-starting tool and its preceding tool in each of the tool call paths, and obtain the evaluation results of each of the tool call paths.

[0106] For example, the execution result of the tool call path includes at least one of the following: the call parameters, execution status, and return result of each tool in the tool call path.

[0107] For example, the evaluation results of each of the tool call paths include at least one of the following: parameter dependencies between each non-starting tool and its preceding tool, execution status of each non-starting tool, and correlation between each non-starting tool and its preceding tool.

[0108] For example, all directed edges in the initial tool graph are set with the same weight, and the weight of the directed edge between any two tools is used to represent the degree of dependence between them; the tool graph optimization module is specifically used to modify the weight of the directed edges in the tool graph to be optimized based on the evaluation results corresponding to the multiple tool call paths, and delete the directed edges whose modified weights are lower than a preset threshold, so as to obtain the modified tool graph.

[0109] For example, the evaluation results of each tool call path include the parameter dependencies between each non-starting tool and its preceding tool, and the modified weights of the directed edges between each non-starting tool and its preceding tool are positively correlated with the parameter dependencies.

[0110] For example, the evaluation results of each tool call path include the execution status of each non-starting tool, and the modified weights of the directed edges between each non-starting tool and the preceding tool are positively correlated with the execution status.

[0111] For example, the evaluation results of each tool call path include the correlation between each non-starting tool and the preceding tool, and the modified weights of the directed edges between each non-starting tool and the preceding tool are positively correlated with the correlation.

[0112] For example, the initial tool graph includes a fully connected graph; or, the directed edges in the initial tool graph are determined based on the historical call trajectories of the calling object for the multiple tools and / or pre-generated reference call trajectories for the multiple tools; wherein, the reference call trajectories are generated by a pre-trained language model based on the call parameters, functional description information and return parameters corresponding to the multiple tools respectively.

[0113] For example, the tool graph optimization module is specifically used to determine at least one starting tool from the plurality of tools; and to sample the plurality of tool call paths from the tool graph to be optimized based on the at least one starting tool and a preset path length range.

[0114] For example, the calling object includes a pre-trained language model.

[0115] For example, the iteration termination condition includes at least one of the following: the modified tool graph obtained in the current iteration is the same as the modified tool graph obtained in at least one previous iteration; the difference between the modified tool graph obtained in the current iteration and the modified tool graph obtained in at least one previous iteration is less than a preset difference; and the current iteration number reaches the maximum iteration number.

[0116] For example, the tool graph optimization module is further configured to, if a new tool is detected, add a new vertex indicating the new tool to the target tool graph, and establish directed edges between the new vertex and all vertices in the target tool graph to obtain a tool graph to be optimized; and re-execute the tool graph optimization task using the tool graph to be optimized to obtain a new target tool graph.

[0117] For example, the tool graph optimization module is further configured to, if a failed tool is detected among the plurality of tools, use the target tool graph as the tool graph to be optimized, and re-execute the tool graph optimization task to obtain a new target tool graph.

[0118] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0119] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0120] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0121] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0122] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0123] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for generating tool diagrams, comprising: Obtain multiple tools for the calling object to invoke, and initialize an initial tool graph based on the multiple tools. The initial tool graph includes vertices for representing tools and directed edges for representing the dependencies between any two tools. The initial tool graph is used as the tool graph to be optimized in the first iteration process. The following iterative process is performed to complete the tool graph optimization task: multiple tool call paths are determined from the tool graph to be optimized, each tool call path is executed to obtain the execution result, and the directed edges in the tool graph to be optimized are modified based on the execution result to obtain the modified tool graph. If the iteration termination condition is not met, the modified tool graph will be used as the tool graph to be optimized in the next iteration process; If the iteration termination condition is met, the modified tool graph obtained in the last iteration is saved as the target tool graph, which is used to provide a reference for the calling object when combining tools.

2. The method according to claim 1, wherein executing each of the tool call paths comprises: The tools in the tool call path are invoked according to the following rules until the tool call path is completed or a tool call fails: If the starting tool in the tool call path requires call parameters, then the starting tool in the tool call path is called using the preset call parameter values ​​of the starting tool; If the starting tool in the tool call path does not require any call parameters, then the starting tool in the tool call path is called directly; If subsequent tools in the tool call path, other than the starting tool, require call parameters, then call parameter values ​​are generated based on the return results of the preceding tools of the subsequent tools, and the subsequent tools are called accordingly. If any subsequent tools in the tool call path, other than the starting tool, do not require call parameters, then the subsequent tools are called directly.

3. The method according to claim 1, wherein modifying the directed edges in the tool graph to be optimized based on the execution result to obtain the modified tool graph includes: Based on the execution results of each tool call path, the dependencies between each non-starting tool and its preceding tool in each tool call path are evaluated to obtain the evaluation results of each tool call path; Based on the evaluation results corresponding to the multiple tool call paths, the directed edges in the tool graph to be optimized are modified to obtain the modified tool graph.

4. The method according to claim 3, wherein evaluating the dependency relationship between each non-starting tool and the preceding tool in each tool call path based on the execution result of each tool call path, and obtaining the evaluation result of each tool call path, includes: Based on the execution results of each tool call path, evaluation prompts are generated and input into a pre-trained language model. The pre-trained language model then evaluates the dependencies between each non-starting tool and its preceding tool in each tool call path, thereby obtaining the evaluation results of each tool call path.

5. The method according to claim 3, wherein the execution result of the tool call path includes at least one of the following: the call parameters, execution status, and return result of each tool in the tool call path; And / or, the evaluation results of each of the tool call paths include at least one of the following: parameter dependencies between each non-starting tool and its preceding tool, execution status of each non-starting tool, and correlation between each non-starting tool and its preceding tool.

6. The method according to any one of claims 3 to 5, wherein all directed edges in the initial tool graph are assigned the same weight, and the weight of the directed edge between any two tools is used to represent the degree of dependency between them; Based on the evaluation results corresponding to the multiple tool call paths, the directed edges in the tool graph to be optimized are modified to obtain the modified tool graph, including: Based on the evaluation results corresponding to the multiple tool call paths, the weights of the directed edges in the tool graph to be optimized are modified, and directed edges with weights lower than a preset threshold are deleted to obtain the modified tool graph.

7. The method according to claim 6, wherein the evaluation results of each tool call path include the parameter dependency between each non-starting tool and the preceding tool, and the modified weight of the directed edge between each non-starting tool and the preceding tool is positively correlated with the parameter dependency; And / or, the evaluation results of each of the tool call paths include the execution status of each non-starting tool, and the modified weights of the directed edges between each non-starting tool and the preceding tool are positively correlated with the execution status; And / or, the evaluation results of each of the tool call paths include the correlation between each non-starting tool and the preceding tool, and the modified weights of the directed edges between each non-starting tool and the preceding tool are positively correlated with the correlation.

8. The method according to claim 1, wherein the initial tool graph comprises a fully connected graph; Alternatively, the directed edges in the initial tool graph are determined based on the historical call trajectories of the calling object for the multiple tools and / or pre-generated reference call trajectories for the multiple tools; wherein, The reference call trajectory is generated by the pre-trained language model based on the call parameters, function description information and return parameters corresponding to the multiple tools respectively.

9. The method according to claim 1, wherein determining multiple tool call paths from the tool graph to be optimized includes: Determine at least one starting tool from the plurality of tools; Based on the at least one starting tool and the preset path length range, the multiple tool call paths are sampled from the tool graph to be optimized.

10. The method according to claim 1, wherein the calling object includes a pre-trained language model; And / or, The iteration termination condition includes at least one of the following: the modified tool graph obtained in the current iteration is the same as the modified tool graph obtained in at least one previous iteration; the difference between the modified tool graph obtained in the current iteration and the modified tool graph obtained in at least one previous iteration is less than a preset difference; and the current iteration number reaches the maximum iteration number.

11. The method according to claim 1, further comprising: If a new tool is detected, a new vertex used to indicate the new tool is added to the target tool graph, and directed edges are established between the new vertex and all vertices in the target tool graph to obtain the tool graph to be optimized. The tool graph optimization task is re-executed using the tool graph to be optimized to obtain a new target tool graph.

12. The method according to claim 1, further comprising: If a failed tool is detected among the multiple tools, the target tool graph is used as the tool graph to be optimized, and the tool graph optimization task is re-executed to obtain a new target tool graph.

13. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1 to 12 by executing the executable instructions.

14. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 12.

15. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1 to 12.

Images