Hypothesis-validation based agent tool invocation methods, devices, and equipment

Abstract

This invention relates to the field of artificial intelligence technology and discloses a hypothesis-verification-based method, apparatus, and device for invoking tools by an intelligent agent. The method includes: acquiring a user task; acquiring a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph; each node in the tool capability graph represents a tool; the preliminary candidate toolset is a set of tools required by the user task; each node in the tool capability graph has its corresponding attribute parameters; generating usage hypotheses corresponding to the tools in the preliminary candidate toolset based on the attribute parameters; acquiring expected target hypotheses based on the usage hypotheses; and invoking the tools corresponding to the expected target hypotheses to generate a completion plan corresponding to the user task. This allows for the simulation of the functions corresponding to each task in the preliminary candidate toolset, thereby selecting expected target hypotheses that meet the requirements of the user task, improving the accuracy of the selected tools, and thus increasing the success rate of the generated completion plan.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and more specifically to a hypothesis-validation-based intelligent agent tool invocation method, apparatus, and device. Background Technology

[0002] With the popularization of digital office, project management and cross-domain collaboration, task plan generation has become a core link in improving work efficiency and ensuring the achievement of expected goals. For intelligent agents based on large language models, they need to generate task plans by calling external APIs, functions and other tools to complete complex tasks.

[0003] In existing technologies, it is common practice to match user-input tasks with static text descriptions of tools to determine the appropriate tool and then generate a plan. However, when the tool library is large and contains overlapping functions, semantic matching based on plain text struggles to distinguish subtle functional differences, easily leading to incorrect tool selection and ultimately rendering the generated plan unusable.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The technical problem to be solved by the present invention is how to improve the accuracy of the selected tools, thereby increasing the success rate of the plan. The purpose is to provide a hypothesis-validation-based agent tool invocation method, apparatus and device to improve the accuracy of the selected tools and thus increase the success rate of the plan.

[0006] This invention is achieved through the following technical solution:

[0007] In a first aspect, a hypothesis-validation-based intelligent agent tool invocation method includes: acquiring a user task; acquiring a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph; the tool capability graph having multiple nodes; each node representing a tool; the preliminary candidate toolset being a set of tools required by the user task; each node of the tool capability graph having its corresponding attribute parameters; generating usage hypotheses corresponding to the tools in the preliminary candidate toolset based on the attribute parameters; acquiring expected target hypotheses based on the usage hypotheses; and invoking the tools corresponding to the expected target hypotheses to generate a completion plan corresponding to the user task.

[0008] In some embodiments, the attribute parameters include static attributes and dynamic attributes; wherein, the static attributes include the name, description text, structured parameter value definition, and category label of the tool corresponding to the node; the dynamic attributes include the confidence level, success profile, failure profile, and utility index corresponding to the tool; and the edges of the tool capability graph are used to represent the relationships between tools.

[0009] In some embodiments, obtaining a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph includes: performing intent parsing on the user task to obtain semantic features corresponding to the user task; determining one or more task categories corresponding to the user task based on the semantic features; filtering nodes that match the task categories based on the category labels of each node in the tool capability graph; and merging the nodes corresponding to different task categories to obtain a preliminary candidate toolset corresponding to the task category.

[0010] In some embodiments, generating usage hypotheses corresponding to tools in the preliminary candidate toolset includes: obtaining parameter values ​​and expected goals corresponding to tools in the preliminary candidate toolset based on the user task; and generating usage hypotheses corresponding to tools in the preliminary candidate toolset based on the tools in the preliminary candidate toolset, the parameter values, and the expected goals, according to a preset hypothesis document format.

[0011] In some embodiments, determining the expected target hypothesis among the usage hypotheses includes: obtaining a hypothesis score corresponding to the usage hypothesis; and determining the expected target hypothesis among the usage hypotheses based on the hypothesis score.

[0012] In some embodiments, generating a completion plan for the user task based on the expected goal assumptions includes: obtaining and determining the dependencies and conflicts between the expected goal assumptions according to the tool capability graph; and generating a completion plan for the user task based on the dependencies and conflicts between the expected goal assumptions.

[0013] In some embodiments, after calling the tool corresponding to the expected target assumption to generate the completion plan corresponding to the user task, the method further includes: executing the completion plan and obtaining the execution result; updating the attribute parameters of the node corresponding to the called tool according to the execution result; if the execution result is an execution failure, performing attribution analysis on the reason for the failure of the completion plan to obtain the reason for failure; and starting a preset exploration strategy to correct or regenerate the completion plan according to the reason for failure.

[0014] Secondly, a hypothesis-validation-based intelligent agent tool invocation device includes: a task acquisition module configured to acquire a user task; a toolset acquisition module configured to acquire a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph; the tool capability graph has multiple nodes; each node represents a tool; the preliminary candidate toolset is a set of tools required by the user task; each node of the tool capability graph has its corresponding attribute parameters; a hypothesis generation module configured to generate usage hypotheses corresponding to the tools in the preliminary candidate toolset based on the attribute parameters; a determination module configured to determine an expected target hypothesis from the usage hypotheses; and a plan generation module configured to invoke the tool corresponding to the expected target hypothesis to generate a completion plan corresponding to the user task.

[0015] Thirdly, a hypothesis-verification-based agent tool invocation apparatus includes a processor and a memory storing program instructions, wherein the processor is configured to execute the aforementioned hypothesis-verification-based agent tool invocation method when running the program instructions.

[0016] Fourthly, an electronic device includes the aforementioned hypothesis-verification-based agent tool invocation device.

[0017] Compared with existing technologies, this invention acquires the user task, then obtains a preliminary candidate toolset based on a preset tool capability map, including the tools required for the user task. Next, it generates usage hypotheses for the tools in the preliminary candidate toolset based on the attribute parameters of the nodes within the preliminary candidate toolset. Finally, it obtains expected target hypotheses based on these usage hypotheses and calls the tools corresponding to these expected target hypotheses to generate a completion plan for the user task. This approach, by first acquiring the preliminary candidate toolset and then generating hypotheses for the tools within it, simulates the functions of each task within the preliminary candidate toolset, thereby selecting the expected target hypotheses that meet the user task requirements. This improves the accuracy of tool selection and ultimately increases the success rate of the generated completion plan. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0019] Figure 1 This is a flowchart of a hypothesis-verification-based intelligent agent tool invocation method provided in an embodiment of this disclosure;

[0020] Figure 2 This is an example diagram of a tool capability map provided in an embodiment of this disclosure;

[0021] Figure 3 This is a flowchart of another hypothesis-verification-based agent tool invocation method provided in this disclosure embodiment;

[0022] Figure 4 This is a schematic diagram of a hypothesis-verification-based intelligent agent tool invocation device provided in an embodiment of this disclosure;

[0023] Figure 5 This is a schematic diagram of another hypothesis-verification-based intelligent agent tool invocation device provided in an embodiment of this disclosure. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0025] 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 numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0028] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0029] Please see Figure 1 , Figure 1 This is a flowchart illustrating a hypothesis-verification-based agent tool invocation method, as shown in an exemplary embodiment of this application.

[0030] Combination Figure 1 As shown, this disclosure provides a hypothesis-verification-based agent tool invocation method, including:

[0031] Step S101: Obtain user tasks.

[0032] Step S102: Obtain a preliminary candidate toolset corresponding to the user task based on the preset tool capability graph; the tool capability graph has multiple nodes; each node represents a tool; the preliminary candidate toolset is a set of tools required by the user task; each node of the tool capability graph has its corresponding attribute parameters.

[0033] Step S103: Generate usage hypotheses for the tools in the preliminary candidate toolset based on the attribute parameters.

[0034] Step S104: Obtain the expected target hypothesis based on the usage hypothesis.

[0035] Step S105: Invoke the tool corresponding to the expected goal assumption to generate the completion plan corresponding to the user task.

[0036] The hypothesis-verification-based intelligent agent tool invocation method provided in this disclosure involves acquiring a user task, then obtaining a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph, including the tools required for the user task, generating usage hypotheses for the tools in the preliminary candidate toolset based on the attribute parameters corresponding to the nodes in the preliminary candidate toolset, obtaining the expected target hypothesis based on the usage hypothesis, and then invoking the tool corresponding to the expected target hypothesis to generate a completion plan for the user task. In this way, by first acquiring a preliminary candidate toolset for the user task and then generating hypotheses for the tools within it, the functionality corresponding to each task in the preliminary candidate toolset can be simulated, thereby selecting the expected target hypothesis that meets the requirements of the user task. This improves the accuracy of the selected tools and thus increases the success rate of the generated completion plan.

[0037] It should be noted that the intelligent agent can invoke tools based on a large language model. Therefore, the user task can be a task input by the user into the large language model that needs to be completed. Examples include: booking a flight to Beijing, generating a complete weekend travel plan for Shanghai, checking the weather in Beijing tomorrow, and arranging a meeting.

[0038] Specifically, the system includes static and dynamic attributes. Static attributes include the tool's name, description text, structured parameter values, and category label. Dynamic attributes include the tool's confidence level, success profile, failure profile, and utility index. The edges of the tool capability graph represent the relationships between tools. Since static attributes only display the fixed properties of a node and cannot reflect its actual performance during runtime, the introduction of dynamic attributes—confidence level, success profile, failure profile, and utility index—allows for understanding the true performance of the tool corresponding to a node from these dynamic attributes. This constructs and maintains a dynamic, multi-dimensional tool capability graph, serving as the system's core knowledge base. This graph replaces the traditional static tool list, improving the accuracy of tool selection.

[0039] It should be noted that static attributes are fixed attributes of a node and do not change. Dynamic attributes are variable attributes of a node and can change.

[0040] Description text, used to describe the function of this node.

[0041] Structured parameter value definitions are used to describe the inputs and outputs of the tool corresponding to this node.

[0042] Category labels are categorized markers for tools, used for quick filtering.

[0043] Confidence level is an estimated probability that the tool corresponding to a given node will complete its claimed function, representing the probability of success for that node. It can be calculated based on the historical performance of the tool corresponding to that node.

[0044] A success profile is a pattern feature vector that represents the context in which the tool corresponding to the node tends to execute successfully.

[0045] Failure profile: The pattern feature vector of the context in which the tool corresponding to this node failed to execute.

[0046] Utility metrics include quantitative indicators such as the average execution time and historical success rate of the tool corresponding to the node. Optionally, utility metrics may also include resource consumption.

[0047] It should be noted that the relationships between tools can include sequential relationships and / or substitution relationships. Specifically, a sequential relationship indicates that the tools at both ends of an edge are often used in sequence to complete a task; for example, it means that the output of one tool is usually the input of another tool, indicating a clear sequential dependency. The direction of the edge points to the node corresponding to the tool being called. If the edge has a weight, the weight represents the probability of sequential calling. A substitution relationship indicates that the tools at both ends of an edge have similar functions and can be alternatives to each other. The weight of the edge represents the probability of successful substitution and completion of the task.

[0048] Furthermore, the relationships between tools also include composition relationships. Composition relationships can be represented by enclosing the nodes corresponding to the tools within the composition. Composition relationships indicate that several tools can be combined and work together to complete a task.

[0049] In some embodiments, such as Figure 2 As shown, Figure 2 This is an example diagram of a tool capability graph. Some static and dynamic attributes of each node in the graph are not shown.

[0050] like Figure 2 As shown, the tool's capability graph has 7 nodes, specifically: Node T1, named QueryFlight, with the description "query flight information," indicating that node T1 is a tool for querying flight information; Node T2, named QueryHotel, with the description "query hotel information," indicating that node T1 is a tool for querying hotel information; Node T3, named BookFlight, with the description "book flight," indicating that node T2 is a tool for booking flight information; Node T4, named BookHotel, with the description "book hotel," indicating that node T3 is a tool for booking hotel information; Node T5, named GetWeatherForecast, with the description "get weather forecast," indicating that node T4 is a tool for getting weather forecasts; Node T6, named QueryTrain, with the description "query train tickets," indicating that node T5 is a tool for querying train tickets; and Node T7, named CreateItinerary, with the description "generate travel plans," indicating that node T6 is a tool for generating travel plans.

[0051] The following combination Figure 2 Explain the relationships between the nodes.

[0052] Specifically, for example, the edge between nodes T1 and T3 is a one-way arrow pointing from node T1 to node T3, indicating a dependency relationship between them, with a clear sequential dependency. Its weight is 0.9. This means that users typically first use the tool corresponding to node T1 (T1) to query flight information, obtaining a specific flight ID (flight_id). Then, they pass the flight_id as a parameter to node T3 to call the tool corresponding to node T3 to book the flight corresponding to flight_id. The weight of this edge 0.9 indicates that, historically, there is a 90% chance that calling the tool corresponding to node T1 will subsequently call the tool corresponding to node T3. The relationship between nodes T2 and T4 is the same as that between nodes T1 and T3, and will not be elaborated further.

[0053] For example, the edge between nodes T1 and T6 is a double arrow, indicating a substitution relationship between them. The nodes have similar functions and can be substituted for each other. For instance, in the user task of "querying transportation from Beijing to Shanghai," both the tool corresponding to node T1 and the tool corresponding to node T6 are used to query transportation options; therefore, they are interchangeable options. The edge weight of 0.85 can be interpreted as, based on historical data, when the tool corresponding to node T1 is unavailable or yields poor results, using the tool corresponding to node T6 has an 85% probability of successfully meeting the user's needs.

[0054] For example, consider nodes T1, T2, T5, and T7. Nodes T1, T2, and T5 have a combination relationship. After combination, they also have an order relationship with node T7. For instance, the user task of "generating a complete Shanghai weekend travel plan" cannot be completed using a single tool. The system needs to combine and call the tool corresponding to node T1 to query flights, the tool corresponding to node T2 to query hotels, and the tool corresponding to node T5 to get the weather. Then, the retrieved flight IDs, hotel information, and weather information are used as input to the tool corresponding to node T7. This tool then integrates the retrieved flight IDs, hotel information, and weather information to output the weekend travel itinerary.

[0055] Furthermore, based on a pre-defined tool capability graph, a preliminary candidate toolset is obtained for each user task. This includes: parsing the user task's intent to obtain its semantic features; determining one or more task categories based on these semantic features; filtering nodes matching the task categories based on the category labels of each node in the tool capability graph; and merging the nodes corresponding to different task categories to obtain a preliminary candidate toolset for each task category. In this way, by parsing the user task's intent to obtain its semantic features, one or more task categories can be determined based on these features. Then, nodes matching the task categories are filtered based on the category labels of each node in the tool capability graph. Furthermore, for different task categories, the nodes corresponding to each task category are merged to obtain a preliminary candidate toolset for each task category. This initial filtering of tools corresponding to each node in the tool capability graph using category labels reduces the number of hypotheses that need to be generated, thereby improving the system's response speed and scalability.

[0056] It should be noted that each task category corresponds to a preliminary set of candidate tools.

[0057] Furthermore, the user task is subjected to intent parsing to obtain the semantic features corresponding to the user task, including: inputting the user task into a preset intent parsing model for intent parsing to obtain the semantic features corresponding to the user task.

[0058] It should be noted that determining one or more task categories corresponding to a user task based on semantic features involves analyzing semantic features to decompose the user task into one or more sub-tasks, and then determining the task category corresponding to each sub-task. Semantic features can include keywords in the user task. Through task categories, the two processes of task decomposition are implemented, and corresponding tools are selected for each decomposed task.

[0059] It should be noted that the task categories are arranged in the order in which the user tasks are completed. For example, the user task is "Summarize the sales data of product A in the previous quarter, identify the three regions with the most severe sales decline, and send a report via email." The semantic features extracted by the BERT model include: "summarize data," "identify regions," and "email." By analyzing the semantic features, the user task can be decomposed into subtasks: subtask 1 (data query), subtask 2 (aggregate analysis), subtask 3 (identify the Top-N regions), and subtask 4 (send the report). Therefore, the task categories corresponding to each task are obtained, and the task categories are arranged in the order in which the user tasks are completed: data query, aggregate analysis, identifying the Top-N regions, and sending the report.

[0060] In this way, intent parsing can break down user tasks into one or more subtasks, making it easier to select the appropriate tool for each subtask.

[0061] Furthermore, nodes matching the task category are selected based on the category labels of each node in the tool capability graph, including: selecting nodes in the tool capability graph whose category labels are the same as the task category; and determining the selected nodes as nodes matching the task category.

[0062] Furthermore, for different task categories, the nodes corresponding to the task categories are merged to obtain a preliminary candidate tool set for each task category. That is, nodes with the same task category are merged through intersection or union operations to obtain a preliminary candidate tool set for each task category.

[0063] In some embodiments, common category tags include: weather query, schedule management, communication, calculation, and search. Nodes tagged as weather query include: nodes named GetWeather, nodes named GetForecast, etc. GetWeather is used to obtain real-time weather; GetForecast is used to obtain weather forecasts. Nodes tagged as schedule management include: nodes named ScheduleEven, nodes named RemindEvent, etc. ScheduleEven is used to schedule events; RemindEvent is used to remind users of events. Nodes tagged as communication include: nodes named NotifyUser, nodes named SendEmail, etc. NotifyUser is used to notify users; SendEmail is used to send emails. Nodes tagged as calculation include: nodes named Calculator, nodes named MathSolver, etc. Calculator is used for calculations using a calculator; MathSolver is used for calculations using a mathematical solver. Nodes tagged with "Search" include those with the tool name "WebSearch" and those with the tool name "DatabaseQuery." WebSearch is used for searching via web pages; DatabaseQuery is used for querying via a database.

[0064] The user input task was "Help me check the weather in Beijing tomorrow and schedule a meeting." The semantic features extracted using the BERT model included: "weather," "Beijing," "tomorrow," "schedule," and "meeting." Analysis of these semantic features determined that the user task fell into two categories: weather query and schedule management.

[0065] Then, in the tool capability graph, nodes with the same category label as the task category are selected. That is, nodes with the category label "weather query" include nodes with the tool name "GetWeather", nodes with the tool name "GetForecast", etc.; and nodes with the category label "schedule management" include nodes with the tool name "ScheduleEven", nodes with the tool name "RemindEvent", etc.

[0066] Then, through intersection or union operations, nodes with the same matching task category are merged to obtain a preliminary candidate toolset corresponding to the task category. For example, for the task category "weather query", the corresponding preliminary candidate toolset is {nodes with the tool name "GetWeather" and nodes with the tool name "GetForecast"}.

[0067] Optionally, the initial candidate toolset should be limited to 10-20 items.

[0068] In this way, by obtaining a preliminary set of candidate tools corresponding to the user task based on the preset tool capability map, tools that are irrelevant to the user task are excluded first, thus achieving tool pruning, avoiding full scanning, and improving response speed.

[0069] Furthermore, the generation of usage hypotheses for tools in the preliminary candidate toolset based on attribute parameters includes: obtaining the parameter values ​​and expected goals of the tools in the preliminary candidate toolset from the user task based on the attribute parameters; and generating usage hypotheses for the tools in the preliminary candidate toolset based on the tools, parameter values, and expected goals according to a preset hypothesis document format. In this way, by obtaining the parameter values ​​and expected goals of the tools in the preliminary candidate toolset based on the user task, and then generating usage hypotheses for the tools in the preliminary candidate toolset based on the tools, parameter values, and expected goals according to a preset hypothesis document format, the functionality of each task in the preliminary candidate toolset can be simulated using usage hypotheses, thereby selecting expected goal hypotheses that meet the user task requirements. This improves the accuracy of tool selection and thus increases the success rate of the generated completion plan.

[0070] In some embodiments, the expected target can be inferred from the user task's intent based on the output defined by the structured parameter values ​​in the attribute parameters, and is expressed as the expected output. For example, for the user task "Query transportation from Beijing to Shanghai", the tools in the initial candidate toolset include the tool QueryFlight, which queries flights and outputs flight numbers. By inferring from the user task's intent, the expected output can be determined to be flight numbers from Beijing to Shanghai. The parameter values ​​are the values ​​of the parameters required for the tool to achieve the expected target. These values ​​can be extracted from the user task based on the input defined by the structured parameter values ​​in the attribute parameters, obtained from the usage assumptions corresponding to the tools it depends on, or directly determined as preset default values; no restrictions are placed here.

[0071] For example, for the user task "Query transportation from Beijing to Shanghai", the structured parameter values ​​in its attribute parameters define the input as the origin and destination. Therefore, the parameter value for the origin is Beijing, and the parameter value for the destination is Shanghai.

[0072] It should be noted that the presupposition in this paper can be in the form of: if tool X is used and parameter P is provided, then the expected goal O is expected to be achieved. That is, in some embodiments, for the user task "querying transportation from Beijing to Shanghai", the QueryFlight tool used to query flights is assumed to be: if the QueryFlight tool is used and the parameters origin: Beijing; destination: Shanghai are provided, then the flight number from Beijing to Shanghai is expected to be obtained.

[0073] It should be noted that the format of this paper is not fixed, and other text formats can be used to generate the assumptions, which will not be elaborated here.

[0074] Furthermore, determining the expected target hypothesis within the usage hypothesis process includes: obtaining the hypothesis score corresponding to the usage hypothesis; and determining the expected target hypothesis based on the hypothesis score within the usage hypothesis process. This ensures that the determined expected target hypothesis is one whose hypothesis score in the usage hypothesis process meets the requirements, thereby ensuring that the selected tool meets the requirements and improving the success rate of the generated completion plan.

[0075] It should be noted that for each task category, at least one expected target hypothesis needs to be determined in the hypothesis testing process based on the hypothesis scoring.

[0076] Furthermore, the hypothesis score corresponding to the hypothesis is obtained, including: obtaining the semantic similarity score between the hypothesis and the user task; obtaining the confidence score of the node corresponding to the hypothesis; obtaining the matching score corresponding to the hypothesis; obtaining the parameter score corresponding to the parameter value of the hypothesis; and taking a weighted average of the semantic similarity score, confidence score, matching score and parameter score to obtain the hypothesis score.

[0077] Specifically, obtaining the semantic similarity score between the usage hypothesis and the user task includes: identifying the description text of the tool corresponding to the usage hypothesis as the expected target text; using a pre-defined embedding feature extraction model to obtain the feature embedding vectors corresponding to the expected target text and the user task; and calculating... This yields a semantic similarity score between the hypothesis used and the user's task. To score the semantic similarity between the hypothesis and the user task; Embed the feature vector corresponding to the user task; This is the feature embedding vector corresponding to the expected target text.

[0078] It should be noted that the confidence score of the node corresponding to the hypothesis is obtained through the confidence score of the node corresponding to the hypothesis. For example, the confidence score of the node corresponding to the hypothesis can be directly determined as the confidence score of the node corresponding to the hypothesis. Alternatively, the confidence score can be obtained through other methods based on the confidence score of the node corresponding to the hypothesis; no restrictions are placed here.

[0079] Furthermore, obtaining the matching score corresponding to the hypothesis includes: obtaining the current context vector corresponding to the user task; obtaining the first similarity between the current context vector and the successful profile; obtaining the second similarity between the current context vector and the failed profile; obtaining the candidate score by the difference between the first similarity and the second similarity; and normalizing the candidate score to obtain the matching score.

[0080] Furthermore, obtaining the current context vector corresponding to the user task includes: inputting the user task into a preset context encoding model to obtain the current context vector. The preset context encoding model can be a BERT model, a recurrent neural network, a long short-term memory network, or other models used for context encoding.

[0081] It should be noted that the candidate score is normalized, that is, the candidate score is normalized to a preset range. The preset range can be [0, 1].

[0082] Furthermore, obtaining the parameter score corresponding to the assumed parameter values ​​includes: determining whether each parameter value conforms to the constraints corresponding to the tool; and determining the ratio of the number of parameter values ​​that conform to the constraints corresponding to the tool to the total number of parameter values ​​as the parameter score.

[0083] Furthermore, a weighted average is calculated from the semantic similarity score, confidence score, matching score, and parameter score to obtain the hypothesis score, including: by calculating... , and obtain a hypothesis score. Among them, The first weight corresponding to the semantic similarity score; Score the confidence level; A score for the degree of matching; Rate the parameters; This is the second weight corresponding to the confidence score; The third weight corresponding to the matching score; The fourth weight corresponding to the parameter score.

[0084] It should be noted that the sum of the first, second, third, and fourth weights is 1. The values ​​of the first, second, third, and fourth weights are not fixed and can be dynamically adjusted based on historical validation data or actual circumstances. No restrictions are imposed here.

[0085] Furthermore, the expected target hypothesis is determined based on the hypothesis score in the use hypothesis, including: ranking the use hypotheses according to the hypothesis score in each preliminary candidate toolset; and then determining the top K use hypotheses as the expected target hypotheses.

[0086] Furthermore, the process of generating a completion plan for the user task based on the expected goals involves: identifying and determining the dependencies and conflicts between the expected goals based on the tool capability graph; and generating the completion plan for the user task based on these dependencies and conflicts. By identifying and determining the dependencies and conflicts between the expected goals based on the tool capability graph, and then generating the completion plan for the user task based on these dependencies and conflicts, the tools used to generate the completion plan can meet the requirements of dependencies and conflicts, thus improving the success rate of the generated completion plan.

[0087] The dependencies and conflicts between expected target assumptions are determined by using the tool capability map. In other words, the dependencies and conflicts between the tools corresponding to each expected target assumption are determined by using the tool capability map.

[0088] Furthermore, based on the dependencies and conflicts between the expected goals, a completion plan for the user task is generated, including: generating multiple alternative plans based on the dependencies and conflicts between the expected goals; obtaining the success rate of each alternative plan; and determining the alternative plan with the highest success rate as the completion plan.

[0089] It's important to note that dependencies can determine the order in which tools are invoked. Conflict relationships indicate that two tools cannot coexist. For example, two tools may be interchangeable, or the intended goal of the former tool cannot be used as a parameter value for the latter tool.

[0090] Furthermore, based on the dependencies and conflicts between the expected goals, multiple alternative plans are generated, including: traversing all preliminary candidate toolkits, selecting one tool from each preliminary candidate toolkit to obtain a reference plan. The tools in the reference plan are arranged in order of task category. Alternative plans are then selected from the reference plan based on dependencies and conflicts.

[0091] Specifically, the process of selecting alternative plans from the reference plan based on dependencies and conflicts includes: if the d-th tool in the reference plan has a dependency, and it is determined that the (d-1)-th or (d+1)-th tool is not a tool that depends on the d-th tool, then the reference plan is deleted. If there are conflicts between adjacent tools in the reference plan, then the reference plan is deleted. The remaining reference plans are then identified as alternative plans.

[0092] Furthermore, the success rate of each alternative plan is obtained, including: for each alternative plan, multiplying the historical success rate of each tool in the alternative plan to obtain the success rate of each alternative plan.

[0093] It should be noted that if there are multiple alternative plans with the highest success rate, the total execution time of each of the alternative plans with the highest success rate can be obtained. The alternative plan with the shortest total execution time is determined as the completed plan.

[0094] The total execution time is the sum of the average execution times for each tool in the alternative plans.

[0095] Furthermore, after generating the completion plan corresponding to the user task based on the expected goal assumption, the process also includes: executing the completion plan and obtaining the execution result; updating the attribute parameters of the nodes corresponding to the called tools based on the execution result; performing attribution analysis on the reasons for the failure of the completion plan in the case of execution failure to obtain the reasons for failure; and initiating a preset exploration strategy to correct or regenerate the completion plan based on the reasons for failure. In this way, by generating the completion plan corresponding to the user task, executing the completion plan, obtaining the execution result, and updating the attribute parameters of the nodes corresponding to the called tools based on the execution result, and updating the tool capability graph, the tool capability graph can reflect the historical call situation of each tool, improving the ability to learn from historical call experience and realizing a closed loop of dynamic graph, hypothesis-verification, and exploration feedback. Then, in the case of completion plan execution failure, attribution analysis is performed on the completion plan to obtain the reasons for failure; and based on the reasons for failure, a preset exploration strategy is initiated to correct or regenerate the completion plan to successfully complete the user task.

[0096] It should be noted that executing the completion plan requires a pre-defined, controlled environment, such as a sandbox, where the tools within the completion plan are invoked sequentially. Simultaneously, a detailed log of the entire execution process must be maintained.

[0097] The execution result is either successful or failed. The execution result can be determined by the execution code returned after the plan is completed. For example, the failure of the plan execution can be determined as follows: obtain the execution code returned after the plan execution is completed. If the execution code indicates successful execution, and no first-level exception message or second-level timeout message is returned, and all actual goals output by the tools in the plan are the same as the expected goals, then the plan execution is considered successful. Conversely, if the execution code indicates failure, returns a first-level exception message, a second-level timeout message, or if there are actual goals output by the tools in the plan that are different from the expected goals, then the plan execution is considered failed.

[0098] The returned execution code, first information, second information, and the actual target output of the tool in the completion plan are stored in the log and can be retrieved through the log.

[0099] It should be noted that the attribute parameters of the node corresponding to the invoked tool are updated based on the execution result. That is, the incremental update method is used to update the dynamic attributes of the tool in the completion plan, namely confidence, success profile, failure profile and utility index, in the tool capability graph based on the execution result.

[0100] Specifically, the confidence level of the tools used to complete the plan is updated by calculating... The target confidence level of the tool is obtained. Then, this target confidence level is used to update the tool's original confidence level. The target confidence level for this tool; This represents the confidence level of the tool before the update. This represents the tool's historical call count, i.e., the number of times the tool has been called in the past. This parameter indicates success; its value is 1 if the tool call is successful, and 0 if the tool call fails. It's important to note that task execution failure does not necessarily mean the tool call itself failed. Whether a tool call was successful can be obtained from the logs.

[0101] Specifically, the success profile of the tools in the plan is updated through the following method: Upon successful invocation, by calculating... This allows us to obtain a successful profile of the target user using this tool. To successfully profile the target of this tool; A successful profile of the tool before the update; This is the context vector corresponding to the user task. This represents the number of successful calls to this tool in its history.

[0102] Specifically, the failure profile of the tools in the plan is updated through the following method: In the case of a successful call, by calculating... This allows us to obtain a successful profile of the target user using this tool. Profil the failure of this tool's target; A profile of the failures before the tool was updated; This is the context vector corresponding to the user task. This represents the number of times the tool's historical calls failed.

[0103] Specifically, the average execution time in the utility metrics can be updated using the following method: by calculating... The average execution time was obtained. The new average execution time; This represents the average execution time before the update. This refers to the execution time.

[0104] Specifically, the success rate in the utility metric can be updated using the following method; ,in, For a new success rate; The success rate before the update is given; y represents the success rate of this tool call. A value of 1 indicates a successful tool call, while a value of 0 indicates a failed tool call.

[0105] It should be noted that attribution analysis is performed to investigate the reasons for the failure to complete the plan, i.e., analyzing the causes of failure. Causes of failure include: incorrect parameters, inapplicable tools, and incorrect environment.

[0106] Specifically, when the input tool parameter is invalid or does not conform to the preset definition, the failure reason includes parameter error. For example, the standard input for the address Beijing is: city="Beijing". However, the actual input is: city="Beijin", which is a spelling error and is an invalid parameter. Another example is that the input value is represented as decimal, but the actual input number is hexadecimal, which does not conform to the preset definition.

[0107] When the actual output of the tools in the plan does not match the expected goal, the reasons for failure may include the inapplicability of the tools.

[0108] If there are no parameter errors or inapplicable tools, the cause of failure can be considered as an environmental error. In some embodiments, an environmental error could be a system configuration error, such as no internet access.

[0109] It should be noted that the initiation of the exploration strategy involves modifying the reasons for failure and iteratively executing the algorithm within a sandbox until successful execution or after a preset number of iterations. The preset number of iterations can be less than 5. This approach, compared to existing technologies that only allow simple retries or random selection of alternatives when the initial tool selection fails, provides a systematic, knowledge-based exploration strategy, thereby improving task robustness and success rate.

[0110] In some embodiments, if the failure is due to incorrect parameters, the incorrect parameters can be corrected.

[0111] If the failure is due to reasons such as tool inapplicability, the suboptimal hypothesis can be obtained. The failed tool can then be replaced with the tool corresponding to the suboptimal hypothesis. The suboptimal hypothesis is the next best hypothesis for the tool after ranking the usable hypotheses.

[0112] In cases where failure is caused by environmental errors, alternatives can be made based on tools that have a substitution relationship with the tool in the tool capability map.

[0113] It should be noted that when there are multiple reasons for failure, exploration strategies can be combined according to the specific circumstances.

[0114] It should be noted that after the completion of the plan, the process also includes updating the tool's capability graph if the plan is successfully executed. For example, updating the confidence level and success profile.

[0115] Please see Figure 3 , Figure 3 This is a flowchart illustrating a hypothesis-verification-based agent tool invocation method, as shown in another exemplary embodiment of this application.

[0116] Combination Figure 3 As shown, this disclosure provides a hypothesis-verification-based agent tool invocation method, including:

[0117] Step S301: Obtain user tasks.

[0118] Step S302: Perform intent parsing on the user task to obtain the semantic features corresponding to the user task.

[0119] Step S303: Determine one or more task categories corresponding to the user task based on semantic features.

[0120] Step S304: Filter the nodes that match the task category based on the category labels of each node in the tool capability graph. The tool capability graph has multiple nodes. Each node represents a tool.

[0121] Step S305: For different task categories, merge the nodes corresponding to each task category to obtain a preliminary candidate toolset for each task category. The preliminary candidate toolset is a set of tools required for the user's task.

[0122] Step S306: Obtain the parameter values ​​and expected goals corresponding to the tools in the preliminary candidate toolset based on the user task.

[0123] Step S307: According to the preset hypothesis document format, generate usage hypotheses corresponding to the tools in the preliminary candidate tool set based on the tools, parameter values, and expected goals in the preliminary candidate tool set.

[0124] Step S308: Obtain the hypothesis score corresponding to the hypothesis used.

[0125] Step S309: Determine the expected target hypothesis based on the hypothesis score in the hypothesis usage.

[0126] Step S310: Based on the tool capability map, determine the dependencies and conflicts between the expected target assumptions.

[0127] Step S311: Generate a completion plan for the user task based on the dependencies and conflicts between the expected goals.

[0128] Step S312: Execute the completion plan and obtain the execution results;

[0129] Step S313: Update the attribute parameters of the node corresponding to the invoked tool based on the execution result;

[0130] Step S314: If the execution result is execution failure, perform attribution analysis on the reasons for the failure to complete the plan and obtain the reasons for the failure.

[0131] Step S315: Based on the reason for failure, activate the preset exploration strategy to correct or regenerate the completion plan.

[0132] The hypothesis-verification-based intelligent agent tool invocation method provided in this disclosure acquires a user task, then performs intent parsing on the user task to obtain semantic features corresponding to the user task, so as to determine one or more task categories corresponding to the user task based on the semantic features. Then, nodes matching the task category are filtered according to the category labels of each node in the tool capability graph. Furthermore, for different task categories, the nodes corresponding to each task category are merged to obtain a preliminary candidate toolset for each task category. The category labels enable preliminary filtering of tools corresponding to each node in the tool capability graph, reducing the number of tools required. Then, the parameter values ​​and expected goals corresponding to the tools in the preliminary candidate toolset are obtained based on the user task. Finally, according to a preset hypothesis document format, usage hypotheses corresponding to the tools in the preliminary candidate toolset are generated based on the tools, parameter values, and expected goals in the preliminary candidate toolset. This system leverages hypotheses to simulate the functionality of each task within a preliminary candidate toolkit, selecting the target hypothesis that meets the user's task requirements and obtaining its score. Based on this score, the system determines the target hypothesis within the initial set of target hypotheses, ensuring that the selected tool meets the required score. Furthermore, it uses a tool capability graph to identify dependencies and conflicts between these target hypotheses. This data is then used to generate a completion plan for the user task, ensuring that the tools within the plan meet the dependency and conflict requirements, thus improving the success rate of the generated plan. After generating the completion plan, the system executes it, obtains the execution results, and updates the attribute parameters of the nodes corresponding to the called tools. By updating the tool capability graph, it reflects the historical call history of each tool, enhancing the ability to learn from historical experience and achieving a closed loop of dynamic graph, hypothesis-validation, and exploration feedback. Then, in the event that the completion plan fails to be executed, the cause analysis of the completion plan is performed to obtain the reasons for the failure. Based on the reasons for the failure, a preset exploration strategy is initiated to correct or regenerate the completion plan so that the user task can be successfully completed. This allows the tool capability graph to reflect the historical call status of each tool, improves the ability to learn from historical call experience, and enables the selection of more accurate tools in the next tool selection, thereby improving the success rate of the generated completion plan.

[0133] Combination Figure 4 As shown, this disclosure provides a hypothesis-verification-based intelligent agent tool invocation device 400, which includes: a task acquisition module 401, a toolset acquisition module 402, a hypothesis generation module 403, a determination module 404, and a plan generation module 405.

[0134] Among them, the task acquisition module 401 is configured to acquire user tasks.

[0135] The toolset acquisition module 402 is configured to acquire a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph; the tool capability graph has multiple nodes; each node represents a tool; the preliminary candidate toolset is a set of tools required by the user task; each node of the tool capability graph has its corresponding attribute parameters.

[0136] Assume that generation module 403 is configured to generate usage hypotheses for tools in a preliminary candidate toolset based on attribute parameters.

[0137] Module 404 is configured to determine the expected target assumptions in the use of assumptions.

[0138] The plan generation module 405 is configured to call the tool corresponding to the expected target assumption to generate the completion plan corresponding to the user task.

[0139] The hypothesis-verification-based intelligent agent tool invocation device provided in this disclosure acquires a user task, then obtains a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph, including the tools required for the user task. Next, it generates usage hypotheses for the tools in the preliminary candidate toolset based on the attribute parameters corresponding to the nodes in the preliminary candidate toolset. Then, it obtains the expected target hypothesis based on the usage hypothesis and invokes the tool corresponding to the expected target hypothesis to generate a completion plan for the user task. In this way, by first acquiring the preliminary candidate toolset required by the user task and then generating hypotheses for the tools within it, it is possible to simulate the functions corresponding to each task in the preliminary candidate toolset, thereby selecting the expected target hypothesis that meets the requirements of the user task. This improves the accuracy of the selected tools and thus increases the success rate of the generated completion plan.

[0140] Furthermore, the attribute parameters include static attributes and dynamic attributes; among them, static attributes include the name of the tool corresponding to the node, description text, structured parameter value definition, and category label; dynamic attributes include the confidence level, success profile, failure profile, and utility index corresponding to the tool; the edges of the tool capability graph are used to represent the relationships between tools.

[0141] Furthermore, the toolset acquisition module is configured to acquire a preliminary candidate toolset corresponding to a user task based on a preset tool capability graph in the following manner: perform intent parsing on the user task to obtain semantic features corresponding to the user task; determine one or more task categories corresponding to the user task based on the semantic features; filter out nodes that match the task category based on the category labels of each node in the tool capability graph; and merge the nodes corresponding to different task categories to obtain a preliminary candidate toolset corresponding to the task category.

[0142] Furthermore, the generation module is configured to generate usage hypotheses for tools in the preliminary candidate toolset as follows: obtain the parameter values ​​and expected goals of the tools in the preliminary candidate toolset based on the user task; and generate usage hypotheses for the tools in the preliminary candidate toolset based on the tools, parameter values, and expected goals in the preliminary candidate toolset according to a preset hypothesis document format.

[0143] Furthermore, the determination module is configured to determine the expected target hypothesis in the use hypothesis by: obtaining the hypothesis score corresponding to the use hypothesis; and determining the expected target hypothesis in the use hypothesis based on the hypothesis score.

[0144] Furthermore, the plan generation module is configured to generate completion plans for user tasks based on expected goal assumptions in the following manner: obtaining and determining the dependencies and conflicts between expected goal assumptions based on the tool capability graph; and generating completion plans for user tasks based on the dependencies and conflicts between expected goal assumptions.

[0145] Furthermore, the hypothesis-validation-based agent tool invocation device also includes a validation exploration module. The update module is configured to generate a completion plan corresponding to the user task based on the expected goal hypothesis, execute the completion plan, and obtain the execution result; update the attribute parameters of the node corresponding to the invoked tool according to the execution result; if the execution result is an execution failure, perform attribution analysis on the reasons for the failure of the completion plan to obtain the reasons for failure; and, based on the reasons for failure, initiate a preset exploration strategy to correct or regenerate the completion plan.

[0146] Combination Figure 5 As shown, this disclosure provides a hypothesis-verification-based agent tool invocation device, including a processor 501 and a memory 502. Optionally, the device may further include a communication interface 503 and a bus 504. The processor 501, communication interface 503, and memory 502 can communicate with each other via the bus 504. The communication interface 503 can be used for information transmission. The processor 501 can invoke logical instructions in the memory 502 to execute the hypothesis-verification-based agent tool invocation method of the above embodiment.

[0147] Furthermore, the logic instructions in the aforementioned memory 502 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0148] The memory 502, as a storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 501 executes functional applications and data processing by running the program instructions / modules stored in the memory 502, that is, it implements the hypothesis-verification-based intelligent agent tool invocation method in the above embodiments.

[0149] The memory 502 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 502 may include high-speed random access memory and may also include non-volatile memory.

[0150] This disclosure provides an electronic device including the hypothesis-verification-based intelligent agent tool invocation device described above.

[0151] This disclosure provides a storage medium storing computer-executable instructions configured to execute the hypothesis-verification-based agent tool invocation method described above.

[0152] The aforementioned storage media can be either transient computer-readable storage media or non-transitory computer-readable storage media. Non-transitory storage media include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and can also be transient storage media.

[0153] The foregoing description and accompanying drawings fully illustrate embodiments of this disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. Moreover, the terminology used in this application is for describing embodiments only and is not intended to limit the claims. As used in the description of embodiments and claims, the singular forms “a,” “an,” and “the” are intended to equally include the plural forms unless the context clearly indicates otherwise. Similarly, the term “and / or” as used in this application means including one or more of the associated listed items and all possible combinations thereof. Additionally, when used in this application, the term "comprise" and its variations "comprises" and / or "comprising" refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0154] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0155] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A hypothesis-validation-based intelligent agent tool invocation method, characterized in that, Applied to intelligent agents, the method includes: Obtain user tasks; A preliminary candidate toolset is obtained based on a preset tool capability graph; the tool capability graph has multiple nodes; each node represents a tool; the preliminary candidate toolset is a set of tools required by the user task; each node of the tool capability graph has its corresponding attribute parameters; Based on the attribute parameters, usage hypotheses are generated for the tools in the preliminary candidate toolset. Based on the aforementioned assumptions, obtain the expected target assumptions; The tool corresponding to the assumed expected goal is invoked to generate a completion plan for the user task.

2. The hypothesis-verification-based agent tool invocation method according to claim 1, characterized in that, The attribute parameters include static attributes and dynamic attributes; The static attributes include the name of the tool corresponding to the node, the description text, the structured parameter value definition, and the category label; The dynamic attributes include the confidence level, success profile, failure profile, and utility index corresponding to the tool. The edges of the tool capability graph are used to represent the relationships between tools.

3. The hypothesis-verification-based agent tool invocation method according to claim 2, characterized in that, The step of obtaining the preliminary candidate toolset corresponding to the user task based on the preset tool capability map includes: The user task is subjected to intent parsing to obtain the semantic features corresponding to the user task; Based on the semantic features, determine one or more task categories corresponding to the user task; Nodes matching the task category are selected based on the category labels of each node in the tool capability graph; For different task categories, the nodes corresponding to each task category are merged to obtain a preliminary candidate toolset for that task category.

4. The hypothesis-verification-based agent tool invocation method according to claim 1, characterized in that, The usage assumptions corresponding to the tools in the preliminary candidate toolset include: Based on the user task, obtain the parameter values ​​and expected goals corresponding to the tools in the preliminary candidate toolset; Based on the preset assumptions and the format of this paper, usage hypotheses corresponding to the tools in the preliminary candidate toolset are generated according to the tools in the preliminary candidate toolset, the parameter values, and the expected goals.

5. The hypothesis-verification-based agent tool invocation method according to claim 1, characterized in that, The determination of the expected target assumption in the usage assumptions includes: Obtain the hypothesis score corresponding to the hypothesis used; Based on the hypothesis score, the expected target hypothesis is determined from the usage hypothesis.

6. The hypothesis-verification-based agent tool invocation method according to claim 1, characterized in that, The step of generating the completion plan corresponding to the user task based on the expected goal assumption includes: Based on the tool capability map, determine the dependencies and conflicts between the expected target assumptions; The completion plan for the user task is generated based on the dependencies and conflicts between the assumed expected goals.

7. The hypothesis-verification-based agent tool invocation method according to any one of claims 1 to 6, characterized in that, After invoking the tool corresponding to the assumed expected goal to generate the completion plan for the user task, the method further includes: Execute the completion plan and obtain the execution results; Update the attribute parameters of the node corresponding to the invoked tool based on the execution result; If the execution result is an execution failure, an attribution analysis is performed on the reasons for the failure to complete the plan to obtain the reasons for the failure; Based on the stated reasons for failure, a preset exploration strategy is initiated to correct or regenerate the completion plan.

8. A hypothesis-validation-based intelligent agent tool invocation device, characterized in that, include: The task acquisition module is configured to acquire user tasks; The toolset acquisition module is configured to acquire a preliminary candidate toolset corresponding to the user task based on a preset tool capability graph; the tool capability graph has multiple nodes; each node represents a tool; the preliminary candidate toolset is a set of tools required by the user task; Each node in the tool capability graph has its corresponding attribute parameters; The hypothesis generation module is configured to generate usage hypotheses for the tools in the preliminary candidate toolset based on the attribute parameters. The determination module is configured to determine the expected target assumption among the usage assumptions; The plan generation module is configured to call the tool corresponding to the expected goal assumption to generate the completion plan corresponding to the user task.

9. A hypothesis-validation-based intelligent agent tool invocation device, comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to execute the hypothesis-verification-based agent tool invocation method as described in any one of claims 1 to 7 when running the program instructions.

10. An electronic device, characterized in that, Includes the hypothesis-verification-based agent tool invocation device as described in claim 8 or 9.

Images