Tool drawing generation method and device, storage medium and program product

Abstract

One or more embodiments of the invention provide a tool drawing generation method and device, a storage medium and a program product. The method comprises the steps that a plurality of tools called by a calling object are obtained, an initial tool diagram is obtained based on initialization of the tools, and the initial tool diagram comprises vertexes used for representing the tools and directed edges used for representing the dependency relationship between any two tools; taking the initial tool diagram as a to-be-optimized tool diagram in the first round of iteration process, and circularly performing the following iteration process to complete a tool diagram optimization task: determining a plurality of tool calling paths from the to-be-optimized tool diagram, executing each tool calling path to obtain an execution result, and modifying directed edges in the to-be-optimized tool diagram based on the execution result to obtain a to-be-optimized tool diagram; obtaining a modified tool drawing; and if the iteration ending condition is not met, taking the modified tool diagram as a to-be-optimized tool diagram in the next round of iteration process. The target tool diagram meeting the iteration ending condition is used for providing reference for the calling object when the tools are used in a combined mode.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of computer software technology, and in particular, to a method for generating a tool graph, an electronic device, a computer-readable storage medium, and a program product. Background Art

[0002] In the context of the continuous deepening of the current digital transformation, enterprises and various organizations are increasingly relying on automated and intelligent tools to improve operational efficiency and respond to increasingly complex service demands. A so-called tool refers to an algorithm, software application, model, module, database, etc. that has an independent function. These tools can each perform their own functions, from data processing, intelligent analysis to decision support, helping users quickly respond to complex problems in a huge information system.

[0003] However, with the increasing variety of tools and the continuous expansion of their functions, how to reasonably combine and call these tools has become a major challenge. In the face of complex tasks, there are often multi-level and multi-dimensional dependency relationships between different tools, and the operation sequence and collaboration method have become more complex. Callers often find it difficult to intuitively understand these internal associations, so it is difficult to select the most suitable tool combination for the current scenario, which may not only lead to waste of resources, but also affect the final decision-making efficiency. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a method for generating a tool graph, an electronic device, a computer-readable storage medium, and a program product.

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

[0006] According to the first aspect of one or more embodiments of this specification, a method for generating a tool graph is proposed, including:

[0007] Obtain a plurality of tools for a calling object to call, and initialize an initial tool graph based on the plurality of tools. The initial tool graph includes vertices for representing tools and directed edges for representing the dependency relationships between any two tools;

[0008] Use the initial tool graph as the tool graph to be optimized in the first round of iteration process, and perform the following iterative process in a loop to complete the tool graph optimization task: Determine multiple tool call paths from the tool graph to be optimized, execute each of the tool call paths to obtain an execution result, and modify the directed edges in the tool graph to be optimized based on the execution result to obtain a modified tool graph;

[0009] In the case that the iteration end condition is not satisfied, use the modified tool graph as the tool graph to be optimized in the next round of iteration process;

[0010] When the iteration end condition is satisfied, save the modified tool graph obtained in the last round of iteration process as the target tool graph, and the target tool graph is used to provide a reference for the calling object when using tools in combination.

[0011] According to the second aspect of the embodiments of the present specification, there is provided an electronic device, including:

[0012] A processor;

[0013] A memory for storing executable instructions of the processor;

[0014] Wherein, when the processor executes the executable instructions, it is used to implement the method described in the first aspect.

[0015] According to the third aspect of the embodiments of the present specification, there is provided a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, it implements the steps of the method described in the first aspect.

[0016] According to the fourth aspect of the embodiments of the present specification, there is provided a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the steps of the method described in the first aspect.

[0017] The technical solutions provided by the embodiments of the present specification may include the following beneficial effects:

[0018] In the embodiments of the present specification, multiple tools for a calling object to call are obtained. By abstracting the tools as vertices and mapping the dependency relationships 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 round of iteration process, multiple tool call paths can be determined from the tool graph to be optimized, and then each tool call path is executed, and the execution results of each tool call path are collected. According to the execution results of the tool call paths, the directed edges (i.e., the dependency relationships 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 dependency relationships between tools based on the actual execution results, and finally obtain a more efficient and reasonable tool combination scheme, providing a better decision-making basis for the calling object. By repeatedly optimizing the tool graph, the finally obtained target tool graph can provide a reference for the calling object on a more reasonable tool usage order and dependency relationship, which helps to improve the overall performance and the accuracy of task execution, avoid redundant operations, and achieve more efficient resource utilization and task completion.

[0019] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present specification. Description of the Drawings

[0020] Figure 1 is a flowchart of a method for generating a tool diagram provided by an exemplary embodiment.

[0021] Figure 2 is a flowchart of initialization and optimization of a tool diagram provided by an exemplary embodiment.

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

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

[0024] Figure 5 is a schematic diagram of evaluating an execution result provided by an exemplary embodiment.

[0025] Figure 6 is a schematic diagram of updating the weight of a directed edge provided by an exemplary embodiment.

[0026] Figure 7 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment. Detailed implementation manners

[0027] Here, the exemplary embodiments will be described in detail, and the examples are shown in the drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all the implementation manners consistent with one or more embodiments of this specification. On the contrary, they are only examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0028] It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily executed in the order shown and described in this specification. In some other embodiments, the steps included in the method may be more or less than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step for description in other embodiments.

[0029] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this specification are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or reject.

[0030] The tools mentioned in this specification refer to algorithms, software applications, models, modules, or databases, etc. with independent functions. For example, the tools include but are not limited to:

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

[0032] ② Internet search tool: Can connect to the Internet, call search engines or relevant interfaces, and retrieve and return relevant information in real time. Such tools play a key role in information retrieval and data collection.

[0033] ③ Database access tool: Specifically designed to connect to and operate various databases, supports the storage and retrieval of relevant service data by querying, updating, and managing data.

[0034] ④ Calculation tool: Designed for requirements such as mathematical operations, statistical analysis, or big data processing, can perform complex calculation tasks, and provide accurate results. For example, it can be used in scenarios such as financial statement analysis and scientific calculations.

[0035] ⑤ Reasoning tool: Relying on preset rules or models, conducts logical analysis and judgment on input data to draw conclusions or make decisions. Such tools are widely used in fields such as intelligent decision support and expert systems.

[0036] ⑥ Image processing tool: Used for operations such as editing, filtering, cropping, feature extraction, and recognition of images. Applicable to scenarios such as image optimization, monitoring systems, and visual recognition.

[0037] ⑦ Natural language processing tool: Focuses on text analysis and processing, such as language translation, sentiment analysis, keyword extraction, automatic summarization, and question-and-answer systems, to help the system better understand and generate natural language content.

[0038] ⑧ Data visualization tool: Converts complex data into charts, graphs, or dashboards, facilitating users to intuitively discover patterns and trends in the data, and is commonly used in business intelligence and report displays.

[0039] ⑨ Web crawler tools: Automatically crawl public data on the Internet, collect information and organize it to provide data support for subsequent data analysis and intelligence acquisition.

[0040] ⑩ Log analysis tools: Collect and parse information such as system logs and error records to help developers identify system bottlenecks, fault causes, and security vulnerabilities, improving system maintenance efficiency.

[0041] Scheduling tools: Used to coordinate and manage the execution order and timing of multiple tasks or services to ensure efficient resource utilization, commonly found in distributed systems and large-scale task scheduling.

[0042] Monitoring tools: Real-time track system status and service metrics, promptly detect anomalies and issue alarms or perform automatic processing to ensure the stable operation of the system.

[0043] Security detection tools: Scan for vulnerabilities and conduct security assessments on systems or applications to prevent potential attacks and enhance overall security protection capabilities.

[0044] Speech recognition and synthesis tools: Implement the conversion from speech to text or synthesize speech from text, widely used in scenarios such as intelligent assistants, customer service systems, and interactive voice response.

[0045] API gateway tools: Manage and route various service call requests to achieve data interaction and unified management between different systems or modules, optimizing the interface call process.

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

[0047] Based on the problems in the related technologies, please refer to Figure 1 , this embodiment of the specification provides a method for generating a tool graph, which can be executed by an electronic device. The electronic device includes but is not limited to physical servers, server clusters, cloud servers, smart phones / mobile phones, tablet computers, personal digital assistants (PDAs), laptop computers, and desktop computers, etc. The method includes:

[0048] In S101, obtain multiple tools for a calling object to call, 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 dependency relationships between any two tools.

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

[0050] The initial tool graph is a directed graph G = (V, E) of multiple tools and their relationships. The vertex set (V = {set of tools}) is the set of all tools, where each tool corresponds to a vertex in the graph. The directed edge set (E = {(u, v)}) represents the directed edge between tool u and tool v. In some scenarios, the initial tool graph may also contain other information, such as setting a weight for each directed edge. Then the directed edge set (E = {(u, v, w)}) represents the directed edge 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.

[0051] The calling object refers to the subject that initiates the tool calling request. Specifically, the calling object can be a human user in the traditional sense (such as developers, analysts, etc.) or a non-human entity, such as a pre-trained language model or other intelligent agent system. Among them, pre-trained language models, such as large language models (LLM), are based on deep learning technology, especially artificial intelligence models trained with a large corpus, designed to understand and generate texts similar to human language, and have strong natural language understanding and generation capabilities; the goal of pre-trained language models is to achieve a variety of applications through natural language processing capabilities, such as text generation, translation, summarization, question and answer, and dialogue systems, thereby helping to improve the efficiency and automation of human-computer interaction. But not limited to this.

[0052] In one possible implementation, Figure 2 As shown, during the initialization process, the electronic device can construct directed edges from each vertex to other vertices, thereby obtaining an initial tool graph, which is a fully connected graph. The fully connected graph ensures that all potential dependencies between tools are taken into account, and even in the absence of historical data or prior knowledge, important interactions that may exist are not missed. This method is simple to implement and does not rely on additional data input. It is convenient for quickly generating an initial tool graph and provides a complete set of candidate relationships for subsequent iterative optimization. In the subsequent iterative process, the electronic device can gradually adjust and filter out truly effective tool dependencies based on actual execution feedback.

[0053] In another possible implementation, the electronic device can obtain at least one of the historical call trace information of the calling object for the above-mentioned multiple tools, the reference call trace information input by the user for the above-mentioned multiple tools, and the reference call trace information generated by the pre-trained language model for the above-mentioned multiple tools, and establish a directed edge in the initial tool graph based on at least one of the historical call trace information and the reference call trace information. In this embodiment, by using the real historical trace and the reference information provided by the user / pre-trained model, an initial tool graph that better fits the actual usage situation can be constructed, reducing invalid or redundant edges; and the initial tool graph generated based on at least one of the historical call trace information and the reference call trace information often can approach the actual requirements faster, which can shorten the subsequent iteration optimization cycle.

[0054] Among them, the electronic device can input the call parameters, function description information, and return parameters corresponding to the multiple tools into the pre-trained language model respectively, so that the pre-trained language model can clarify the correlation between the multiple tools by understanding the call parameters, function description information, and return parameters corresponding to the multiple tools respectively, thereby generating the reference call trace information for the above-mentioned multiple tools. In this embodiment, through the semantic analysis of the call parameters, function description, and return parameters of the tools by the pre-trained language model, the correlation between the tools can be captured, providing a more scientific basis for subsequent iteration optimization.

[0055] In S102, (a) Take the initial tool graph as the tool graph to be optimized in the first round of the iterative process, and loop through the following iterative process to complete the tool graph optimization task: (b) 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.

[0056] In this step, in each round of the iterative process, multiple tool call paths can be determined from the tool graph to be optimized, that is, determine the call order and combination method between different tools. Then execute each tool call path, collect the execution results of each tool call path, and modify the directed edges (that is, the dependency relationship between tools) in the tool graph to be optimized according to the execution results of the tool call paths (for example, strengthen or weaken the weights of some edges, delete some edges, etc.), thereby generating an updated tool graph. This iterative optimization method can continuously correct and improve the dependency relationship between tools based on the actual execution results, and finally obtain a more efficient and reasonable tool combination scheme, providing a better decision-making basis for the calling object.

[0057] The following is an exemplary description of the determination process of multiple tool call paths:

[0058] In a possible implementation, each vertex and each directed edge in the tool graph to be optimized can be traversed based on a preset path length range to obtain multiple tool call paths. The preset path length range refers to the range of the number of tools in the tool call path or the range of the number of directed edges. By traversing each vertex and each directed edge in the tool graph to be optimized, all possible tool call paths are generated within the preset path length range, thus ensuring that no potential tool combinations or dependencies are missed. This method is applicable to scenarios with a small number of tools and a simple graph structure. The full traversal method can quickly list all possible call paths, facilitating analysis and comparison.

[0059] For example, assume that there is a tool graph to be optimized with 5 vertices, and the preset path length range stipulates that the number of directed edges in the tool call path is between 1 and 10. If the traversal method is adopted and each value within the path length range is considered, then the directed edges connected to each vertex can be traversed in sequence. In theory, 50 tool call paths can be determined. This method can completely capture all potential combinations among tools when the number of tools in the graph is small.

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

[0061] Please refer to Figure 2 and Figure 3 , assume that the electronic device selects the purple tool in the graph as the starting tool, and the preset path length range stipulates that the number of directed edges in the tool call path is between 1 and 10. Then the electronic device starts from this starting tool and considers each value within the path length range. According to the vertex connection situation in the tool graph to be optimized and the preset path length range, 10 tool call paths can be sampled. These sampled tool call paths can represent the main call strategies that the starting tool may adopt, thus providing effective guiding information for subsequent tool graph optimization and avoiding the high computational burden brought by full graph traversal.

[0062] It can be understood that there are no restrictions on the selection of the starting tool in this embodiment, and specific selection can be made according to the actual application scenario. For example, the starting tool can be specified by the user, or the starting tool can be a tool with a historical call count higher than a preset count, so as to sample representative tool call paths from the tool graph to be optimized.

[0063] Exemplarily, 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 executed completely or there is a tool call failure in the tool call path: (1) If the starting tool in the tool call path requires calling parameters, the starting tool in the tool call path is called using the preset call parameter value of the starting tool. Exemplarily, to ensure that each tool call path can be started accurately, for a starting tool that requires calling parameters, the call parameter value of the starting tool can be set in advance. The call parameter value can be input by the user, or it can also be automatically generated by an automated generation tool based on the format of the call parameters 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 calling parameters, the starting tool in the tool call path is directly called. (3) If a subsequent tool in the tool call path other than the starting tool requires calling parameters, a call parameter value is generated based on the return result of the previous tool of the subsequent tool and the subsequent tool is called with this value. (4) If a subsequent tool in the tool call path other than the starting tool does not require calling parameters, the subsequent tool is directly called.

[0064] Through the above execution process, the dependency relationship between tools can be effectively verified. For example, if the execution of a certain tool depends on the return result of a previous tool, the call parameter value of this tool must be generated based on the return result of the previous tool, which clarifies the data dependency relationship between these two tools. And the call order between tools is represented by directed edges. During the execution process, the call of tools always proceeds along the direction of the tool call path, and there will be no reverse call of tools, thus ensuring the directionality of the tool dependency relationship.

[0065] Then after each tool call path is executed completely, the electronic device can collect the execution results of each tool call path. For example, please refer to Figure 2 and Figure 4 , which shows the execution status between each node in each tool call path: In the path1 path, the green tool is called successfully; in the path10 path, the yellow tool is called successfully, and the pink tool call fails.

[0066] Exemplarily, the execution result of the tool call path includes at least one of the following: the call parameters, execution status, and return results of each tool in the tool call path.

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

[0068] The execution status of each tool, including successful call, failed call or abnormal situation, can directly reflect the call result of the tool.

[0069] The return results of each tool can be used to verify the effectiveness of the tool. For example, the return results of some tools will be used as the input of subsequent tools. Therefore, these results need to be recorded to ensure the correct transfer of the data stream. Another example is that if the return result does not meet the expectations (such as incorrect format or missing data), the implementation of the tool can be checked based on this return result.

[0070] In a possible implementation manner, 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 the execution results of each tool call path. For example, if the electronic device pre-stores the mapping relationship between different execution results and modification methods, the electronic device 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 make modifications accordingly. The preset mapping relationship enables the modification process to be automatically identified and applied to the appropriate modification method without manual intervention, reducing the risk of human error, thereby achieving automated, accurate and efficient optimization.

[0071] For example, as shown in the following table, two different mapping relationships between execution results and modification methods are shown:

[0072]

[0073] In another possible implementation, after obtaining the execution results of each tool call path, the electronic device can evaluate the dependency relationships between each tool and its previous tool in each tool call path based on the execution results of each tool call path, and obtain the evaluation results of each tool call path; then, based on the evaluation results corresponding to multiple tool call paths respectively, modify the directed edges in the tool graph to be optimized to obtain the modified tool graph. In this embodiment, by evaluating the execution results of each tool call path, the dependency relationships between tools can be automatically analyzed, and the directed edges in the tool graph can be modified in real time accordingly, so that the tool graph always reflects the latest actual dependency status. Moreover, through automated evaluation, the subjective biases and errors caused by manual analysis can be reduced, the consistency and objectivity of the overall evaluation can be improved, and the optimization process of the tool graph can be made more reliable.

[0074] Exemplarily, the evaluation results of each tool call path include at least one of the following: the parameter dependency between each non-starting tool and its previous tool, the execution status of each non-starting tool, and the correlation between each non-starting tool and its previous tool. Among them, the non-starting tool refers to other tools in the tool call path except the starting tool.

[0075] The parameter dependency between each non-starting tool and its previous tool is used to evaluate whether the call parameters of this non-starting tool truly depend on the return result of the previous tool. It can reflect the tightness of the dependency relationship; if the dependency is strong, it indicates that the output of the previous tool is crucial for the current tool, otherwise there may be redundant or unnecessary dependencies.

[0076] The execution status of each non-starting tool records the running situation of the tool during the call, such as success, failure, or abnormal situation. By monitoring the execution status, problems occurring during the call can be detected and located in a timely manner, which is convenient for subsequent adjustment of the tool call order or replacement of unstable tools, thereby improving the overall execution success rate.

[0077] The correlation between each non-starting tool and its previous tool is used to evaluate the logical and data matching degree between the output of the previous tool and the input of the current tool. A high correlation indicates that the data flow or logical flow between tools is well-connected, while a low correlation indicates that there may be problems such as interface mismatch and data format error, thereby guiding the electronic device to adjust and optimize the dependency relationship.

[0078] Exemplarily, to improve the evaluation efficiency, the electronic device can generate evaluation prompt words based on the execution results of each tool call path, and input the evaluation prompt words into a pre-trained language model, so that the pre-trained language model can evaluate the dependency relationship between each tool and its previous tool in each tool call path to obtain the evaluation results of each tool call path. In this embodiment, by means of a pre-trained language model (such as a large language model) for evaluation, the pre-trained language model has strong semantic understanding ability and can analyze the complex relationship between call parameters, execution status and return results, so as to more accurately judge the dependency strength and matching degree between tools.

[0079] In one example, please refer to Figure 2 and Figure 5 , which shows the evaluation prompt words input into the pre-trained language model and the evaluation results output by the pre-trained language model. It can be understood that each tool call path can be input to the pre-trained language model in a format that the pre-trained language model can receive, and this embodiment does not impose any restrictions on this.

[0080] Of course, in addition to using the pre-trained language model for evaluation, other automated evaluation means can also be adopted, 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 dependency edges between tools.

[0081] The following is an exemplary description of the modification process of the directed edges in the tool graph to be optimized:

[0082] In a possible implementation manner, after obtaining the evaluation results corresponding to multiple tool call paths respectively, the electronic device can directly judge based on the evaluation results corresponding to multiple tool call paths respectively. If the evaluation results indicate that the dependency relationship reflected by a certain directed edge does not meet the expectations (such as no parameter dependency, execution status failure, etc.), the electronic device directly decides to delete the directed edge. In this embodiment, only a binary judgment (delete or retain) is made according to the evaluation results, and the implementation process is simple and direct, which is suitable for scenarios where the evaluation results are clear and fast response is required, and can quickly eliminate invalid or inefficient dependency relationships.

[0083] In another possible implementation, all the 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. After obtaining the evaluation results corresponding to multiple tool call paths respectively, the electronic device can modify the weights of the directed edges in the tool graph to be optimized based on the evaluation results corresponding to the multiple tool call paths respectively, and delete the directed edges with the modified weights lower than the preset threshold to obtain the modified tool graph. In this embodiment, by assigning a quantitative weight to the dependence relationship, the strength of the dependence between tools can be described more precisely, so that the edges that may still play a certain role although the dependence is weak can be retained, providing a reference for subsequent further optimization. Among them, the preset threshold can be specifically set according to the actual application scenario.

[0084] Exemplarily, the evaluation results of each tool call path include the evaluation content of each non-starting tool in the tool call path, and the evaluation content includes at least one of the parameter dependence between each non-starting tool and the previous tool, the execution state of each non-starting tool, and the correlation between each non-starting tool and the previous tool. Then, the electronic device can modify the weight of the directed edge between the non-starting tool and the previous tool in the tool graph to be optimized according to the evaluation content of each non-starting tool, and the modified weight can truly reflect the strength of the dependence relationship between the non-starting tool and the previous tool, making the tool graph more in line with the actual call situation. The high-weight dependence edges indicate key tool combination relationships, which will help to retain and strengthen effective call paths in subsequent iterations, while the low-weight edges may be deleted, thereby removing redundant or unstable dependence relationships. Finally, only efficient and stable dependence relationships are retained, realizing the fine-grained optimization of the tool graph and providing a more accurate and effective tool combination guidance for the calling object (such as a user or a large language model).

[0085] Such as please refer to Figure 2 and Figure 6 , which shows a schematic diagram of updating the weights of each directed edge.

[0086] Taking the parameter dependence between each non-starting tool and the previous tool as an example: the modified weight of the directed edge between each non-starting tool and the previous tool has a positive correlation with the parameter dependence. That is, when the parameter dependence is high, it means that if the output of the previous tool changes, the behavior of the subsequent tool will also be significantly affected. Therefore, this dependence relationship should be strengthened, and the electronic device will increase the weight of this directed edge; on the contrary, when the parameter dependence is low, it means that the subsequent tool may not completely depend on the output of the previous tool, so the importance of this dependence relationship is relatively low, and the electronic device reduces the weight of this directed edge. Such as please refer to Figure 6, in path1, the green tool does not depend on the output of the purple tool. For example, the green tool can be directly called without parameters, so the weight of the directed edge between the two is reduced. In path10, the yellow tool depends on the output of the purple tool, so the weight of the directed edge between the two is increased.

[0087] Taking the execution status of each non-starting tool as an example, the modified weight of the directed edge between each non-starting tool and the previous tool has a positive correlation with the execution status. When the execution status of the non-starting tool is successful, it indicates that the previous tool provides valid and correct input for the subsequent tool, making the entire call process smooth, and the weight of the corresponding directed edge will be increased; if the execution status fails or is abnormal, it means that the output of the previous tool is not sufficient to support the normal operation of the subsequent tool, or there is a problem with the dependency relationship, then the weight of this directed edge is reduced. For example, please refer to Figure 6 , in path10, the call of the pink tool fails, so the weight of the directed edge between the yellow tool and the pink tool is reduced.

[0088] Taking the correlation between each non-starting tool and the previous tool as an example, the modified weight of the directed edge between each non-starting tool and the previous tool has a positive correlation with the correlation. When the correlation is high, it means that the output of the previous tool highly matches the input of the subsequent tool 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 means that there is an incompatibility in data format or a logical disconnection between the non-starting tool and the previous tool, then the weight of this directed edge is reduced.

[0089] Those skilled in the art can understand that when modifying the weight of the directed edge, only one of the above evaluation indicators can be referred to, or two or more evaluation indicators can be comprehensively considered for adjustment. This embodiment does not make any restrictions on this.

[0090] Exemplarily, before modifying the weight of the directed edge in the tool graph to be optimized, reference tool call paths can also be screened out from multiple tool call paths based on the evaluation results corresponding to the multiple tool call paths. For example, call paths with obvious anomalies or inefficient performances in one or more evaluation indicators can be excluded. Finally, using the evaluation results of the reference tool call paths, the weight of the directed edge in the tool graph to be optimized is modified. The evaluation results of the screened reference tool call paths will be more representative and reliable, facilitating subsequent use of these results to reasonably modify the weight of the directed edge in the tool graph to be optimized, so that the tool graph can more accurately reflect the actual dependency relationship between tools.

[0091] In S103, it is judged whether the iteration end condition is satisfied.

[0092] After each iteration, the electronic device checks whether the current tool graph meets the preset end condition. Through this judgment, over-iteration can be avoided, ensuring that the optimization process is terminated in a timely manner after reaching the ideal state, thereby improving efficiency and saving computing resources.

[0093] Exemplarily, the iteration end condition includes at least one of the following:

[0094] (1) The modified tool graph obtained in the current iteration process is the same as the modified tool graph obtained in at least one previous iteration process; it is applicable to scenarios where the problem is relatively simple, the tool dependency relationship is relatively clear, or the optimization space is limited, and it can converge quickly to ensure the stability of the result.

[0095] (2) The difference between the modified tool graph obtained in the current iteration process and the modified tool graph obtained in at least one previous iteration process is less than the preset difference; it is applicable to scenarios where the problem is more complex, the tool combination has a certain degree of dynamics, and convergence judgment is allowed within a certain tolerance range, which can not only ensure the convergence accuracy but also avoid infinite iteration due to small fluctuations. By setting the preset difference (tolerance value) to determine convergence, it can not only capture the trend of overall structural stability but also balance the consumption of computing resources.

[0096] (3) The current iteration count reaches the maximum iteration count; as a protection mechanism, it prevents the iteration process from extending infinitely when convergence cannot be clearly determined or the iteration change amplitude never reaches the preset tolerance.

[0097] In S104, when the iteration end condition is not met, the modified tool graph is used as the tool graph to be optimized in the next iteration process.

[0098] In this step, if it is checked and found that the iteration end condition has not been met, the electronic device uses the updated tool graph as the basis for the next iteration and repeats the call path determination, execution, and graph structure modification processes in step S102. Continuous iteration enables the electronic device to continuously absorb execution feedback and gradually improve the call relationship between tools. This adaptive adjustment ensures that the finally output tool graph can better meet the requirements of complex tasks and can provide accurate and flexible tool combination suggestions regardless of how the requirements of the calling object change.

[0099] In S105, when the iteration end condition is met, the modified tool graph obtained in the last iteration process is saved as the target tool graph, and the target tool graph is used to provide a reference for the calling object when combining tools.

[0100] In this step, once the iteration end condition is met, the electronic device saves the modified tool graph obtained in the last iteration as the target tool graph. As the final result, this graph provides an intuitive and reliable reference for the calling object when combining and using tools in actual tasks. The saved target tool graph can directly guide the calling object (user or large language model) to select a better tool combination, thereby reducing the operation complexity, reducing the risk of errors, and enhancing the overall execution efficiency and automation level. When facing complex tasks, these calling objects can obtain the call order and dependency relationships between tools through the tool graph, thus helping them more efficiently combine and use various tools to achieve automated and intelligent operations and decisions.

[0101] In some embodiments, 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. These directed edges initially represent the possible dependency relationships between the new tool and the existing tools, forming a tool graph to be optimized. Then, the above-mentioned tool graph optimization task is re-executed using the tool graph to be optimized. By evaluating the execution results of each tool call path, the dependency relationships between the new tool and other tools are dynamically adjusted, thereby generating a new target tool graph that includes the new tool. In this embodiment, the new tool is quickly integrated into the tool graph by automatically adding a new vertex and establishing fully connected directed edges without manual intervention, supporting the dynamic expansion and continuous update of the system. By re-executing the optimization task, the entire tool graph can be automatically adjusted, re-evaluating and optimizing the dependency relationships between the new and existing tools to ensure that the new tool can work in coordination with the existing tools and improve the flexibility of overall task execution. This mechanism ensures continuous learning and improvement. By continuously re-evaluating and optimizing the tool combination, it promotes the continuous optimization of the service process and can quickly respond to new requirements and technological advancements.

[0102] In some embodiments, the electronic device can monitor the execution status of each tool during the tool call process, such as metrics like call success rate, correctness of the returned result, response time, etc. If the execution status of a certain tool does not meet the expectation, this tool will be determined as a "failed tool". In other words, a failed tool refers to a tool that fails to achieve the expected effect during the actual call process, specifically including but not limited to the following situations: (1) Execution failure, where the tool often returns error, exception information, or timeouts during the call and cannot complete the task normally. (2) Abnormal returned result, where the output result of the tool does not conform to the preset standard or expected format, resulting in subsequent tools being unable to correctly parse or process it. (3) Low stability, where the tool shows inconsistency, such as large fluctuations in the results of multiple calls under the same conditions or occasional successes and occasional failures. (4) Poor response performance, where the tool has a long delay during the execution process, seriously affecting the overall process efficiency.

[0103] If multiple tools among the detected tools are the failed tools mentioned above, the electronic device can use the target tool graph as the tool graph to be optimized, ensuring that the new optimization process is carried out on the basis of the existing better structure, and only needs to adjust the impact caused by the failed tool and re-execute the tool graph optimization task. For example, the tool graph is modified according to the evaluation result of the failed tool, and measures such as deleting the nodes of the failed tool and weakening or deleting the directed edges related to it are taken. After that, the electronic device recalculates and optimizes the dependencies between the tools to generate an updated target tool graph, ensuring that the entire tool combination system is more stable and efficient. In this embodiment, removing or weakening the dependencies of the failed tool can prevent the failed tool from affecting the entire tool call process, reduce the error rate and failure risk. The tool graph generated after re-optimization will only contain tools with good performance and stability, ensuring that the dependencies between the tools are more reasonable and efficient, thereby improving the success rate of task execution. The automated re-optimization mechanism enables the electronic device to continuously absorb execution feedback, continuously improve the tool graph structure, and reduce the complexity of subsequent maintenance and upgrade.

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

[0105] In some embodiments, the embodiments of this specification also provide an electronic device, including: a processor; a memory for storing executable instructions that can be executed by the processor; wherein, the processor realizes the method described in any one of the above by running the executable instructions.

[0106] Figure 7 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer 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. Of course, there may also be other hardware required for other functions. One or more embodiments of this specification can be implemented in a software manner. 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 the software implementation manner, one or more embodiments of this specification do not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and can also be hardware or a logic device.

[0107] In some embodiments, the tool graph generation device can be applied to a device such as Figure 7 shown to implement the technical solutions of this specification. Among them, the tool graph generation device can include:

[0108] An initialization module, configured to obtain a plurality of tools for a calling object to call, and initialize an initial tool graph based on the plurality of tools. The initial tool graph includes vertices for representing tools and directed edges for representing the dependency relationships between any two tools.

[0109] A tool graph optimization module, configured to use the initial tool graph as the tool graph to be optimized in the first round of iteration process, and perform the following iterative process in a loop to complete the tool graph optimization task: determine a plurality of tool call paths from the tool graph to be optimized, execute each of the tool call paths to obtain an execution result, and modify the directed edges in the tool graph to be optimized based on the execution result to obtain a modified tool graph.

[0110] The tool graph optimization module is further configured to, when the iteration end condition is not satisfied, use the modified tool graph as the tool graph to be optimized in the next round of iteration process.

[0111] The tool graph optimization module is further configured to, when the iteration end condition is satisfied, save the modified tool graph obtained in the last round of iteration process as a target tool graph, and the target tool graph is used to provide a reference for the calling object when combining and using tools.

[0112] Exemplarily, the tool graph optimization module is specifically configured to call each tool in the tool call path according to the following rules until the tool call path is executed completely or there is a tool call failure: if the starting tool in the tool call path requires calling parameters, call the starting tool in the tool call path by using the preset calling parameter value of the starting tool; if the starting tool in the tool call path does not require calling parameters, directly call the starting tool in the tool call path; if a subsequent tool in the tool call path except the starting tool requires calling parameters, generate a calling parameter value based on the return result of the previous tool of the subsequent tool and call the subsequent tool with this value; if a subsequent tool in the tool call path except the starting tool does not require calling parameters, directly call the subsequent tool.

[0113] Exemplarily, the tool graph optimization module is specifically configured to evaluate the dependency relationship between each non-starting tool and its previous tool in each tool call path based on the execution results of each tool call path to obtain the evaluation results of each tool call path; and modify the directed edges in the tool graph to be optimized based on the evaluation results respectively corresponding to the plurality of tool call paths to obtain a modified tool graph.

[0114] Exemplarily, the tool graph optimization module is specifically configured to generate an evaluation prompt based on the execution results of each of the tool call paths, and input the evaluation prompt into a pre-trained language model, so that the pre-trained language model evaluates the dependency relationship between each non-starting tool and its previous tool in each of the tool call paths, and obtains the evaluation results of each of the tool call paths.

[0115] Exemplarily, the execution results of the tool call path include at least one of the following: the call parameters, execution status, and return results of each tool in the tool call path.

[0116] Exemplarily, the evaluation results of each of the tool call paths include at least one of the following: the parameter dependency between each non-starting tool and its previous tool, the execution status of each non-starting tool, and the correlation between each non-starting tool and its previous tool.

[0117] Exemplarily, all the 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 configured to modify the weights of the directed edges in the tool graph to be optimized based on the evaluation results respectively corresponding to the multiple tool call paths, and delete the directed edges with the modified weights lower than the preset threshold, so as to obtain the modified tool graph.

[0118] Exemplarily, the evaluation results of each of the tool call paths include the parameter dependency between each non-starting tool and its previous tool, and the modified weight of the directed edge between each non-starting tool and its previous tool has a positive correlation with the parameter dependency.

[0119] Exemplarily, the evaluation results of each of the tool call paths include the execution status of each non-starting tool, and the modified weight of the directed edge between each non-starting tool and its previous tool has a positive correlation with the execution status;

[0120] Exemplarily, the evaluation results of each of the tool call paths include the correlation between each non-starting tool and its previous tool, and the modified weight of the directed edge between each non-starting tool and its previous tool has a positive correlation with the correlation.

[0121] Exemplarily, the initial tool graph includes 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 trajectories are generated by a pre-trained language model based on the call parameters, function description information, and return parameters respectively corresponding to the multiple tools.

[0122] Exemplarily, the tool graph optimization module is specifically configured to determine at least one starting tool from the multiple tools; and sample the multiple tool call paths from the tool graph to be optimized based on the at least one starting tool and a preset path length range.

[0123] Exemplarily, the calling object includes a pre-trained language model.

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

[0125] Exemplarily, the tool graph optimization module is further configured to, if a new tool is detected, add a new vertex for indicating the new tool to the target tool graph, establish directed edges between the new vertex and all vertices in the target tool graph, and 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.

[0126] Exemplarily, the tool graph optimization module is further configured to, if a failed tool is detected among the multiple 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.

[0127] For the implementation processes of the functions and roles of each module in the above device, please refer to the implementation processes of the corresponding steps in the above method for details, which will not be elaborated here.

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

[0129] Based on the same concept as the above method, this specification also provides a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method as described in any one of the above embodiments are realized.

[0130] A computer-readable medium includes permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules, 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage, quantum memory, graphene-based storage media, or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer-readable medium does not include transitory computer-readable media, such as modulated data signals and carrier waves.

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

[0132] The above description is only the preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of one or more embodiments of this specification shall be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A method for generating a tool diagram, comprising: Acquire multiple tools for calling the calling object, and initialize an initial tool graph based on the multiple tools, wherein the initial tool graph includes vertices for representing tools and directed edges for representing dependency relationships between any two tools; 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 cyclically performed to complete the tool graph optimization task: multiple tool call paths are determined from the tool graph to be optimized, each of the tool call paths is executed to obtain an execution result, and the directed edges in the tool graph to be optimized are modified based on the execution result to obtain a modified tool graph; If the iteration end condition is not met, the modified tool diagram is used as the tool diagram to be optimized in the next round of iteration; When the iteration end condition is met, the modified tool diagram obtained in the last round of iteration process is saved as the target tool diagram, and the target tool diagram is used to provide a reference for the calling object when using tools in combination.

2. The method according to claim 1, wherein executing each of the tool call paths comprises: Each tool in the tool calling path is called according to the following rules until the tool calling path is completed or a tool calling fails: If the starting tool in the tool calling path requires calling parameters, calling the starting tool in the tool calling path using the preset calling parameter value of the starting tool; If the starting tool in the tool calling path does not need calling parameters, directly calling the starting tool in the tool calling path; If a subsequent tool other than the starting tool in the tool calling path requires calling parameters, a calling parameter value is generated based on a return result of a preceding tool of the subsequent tool and the subsequent tool is called with the calling parameter value; If subsequent tools other than the initial tool in the tool calling path do not require calling parameters, the subsequent tools are directly called.

3. The method according to claim 1, wherein the step of modifying the directed edges in the tool graph to be optimized based on the execution result to obtain a modified tool graph comprises: Based on the execution results of each tool calling path, the dependency relationship between each non-starting tool and its predecessor tool in each tool calling path is evaluated to obtain the evaluation result of each tool calling path; Based on the evaluation results respectively corresponding to the multiple tool call paths, the directed edges in the tool graph to be optimized are modified to obtain a modified tool graph.

4. The method according to claim 3, wherein the dependency relationship between each non-starting tool and a preceding tool in each tool calling path is evaluated based on the execution result of each tool calling path to obtain the evaluation result of each tool calling path, comprising: Based on the execution results of each of the tool call paths, evaluation prompt words are generated, and the evaluation prompt words are input into a pre-trained language model so that the pre-trained language model can evaluate the dependency relationship between each non-starting tool and its predecessor tool in each of the tool call paths to obtain the evaluation results of each of the tool call paths.

5. The method according to claim 3, wherein the execution result of the tool call path comprises 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 result of each of the tool call paths includes at least one of the following: parameter dependency between each non-starting tool and a preceding tool, execution status of each non-starting tool, and correlation between each non-starting tool and a preceding tool.

6. The method according to any one of claims 3 to 5, wherein 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 dependency between the two tools; The step of modifying the directed edges in the tool graph to be optimized based on the evaluation results respectively corresponding to the plurality of tool call paths to obtain a modified tool graph includes: Based on the evaluation results respectively corresponding to the multiple tool call paths, the weights of the directed edges in the tool graph to be optimized are modified, and the directed edges whose modified weights are lower than a preset threshold are deleted to obtain a modified tool graph.

7. The method according to claim 6, wherein the evaluation result of each tool call path includes parameter dependencies between each non-starting tool and a preceding tool, and the modified weight of the directed edge between each non-starting tool and a preceding tool has a positive correlation with the parameter dependencies; and / or, the evaluation result of each of the tool call paths includes the execution status of each non-starting tool, and the modified weight of the directed edge between each non-starting tool and the preceding tool has a positive correlation with the execution status; And / or, the evaluation result of each of the tool call paths includes the correlation between each non-starting tool and a preceding tool, and the modified weight of the directed edge between each non-starting tool and a preceding tool has a positive correlation with the correlation.

8. The method of 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 traces of the call object for the multiple tools and / or pre-generated reference call traces for the multiple tools; wherein, The reference call trace is generated by a pre-trained language model based on the call parameters, function description information and return parameters respectively corresponding to the multiple tools.

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

10. The method according to claim 1, wherein the calling object comprises a pre-trained language model; and / or, The iteration end condition includes at least one of the following: the modified tool diagram obtained in the current iteration process is the same as the modified tool diagram obtained in at least one previous iteration process, the difference between the modified tool diagram obtained in the current iteration process and the modified tool diagram obtained in at least one previous iteration process 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 indicating 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 a 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 it is detected that there is a failed tool among the multiple tools, the target tool diagram is used as the tool diagram to be optimized, and the tool diagram optimization task is re-executed to obtain a new target tool diagram.

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

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

15. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 12.

Images