Management method and device of agent tool chain, equipment and storage medium

Abstract

The invention relates to the technical field of artificial intelligence, can be applied to the medical field and the financial science and technology field, and discloses an agent tool chain management method and device, equipment and a storage medium, and the method comprises the steps: maintaining and dynamically updating a real-time reliability score for each tool in a tool set capable of being called by an agent; determining a target tool from the tool set based on the user query task instruction and reliability analysis; executing the task through the target tool to obtain an execution result; if the execution result is execution failure, obtaining an original error log and failure context information, and converting the original error log and the failure context information into semantic error description information; multi-path backtracking and re-planning operations are performed based on the semantic error description information to switch to an alternative tool and continue to execute the task. The reliability and task success rate of the intelligent agent tool chain are improved, the fault-tolerant capability is enhanced, and resource waste is reduced.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology and can be applied to the medical and financial technology fields. In particular, it relates to a management method, device, equipment and storage medium for an intelligent agent toolchain. Background Technology

[0002] With the rapid development of Large Language Model (LLM) technology, LLM-based agents have become an important technical means to automate complex tasks. By invoking a series of external tools or functions, such as database queries, API calls, data analysis, and report generation, agents greatly expand their capabilities, enabling them to execute various processes ranging from information integration to business decision-making. The application potential of agents is particularly significant in fintech and healthcare, two fields with extremely high requirements for accuracy, reliability, and timeliness.

[0003] In the fintech field, intelligent agents are widely used in scenarios such as real-time market data analysis, automated trading strategy execution, risk management assessment, compliance review, and robo-advisory. For example, an investment analysis agent may need to continuously call APIs from multiple data providers to obtain stock price information, call risk models to calculate the portfolio's VaR (Value at Risk), and finally call report generation services to output the analysis results. In the healthcare field, intelligent agents can assist in tasks such as clinical research data analysis, intelligent extraction and summarization of patient medical records, generation of medical image analysis reports, and personalized treatment plan recommendations.

[0004] However, existing intelligent agent platforms suffer from serious deficiencies in tool invocation and management, hindering their reliable implementation in the aforementioned key areas. First, tool selection is often haphazard. Current intelligent agents primarily select tools based on the semantic similarity between the tool's functional description and the user's instructions (usually achieved through RAG retrieval or Prompt matching), completely ignoring the tool's service quality and historical reliability. Second, existing systems lack robust error handling mechanisms. When a invoked tool fails (e.g., network timeout, permission errors, or returning abnormal data), existing intelligent agents typically only passively receive raw, lengthy error logs or stack traces and directly inject them into their own inference context. Third, existing processes exhibit rigid execution characteristics with no alternative paths. Once the tool invocation sequence is determined, the failure of a single tool often leads to the failure of the entire task chain. The system lacks the ability to automatically backtrack the execution state, find backup tools with similar or identical functions, and resume execution from the breakpoint upon failure. Summary of the Invention

[0005] The purpose of this application is to provide a management method, apparatus, device, and storage medium for intelligent agent toolchains, which has the advantages of improving the reliability and task success rate of intelligent agent toolchains, enhancing fault tolerance, and reducing resource waste.

[0006] To address the aforementioned technical problems, embodiments of this application provide a method for managing an intelligent agent toolchain, comprising: Maintain and dynamically update a real-time reliability score for each tool in the toolkit that the agent can invoke; Receive user query task instructions, and determine target tools from the toolset based on the user query task instructions and the reliability analysis; The task is executed using the target tool, and the execution result is obtained. If the execution result is an execution failure, the original error log and failure context information are obtained, and the original error log and failure context information are converted into semantic error description information; Based on the semantic error description information, perform multi-path backtracking and replanning operations to switch to an alternative tool and continue performing the task.

[0007] To address the aforementioned technical problems, embodiments of this application provide a management device for an intelligent agent toolchain, comprising: The reliability score maintenance module is used to maintain and dynamically update a real-time reliability score for each tool in the toolkit that the agent can invoke. The target tool determination module is used to receive user query task instructions and determine target tools from the toolset based on the user query task instructions and the reliability analysis. The target tool execution module is used to execute tasks through the target tool and obtain execution results; The description information conversion module is used to obtain the original error log and failure context information if the execution result is an execution failure, and convert the original error log and the failure context information into semantic error description information; The multi-path backtracking module is used to perform multi-path backtracking and replanning operations based on the semantic error description information, so as to switch to an alternative tool and continue to execute the task.

[0008] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is to provide a computer device, including one or more processors; and a memory for storing one or more programs, so that the one or more processors implement the management method of the intelligent agent toolchain described in any one of the above-mentioned methods.

[0009] To solve the above-mentioned technical problems, one technical solution adopted by the present invention is: a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the management method of the intelligent agent toolchain described in any one of the above-mentioned methods.

[0010] This invention provides a method, apparatus, device, and storage medium for managing an agent toolchain. The method includes: maintaining and dynamically updating a real-time reliability score for each tool in a toolset accessible to the agent; receiving a user query task instruction and determining a target tool from the toolset based on the user query task instruction and the reliability analysis; executing a task using the target tool and obtaining an execution result; if the execution result is a failure, obtaining the original error log and failure context information, and converting the original error log and failure context information into semantic error description information; and performing multi-path backtracking and replanning operations based on the semantic error description information to switch to an alternative tool and continue executing the task. This invention, by dynamically maintaining tool reliability scores and selecting tools based on them, and performing semantic error handling and backtracking replanning in case of failure, solves the problems of blind tool selection and weak error handling mentioned in the background art. It has the advantages of improving the reliability and task success rate of the agent toolchain, enhancing fault tolerance, and reducing resource waste. Attached Figure Description

[0011] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of an application environment for a management method of an intelligent agent toolchain according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the implementation of the management method for the intelligent agent toolchain provided in this application embodiment; Figure 3 yes Figure 2 A flowchart illustrating a specific implementation method of step S1; Figure 4 yes Figure 2 A flowchart illustrating a specific implementation method of step S2; Figure 5 yes Figure 2 A flowchart illustrating a specific implementation method following step S3; Figure 6 yes Figure 2A flowchart illustrating a specific implementation of step S4; Figure 7 yes Figure 2 A flowchart illustrating a specific implementation of step S5; Figure 8 yes Figure 2 A flowchart illustrating a specific implementation method following step S5; Figure 9 This is a schematic diagram of the management device for the intelligent agent toolchain provided in an embodiment of this application; Figure 10 This is a schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0013] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0014] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0015] This embodiment provides a method for managing an intelligent agent toolchain. Traditional intelligent agent development platforms have limitations in tool selection and execution. First, tool selection is often based on semantic relevance, ignoring tool quality and leading to blind selection. Second, when a tool call fails, existing intelligent agents lack robust error handling mechanisms, often directly terminating the task with an error or injecting raw and lengthy API error logs into the context, polluting the inference chain and unable to self-recover. Third, once the tool call order is determined in existing processes, failures can only be interrupted, lacking the ability to automatically find similar alternative tools and backtrack the execution state.

[0016] To address this, this application proposes a management method for an intelligent agent toolchain, comprising: maintaining and dynamically updating a real-time reliability score for each tool in a toolset that the intelligent agent can invoke; receiving a user query task instruction and determining a target tool from the toolset based on the user query task instruction and the reliability analysis; executing the task through the target tool and obtaining the execution result; if the execution result is an execution failure, obtaining the original error log and failure context information, and converting the original error log and failure context information into semantic error description information; and performing multi-path backtracking and replanning operations based on the semantic error description information to switch to an alternative tool and continue executing the task.

[0017] For ease of understanding, the following explains some key terms in this embodiment: The toolset that an intelligent agent can invoke: This refers to the collection of all external functions or service modules that an intelligent agent can access and invoke during task execution, such as database query interfaces, API interfaces, report generation tools, etc. These tools extend the capabilities of the intelligent agent.

[0018] Real-time reliability score: This refers to a numerical value that quantitatively evaluates the performance and stability of each tool in the toolset. The score reflects metrics such as availability, success rate, and response efficiency of the tool in the current or near-term context, and can be dynamically adjusted based on the actual operating conditions of the tool.

[0019] User-inquired task instructions: These are commands or requests issued by a user to an intelligent agent, instructing the agent to perform a specific task. These instructions typically include the task's objective, required information, or type of operation.

[0020] Reliability analysis refers to the process of evaluating and utilizing the real-time reliability score of a tool. Through reliability analysis, tools with stable performance and low failure rates can be identified, thus providing a basis for tool selection.

[0021] Target tool: refers to the specific tool selected from the toolset to perform the current task based on the user's query task instructions and reliability analysis.

[0022] Raw error logs: These are unprocessed error messages directly recorded by the system or the tool itself when a task fails. These logs typically contain technical details, stack traces, etc., and can be lengthy and difficult to understand directly.

[0023] Failure context information refers to the environmental and state data related to the failure event when the tool fails to execute a task. This may include the current progress of the task, input parameters, the internal state of the agent, etc., which helps to understand the specific circumstances when the failure occurred.

[0024] Semantic error description information refers to the processing of raw error logs and failure context information into concise error descriptions that are easier for humans or intelligent agents to understand and have clear semantics. These descriptions typically abstract away the underlying technical details, focusing on the cause and impact of the error.

[0025] Multi-path backtracking and replanning: This refers to a recovery strategy adopted by an agent system after a tool fails. This operation involves reverting the execution state to a previous stable point and re-evaluating and selecting alternative tools based on the failure information to attempt to complete the task through different paths.

[0026] Alternative tool: refers to another tool that is selected to replace the original target tool and continue the task after the target tool fails through multi-path backtracking and replanning operations.

[0027] This application effectively addresses the problems of blind tool selection, insufficient error handling, and lack of alternative execution paths in the agent toolchain by introducing real-time reliability scores, combining reliability analysis to determine target tools, and converting raw error information into semantic descriptions and performing multi-path backtracking and replanning upon failure. As a result, agents can more intelligently select high-quality tools when performing tasks and achieve automated error recovery and task continuation when encountering failures, significantly improving the success rate of enterprise-level agent tasks and the robustness of the system.

[0028] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0029] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0030] It should be noted that the management method of the intelligent agent toolchain provided in the embodiments of this application is generally executed by the server, and correspondingly, the management device of the intelligent agent toolchain is generally configured in the server.

[0031] The intelligent agent toolchain management method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can receive user query task instructions from the client and select tools and execute tasks accordingly. In this invention, the server sends a system operation report to the client. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0032] The management method for the intelligent agent toolchain provided in this application embodiment can be applied to automated investment research and report generation scenarios in the fintech field, or to clinical decision support and patient information integration scenarios in the healthcare field.

[0033] Please see Figure 2 , Figure 2 This illustrates one specific implementation of a management method for an intelligent agent toolchain.

[0034] It should be noted that if substantially the same result is obtained, the method of this invention is not based on... Figure 2 Limited to the order of the processes shown, this method includes the following steps: S1: Maintain and dynamically update a real-time reliability score for each tool in the toolkit that the agent can invoke.

[0035] In one implementation, each tool can be assigned an initial reliability score; for example, all new tools are assigned a medium score. Subsequently, each time a tool is invoked and completes execution, this score can be simply added or subtracted based on its execution result (success or failure). For example, a successful execution increases the score by a fixed value, while a failed execution decreases the score by a fixed value. In another implementation, the reliability scores of all tools can be updated periodically (e.g., at the end of each day), based on the ratio of the tool's total successful calls to its total failed calls over a past period.

[0036] Please see Figure 3 , Figure 3 A specific implementation of step S1 is shown below: S11: Collect historical execution data of each tool in the toolkit of the intelligent agent within a preset time window according to a preset period, wherein the historical execution data includes historical success rate and historical average response latency. S12: Calculate and update the reliability score of the tool based on the historical success rate and the historical average response latency according to a first preset formula.

[0037] Specifically, the phrase "collecting historical execution data of each tool in the agent's toolset within a preset time window according to a preset cycle" aims to ensure the dynamism and timeliness of the reliability score. The preset cycle refers to the time interval between data collection and score updates, which can be implemented in ways including but not limited to: setting a fixed time interval, such as performing data collection and score updates once per hour, day, or week; this approach is suitable for scenarios where tool performance changes are relatively stable; or using an event-triggered mechanism, such as triggering data collection and updates when a tool is called a preset number of times or when the system detects significant fluctuations in tool performance; this approach allows for more flexible responses to changes in tool status. The preset time window refers to the time range of data considered when collecting historical execution data, which can be implemented in ways including but not limited to: using a sliding time window, such as always collecting data from the past 24 hours, 7 days, or 30 days, with the window sliding forward as time progresses, old data being removed and new data being included; or using a fixed data volume window, such as always collecting data from the most recent 1000 calls or the most recent 500 successful calls, with the oldest data being replaced when the preset data volume is reached. Historical execution data are objective metrics used to evaluate tool performance. In addition to historical success rate and historical average response latency, they can also include historical error type distribution, historical resource consumption (such as CPU and memory), historical concurrent processing capacity, etc. This data can be obtained from the tool's call logs, system monitoring data, or dedicated performance metric collection services and stored in a structured format.

[0038] The "historical success rate" refers to the proportion of times the tool successfully executes a task within a preset time window out of the total number of calls. It is a direct indicator of the tool's reliability. It can be calculated by dividing the number of successful calls by the total number of calls, and "success" can be defined based on different error levels; for example, HTTP status codes 2xx are considered successes, and others are considered failures. The "historical average response latency" refers to the average time the tool takes to respond to user requests within a preset time window, and it is a key indicator of the tool's efficiency and performance. It can be calculated by dividing the sum of all successful call response times by the number of successful calls, and "latency" can be defined based on different Service Level Agreements (SLAs); for example, response times exceeding a certain threshold are considered high latency.

[0039] The phrase "calculating and updating the tool's reliability score based on historical success rate and historical average response latency according to the first preset formula" aims to comprehensively quantify multi-dimensional indicators into a single reliability score. The first preset formula ensures the objectivity and consistency of the score calculation; alternatively, a multi-factor scoring model can be used, which, in addition to success rate and response latency, can introduce other factors such as error rate, resource utilization, and stability indicators, and combine them through more complex functions (such as the sigmoid function and exponential decay function) to generate a more comprehensive reliability score.

[0040] Furthermore, the first preset formula is: in, It is the historical success rate; This is the historical average response time; and These are the weighting coefficients; It is a reliability score.

[0041] This application provides a specific and dynamic mechanism for calculating and updating the real-time reliability scores of each tool in an agent toolchain. By collecting historical execution data according to a preset cycle and time window, and combining it with two key indicators—historical success rate and historical average response latency—it ensures that the collected data is up-to-date and representative, thus avoiding inaccurate scores due to outdated or incomplete data. Furthermore, by quantifying these multi-dimensional data using a first preset formula, the reliability score generation process becomes objective, consistent, and quantifiable, accurately reflecting the actual operational quality and performance of the tools. This allows the agent to consider not only semantic relevance but also the actual "quality" of the tools when selecting them, significantly improving the accuracy of tool selection and the success rate of task execution. It effectively solves the problems of blind tool selection and the inability to distinguish between tools with similar functions but large quality differences in existing technologies, laying a solid foundation for the robust operation of the agent toolchain.

[0042] S2: Receive user query task instructions, and determine target tools from the toolset based on the user query task instructions and the reliability analysis.

[0043] Specifically, when receiving a task instruction from a user, the system can first perform preliminary parsing of the instruction to extract keywords or intents related to the task. Then, the system can iterate through all tools in the toolset, performing simple text matching between these keywords and the description of each tool to identify candidate tools that may be relevant to the task. From these candidate tools, a tool can be selected as the target tool based on preset priority rules (e.g., a manually configured tool priority list) or randomly.

[0044] Please see Figure 4 , Figure 4 A specific implementation of step S2 is shown below: S21: Receive the user query task instruction and calculate the semantic similarity between the query statement in the user query task instruction and the descriptions of each tool in the toolset. S22: Calculate a comprehensive score for each tool based on the semantic similarity and the real-time reliability score of the corresponding tool. S23: Select the tool with the highest comprehensive score as the target tool.

[0045] Specifically, after receiving the user's query task instruction, it is necessary to calculate the semantic similarity between the query statement in the user's query task instruction and the descriptions of each tool in the toolset. This step aims to quantify the relevance between user needs and tool functions, ensuring that the tools are highly compatible with the task at the functional level, thereby avoiding the misselection of irrelevant tools. For example, natural language processing (NLP) techniques can be used, such as word embedding models (e.g., Word2Vec, GloVe) or pre-trained language models (e.g., BERT, GPT series) to convert the query statement and tool descriptions into vector representations, and then the cosine similarity between these vectors can be calculated as the semantic similarity. Alternatively, deep learning models, such as the Siamese Network, can be used to train a model to directly evaluate the degree of semantic matching between the query statement and the tool description.

[0046] Based on this, a comprehensive score is calculated for each tool based on the semantic similarity and the corresponding tool's real-time reliability score. This step aims to dynamically integrate task suitability metrics (semantic similarity) with tool quality metrics (real-time reliability score), overcoming the one-sidedness caused by relying solely on semantics or reliability, and achieving a balanced optimization of tool selection. Typically, the comprehensive score can be calculated using a weighted average, for example: `Comprehensive Score = w1 * Semantic Similarity + w2 * Real-time Reliability Score`, where w1 and w2 are preset weights, and w1 + w2 = 1. These weights can be adjusted according to actual application scenarios and strategies. Furthermore, a nonlinear function or machine learning model can also be used to calculate the comprehensive score. By training a classifier or regressor, taking semantic similarity and real-time reliability score as input, and outputting a comprehensive score, this model can learn more complex interaction relationships.

[0047] Finally, the tool with the highest overall score is selected as the target tool. This step uses objective scoring criteria to select the optimal option, ensuring that the selected tool meets both the task's semantic requirements and has high reliability. Typically, after calculating the overall score for all tools, the system directly iterates through all scores and selects the tool corresponding to the score with the highest value. Alternatively, all tools can be sorted in descending order of their overall scores, and then the first tool in the sorted list can be selected.

[0048] This application introduces semantic similarity calculation into its intelligent agent toolchain management method, ensuring a high degree of semantic matching between the selected tools and the user's query task instructions, thus avoiding tool selection bias caused by semantic irrelevance. Simultaneously, it combines semantic similarity with real-time reliability scores to calculate a comprehensive score, ensuring that tool selection considers not only functional relevance but also the actual operational quality and stability of the tools. This comprehensive consideration mechanism effectively solves the one-sidedness problem caused by relying solely on reliability scores or semantic relevance, thereby enabling more accurate and robust selection of target tools, significantly improving the accuracy and success rate of intelligent agents in task execution, and optimizing the overall management efficiency of the intelligent agent toolchain.

[0049] S3: Execute the task using the target tool to obtain the execution result.

[0050] Specifically, once the target tool is identified, the agent will invoke the tool and pass the necessary parameters to execute the task. After execution, the system will receive the execution result returned by the tool, which may indicate that the task was successfully completed or that the task failed.

[0051] Please see Figure 5 , Figure 5 A specific implementation method following step S3 is shown below: S31: Update the current historical execution data of the target tool based on the execution result, wherein the current historical execution data includes the cumulative number of successful calls, the total number of calls, and delay records. S32: Based on the updated current historical execution data, trigger a recalculation of the reliability score of the target tool.

[0052] Specifically, after the agent executes a task through the target tool and obtains the execution result, the system immediately updates the current historical execution data of the target tool based on the execution result. This step aims to ensure that the tool's performance data can reflect its latest operating status in a timely manner. Regardless of whether the task execution is successful or fails, its result is immediately captured and used to update the tool's historical performance record. One implementation is that after each tool call, a data collection agent or service listens for the execution result and directly writes the result to persistent storage associated with the tool, such as a tool performance table in a database or a distributed cache. Another implementation is that after the tool execution module completes the task, it publishes an event containing the execution result to an event bus, and a dedicated data processing module subscribes to the event and is responsible for updating the corresponding historical execution data.

[0053] The current historical execution data includes the cumulative number of successful calls, the total number of calls, and latency records. These data items are key indicators for evaluating the reliability of the tool. The "cumulative number of successful calls" records the total number of times the tool has successfully completed tasks since its inception, used to calculate the success rate. The "total number of calls" records the total number of times the tool has been called, including both successful and failed calls, and together with the cumulative number of successful calls, forms the basis for calculating the success rate. The "latency records" record the response time or processing duration of each tool call, which can be used to calculate the average response latency, median latency, or latency distribution to evaluate the tool's response performance. In practice, this data can be stored as counters (such as cumulative number of successful calls and total number of calls) and time-series data (such as latency records). For example, a record containing these fields can be maintained for each tool in a database and atomically updated after each execution.

[0054] Subsequently, based on the updated historical execution data, the system triggers a recalculation of the reliability score for the target tool. This step ensures that the reliability score is evaluated based on the latest performance data, thus avoiding inaccurate scores due to data lag. One triggering method is to immediately and synchronously call the reliability score calculation module after the historical execution data update is complete, and recalculate the tool's reliability score using the updated data. Another triggering method is that after the data update operation is complete, the system sends a trigger signal or message to the reliability score service. Upon receiving the signal, the service asynchronously reads the latest historical execution data from the data storage and recalculates according to a preset reliability score calculation formula.

[0055] S4: If the execution result is an execution failure, then obtain the original error log and failure context information, and convert the original error log and failure context information into semantic error description information.

[0056] Specifically, when a target tool fails, the system captures raw error logs generated by the tool or underlying system, such as API error codes and exception stack traces. Simultaneously, the system collects contextual information related to the failure, such as the task's input parameters and the agent's internal state before invoking the tool. These raw error logs and failure contextual information are then fed into a predefined rules engine containing a series of predefined pattern matching rules. Using these rules, the system can extract key error type identifiers from the lengthy raw logs and, combined with the contextual information, generate a concise and easily understood error description. For example, if the log contains the word "Timeout," a semantic description of "tool call timed out" can be generated.

[0057] Please see Figure 6 , Figure 6 A specific implementation of step S4 is shown below: S41: If the execution result is an execution failure, then obtain the original error log and the failure context information. S42: Input the original error log and the task failure context information into the error summary agent. S43: Analyze and process the original error log and the task failure context information through the error summary agent to generate the semantic error description information.

[0058] Specifically, if the execution result is failure, the system retrieves the original error log and failure context information. This aims to ensure that when an agent fails to execute a task using a tool, the system can comprehensively and accurately capture all the original data and environmental information that led to the failure. This includes detailed error information extracted from the tool's output stream, system log file, and API response body, as well as context data such as the current task's execution status, call parameters, environment variables, and call stack. For example, after detecting a tool execution failure, the system can automatically extract the original error log from the tool's output stream, system log file, or API response, and collect failure context information from the current task's execution status, call parameters, and environment variables. Alternatively, by setting an exception capture mechanism at the tool's call interface, once an exception is captured, the logging module is immediately triggered, storing the exception stack information, error code, and error message as the original error log, and saving the current task's input, output, intermediate variables, and call chain information as failure context information.

[0059] Subsequently, the raw error logs and the task failure context information are input into the error summarization agent. The purpose of this step is to provide raw, verbose, and potentially unstructured error information as input to a dedicated agent for processing, thus isolating the error handling logic and preventing direct contamination of the main agent's inference context. For example, the collected raw error logs and failure context information can be encapsulated into structured data packets (such as JSON format) and sent to a separate error summarization agent service via API calls or message queue mechanisms. Alternatively, within the agent toolchain management system, a dedicated error handling module can be designed. This module receives the raw error information and passes it as input parameters to a pre-loaded or dynamically loaded error summarization agent model.

[0060] Based on this, the error summarizing agent analyzes and processes the original error log and the task failure context information to generate the semantic error description information. Leveraging its powerful analytical capabilities, the error summarizing agent extracts key semantics from complex raw information, generating concise, understandable, and structured error descriptions, providing a valid basis for subsequent error recovery and replanning. For example, the error summarizing agent can be a module based on a Large Language Model (LLM). This module receives the original error log and failure context information as prompt input, and through its natural language understanding and generation capabilities, extracts key information such as error type, error cause, and scope of impact, outputting a semantic error description in a predefined structured format (such as JSON or XML). Alternatively, the error summarizing agent can be a hybrid system combining a rule engine and a machine learning model. The rule engine identifies common error patterns and keywords, extracting standardized error codes and messages; the machine learning model (such as a text classification or sequence labeling model) performs semantic analysis on unstructured text, identifying error entities, actions, and attributes, ultimately integrating them to generate semantic error description information.

[0061] This application solves the problem of context pollution caused by the verbosity and unstructured nature of the original information by converting raw error logs and failure context information into semantic error descriptions through an error summarization agent. Specifically, when a task fails, the original error log and failure context information are obtained, ensuring that all critical error data is captured completely and providing necessary input for subsequent transformation. The original error log and task failure context information are input into the error summarization agent, avoiding the direct use of raw data and instead using the analytical capabilities of a specialized agent to isolate error processing and prevent pollution of the inference chain. The error summarization agent analyzes and processes the original error log and task failure context information to generate semantic error descriptions. The core of this step is that the error summarization agent can parse complex logs and contexts, extract semantic cores, and generate concise and understandable structured descriptions, thereby supporting efficient backtracking and replanning operations and improving the accuracy of error recovery and resource utilization.

[0062] S5: Perform multi-path backtracking and replanning operations based on the semantic error description information to switch to an alternative tool and continue executing the task.

[0063] Specifically, after obtaining semantic error description information, the system can simply mark the current task as failed and attempt to randomly select a tool with similar functionality to the original target tool from the toolset as a replacement. The system can then try to re-execute the task using this replacement tool, which may require manual intervention to adjust the invocation parameters. In another implementation, the system can maintain a predefined list of replacement tools; when a tool fails, it tries the next replacement tool in the list in order, until the task succeeds or the list is exhausted.

[0064] Please see Figure 7 , Figure 7 A specific implementation of step S5 is shown below: S51: Roll back the execution state of the agent to the checkpoint state after the last successful tool call. S52: Based on the checkpoint state and the semantic error description information, exclude failed target tools from the toolset and re-select a set of candidate tools with matching functionality. S53: Select the tool with the highest real-time reliability score from the candidate toolset as the replacement tool. S54: Use the replacement tool to correct the call parameters based on the semantic error description information and re-execute the task.

[0065] Specifically, rolling back the agent's execution state to the checkpoint state after the last successful tool invocation aims to restore the system to a known and correct historical state—that is, the state after the most recent successful tool execution. This avoids continuing to operate in an uncertain or erroneous state after an error occurs, thus ensuring that the starting point for subsequent recovery operations is reliable. For example, this can be achieved by maintaining an execution state stack. After each successful tool invocation, key information such as the current system context, intermediate results, and task progress is pushed onto the stack as a checkpoint; when a failure occurs, the most recent successful checkpoint state is popped from the stack for recovery. Another implementation approach is for the system to periodically or after critical operations serialize and store the complete execution context as a snapshot. When a rollback is needed, the most recent successful snapshot is loaded to reconstruct the execution environment.

[0066] Based on this, according to the checkpoint status and the semantic error description information, failed target tools are excluded from the toolset, and a new set of candidate tools matching the functionality is selected. This step utilizes the contextual information at the time of failure and a semantic understanding of the error cause to intelligently identify and remove the tool that caused the failure, while efficiently finding other tools that can replace its functionality. For example, the system can maintain a blacklist of tools for the current task; once a tool fails, it is added to the blacklist and automatically excluded in subsequent tool selection processes. When selecting a set of candidate tools matching the functionality, Natural Language Processing (NLP) technology can be used to perform semantic similarity matching between the semantic error description information and the functional descriptions of each tool in the toolset, or the original task intent recorded in the checkpoint status can be combined to query tools with similar functional tags or API interfaces from the tool registry. For example, if the semantic error description information indicates "database connection failed," the system will exclude the currently failed database tool and look for other tools that can be used for "data query" or "data storage."

[0067] Subsequently, the tool with the highest real-time reliability score is selected from the candidate tool set as the alternative tool, ensuring that the most stable and reliable tool is prioritized among numerous functionally compatible alternatives. This significantly reduces the risk of further failures and improves the success rate of task recovery. Specifically, the system queries the currently maintained real-time reliability score of each candidate tool, which comprehensively reflects the tool's historical success rate, response latency, and other performance indicators. Then, the system selects the tool with the highest score as the preferred alternative. Alternatively, a weighted selection strategy can be adopted, considering other factors such as tool invocation cost and specific functional compatibility in addition to the reliability score, but the reliability score remains the most important consideration.

[0068] Finally, re-executing the task using the alternative tool based on the semantic error description information to correct the calling parameters is crucial to ensuring the successful execution of the alternative tool. It leverages a semantic understanding of the error cause to intelligently adjust or transform the original calling parameters to suit the interface requirements of the alternative tool and resolve potential parameter issues that led to previous failures. For example, if the semantic error description indicates "incorrect input date format," the system can convert the original date parameter from "YYYY-MM-DD" to "MM / DD / YYYY" format according to the alternative tool's API documentation or preset parameter conversion rules. Alternatively, if the error is "missing authentication token," the system can attempt to supplement or update the authentication information for the alternative tool. This parameter correction process can be performed by a parameter correction agent that combines the semantic error description information, the original parameters in the checkpoint state, and the interface specifications of the alternative tool to generate new calling parameters.

[0069] This application provides an efficient and robust multi-path backtracking and replanning mechanism for recovering from tool execution failures in intelligent agent toolchain management. First, by precisely rolling back the agent's execution state to the checkpoint state after the last successful tool call, it ensures that the starting point for task recovery is stable and reliable, avoiding the accumulation and propagation of error states, thus saving unnecessary computational resources and providing a clear context for subsequent intelligent decisions. Second, by combining checkpoint states and semantic error descriptions, the system can intelligently exclude failed target tools from the toolset, avoiding repeated attempts at known failed paths and efficiently filtering out a set of functionally matching candidate tools, greatly narrowing the search range for alternative tools and improving selection efficiency. Furthermore, by prioritizing the tool with the highest real-time reliability score as the alternative tool, this application ensures that the optimal and most stable path is always selected during the recovery process, significantly reducing the risk of further failures and enhancing the overall reliability of the task. Finally, semantic error description information is used to intelligently correct the calling parameters, enabling the alternative tool to adjust its parameters according to the specific error cause and its own interface requirements to adapt to the new execution environment. This ensures that the task can be successfully re-executed, greatly improving the success rate of task recovery and the self-healing ability of the agent. Overall, this application achieves closed-loop optimization from error identification, state backtracking, intelligent selection to parameter correction through step-by-step synergy, significantly improving the robustness of the agent in complex task environments and the task success rate.

[0070] Please see Figure 8 , Figure 8 A specific implementation method following step S5 is shown below: S5A: Continuously collect and statistically analyze the execution metrics throughout the entire process, including the overall task success rate, average tool reliability score, backtracking trigger frequency, and backtracking success rate. S5B: Determine if any of the execution metrics fall below a preset threshold; if so, generate an alarm message. S5C: Generate a system operation report based on the execution metrics and the alarm message.

[0071] Specifically, continuous collection and statistical analysis of execution metrics throughout the entire process aims to comprehensively understand the operational status of the intelligent agent toolchain. These execution metrics include overall task success rate, average tool reliability score, backtracking trigger frequency, and backtracking success rate. The overall task success rate reflects the system's overall efficiency in completing user query commands; the average tool reliability score comprehensively evaluates the stability and availability of all tools in the toolset; the backtracking trigger frequency indicates the system's activity level in error handling and path switching; and the backtracking success rate measures the effectiveness of multi-path backtracking and replanning operations. This process can be achieved in various ways. For example, the system can have a built-in data acquisition module that records relevant data in real time each time a tool is called, a task succeeds or fails, or a backtracking operation occurs, such as timestamps, tool IDs, call results, response latency, and backtracking event types. This raw data is then transmitted to a metric calculation engine, which aggregates and calculates the data at fixed time intervals (e.g., every minute, every hour, or every day) according to preset statistical rules to derive the current values ​​of each execution metric. Another approach is for the system to use a distributed logging system (such as the ELK Stack) to collect all operation logs, extract key information through a log parser, and then have a dedicated metrics service process this information in real time or near real time to generate and update various performance metrics.

[0072] Based on this, it is determined whether any of the execution metrics fall below a preset threshold. If so, an alarm message is generated. This step aims to identify potential system problems or performance bottlenecks through an automated mechanism. The preset threshold is a performance baseline set for each execution metric. For example, it can be set that the overall task success rate is not less than 95%, the average tool reliability score is not less than 0.8, the backtracking trigger frequency does not exceed 10 times / hour, and the backtracking success rate is not less than 90%. When the current value of any execution metric deviates from its preset threshold (e.g., the success rate is lower than the threshold, or the triggering frequency is higher than the threshold), the system determines that an anomaly exists. To implement this judgment and alarm mechanism, a monitoring agent can be configured. This agent periodically (e.g., every 5 minutes) retrieves the latest execution metric data from the metric calculation engine and compares it with the pre-stored thresholds. Once a metric is found to be out of bounds, the monitoring agent immediately triggers the alarm generation module to generate an alarm message containing detailed information such as the specific metric name, current value, threshold, and abnormal time. Alarm information can be sent in various forms, such as by emailing system administrators, sending SMS messages to maintenance personnel's mobile phones, or integrating into the enterprise's existing alarm platform (such as Prometheus or Grafana) for timely response.

[0073] Furthermore, a system operation report is generated based on the performance metrics and alarm information. This step aims to provide system administrators with a comprehensive and structured overview of the operational status and to provide data support for long-term system optimization and decision-making. The system operation report typically includes trend charts and statistical summaries of various performance metrics over a period of time (e.g., one day, one week, or one month), as well as a list of all triggered alarm events and their detailed information. For example, the report can show a curve of the overall task success rate over time, highlighting periods of declining success rates; it can also list tools with low reliability scores and their historical alarm records. To achieve report generation, a report generator module can be developed, which can extract data from a historical metrics database and alarm event logs, and format and visualize the data according to a preset report template. Reports can be automatically generated periodically and distributed to relevant users via email attachments, internal web interfaces, or API interfaces.

[0074] This application embodiment can be applied to the scenario of automated investment research and report generation in the field of financial technology. The scenario is described as follows: A fund manager of an investment institution needs to automatically generate an investment morning report for a specific industry through an intelligent agent before the market opens every day. This task requires the intelligent agent to complete the following in sequence: (1) obtain real-time stock price and financial report data from multiple data providers; (2) call the macroeconomic indicator API; (3) perform calculations using an internal quantitative risk model; and (4) integrate information and generate a structured report.

[0075] The specific process of this scenario is as follows: The input is a user query for "Generate today's new energy sector investment morning report". The system filters out multiple stock price data APIs that meet the criteria (such as suppliers A, B, and C). Although supplier A's API has a high degree of functional description matching, its real-time reliability score R is low (delays have been frequent recently). Supplier B's API has similar functions and the highest R value. The system prioritizes supplier B's API as the data acquisition tool, ensuring the stability of the task foundation from the source. Then, the task is executed through this tool. If the execution fails, the original error log and failure context information are obtained. After analysis by the error summary agent, a semantic description is generated: "Error: Risk calculation service is temporarily overloaded and unavailable. It is expected to recover in 1-2 minutes. It is recommended to retry later or switch to simplified calculation mode." Finally, the system execution status is traced back to the previous step (data acquisition completed). Subsequently, an alternative solution is searched in the toolset, and a simplified version of the risk indicator calculator with faster calculation speed and higher reliability score is found.

[0076] In the fast-paced financial market, this application ensures a high success rate and timeliness of critical investment analysis tasks by selecting the most stable data sources, intelligently understanding and absorbing service failures, and seamlessly switching to backup solutions when core tools fail, directly supporting the continuity and reliability of investment decisions.

[0077] The embodiments of this application can be applied to clinical decision support and patient information integration scenarios in the medical and health field. The scenario is described as follows: When a clinician is dealing with a patient with a complex medical history, he activates a clinical decision support agent through a voice assistant. The agent needs to: (1) query the patient's electronic health record (EHR) from multiple in-hospital and regional medical information platforms; (2) call the latest medical literature guideline API; (3) use a drug interaction examination model; and (4) provide comprehensive diagnostic suggestions and treatment recommendations.

[0078] The specific implementation process in this scenario is as follows: The input is the doctor's instruction to "retrieve the complete medical history of patient [Zhang San] and evaluate the current medication regimen." The system identifies two tools that can query the EHR: the hospital's core database interface and the regional medical information platform interface. Due to cross-institutional network issues, the latter has a historically low success rate and high latency, so its R value is much lower than that of the former. The system prioritizes calling the hospital's core database interface to obtain the main medical history. Only when supplementary information is needed and the internal query fails, will the system cautiously consider calling the backup interface with a low R value, minimizing long wait times or failures caused by external system instability. Then, the task is executed through this interface. If the execution fails, the system obtains the original error log and failure context information. After analysis by the error summary agent, a semantic description is generated, which reads: "Warning: The patient's medication record is being locked and updated by the pharmacy system, and a security check cannot be performed temporarily. It is recommended to wait 30 seconds and retry, or perform an evaluation based on the existing known medical history first." Finally, the system reverts to the state after obtaining the patient's medical history. Subsequently, another general medical knowledge graph API with similar disease coverage and a higher reliability score was selected from the knowledge toolset as an alternative.

[0079] In life-or-death medical settings, this application significantly enhances the robustness and usability of clinical support agents by proactively avoiding unreliable data interfaces, transforming technical errors into clinically understandable alerts, and activating alternative solutions when critical knowledge tools fail. It ensures that when doctors need information support most, the system can provide continuous and available services with the highest probability, assisting rather than interrupting the clinical thought process.

[0080] Please refer to Figure 9 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a management device for an intelligent agent toolchain, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0081] like Figure 9 As shown, the management device for the intelligent agent toolchain in this embodiment includes: a reliability score maintenance module 61, a target tool determination module 62, a target tool execution module 63, a description information conversion module 64, and a multi-path backtracking module 65, wherein: The reliability score maintenance module 61 is used to maintain and dynamically update a real-time reliability score for each tool in the tool set that the agent can invoke; The target tool determination module 62 is used to receive a user query task instruction and determine a target tool from the toolset based on the user query task instruction and the reliability analysis. The target tool execution module 63 is used to execute tasks through the target tool and obtain execution results; The description information conversion module 64 is used to obtain the original error log and failure context information if the execution result is execution failure, and convert the original error log and the failure context information into semantic error description information; The multi-path backtracking module 65 is used to perform multi-path backtracking and replanning operations based on the semantic error description information, so as to switch to an alternative tool and continue to perform the task.

[0082] Furthermore, the reliability score maintenance module 61 includes: The historical execution data acquisition unit is used to collect historical execution data of each tool in the tool set of the intelligent agent within a preset time window according to a preset period. The historical execution data includes historical success rate and historical average response latency. The reliability score update unit is used to calculate and update the reliability score of the tool based on the historical success rate and the historical average response delay according to a first preset formula.

[0083] Furthermore, the target tool determination module 62 includes: A semantic similarity calculation unit is used to receive the user query task instruction and calculate the semantic similarity between the query statement in the user query task instruction and the descriptions of each tool in the toolset; A comprehensive scoring calculation unit is used to calculate a comprehensive score for each of the tools based on the semantic similarity and the real-time reliability score of the corresponding tool; The target tool selection unit is used to select the tool corresponding to the highest value in the comprehensive score as the target tool.

[0084] Furthermore, the description information conversion module 64 includes: The original error log acquisition unit is used to acquire the original error log and the failure context information if the execution result is an execution failure. A data input unit is used to input the original error log and the task failure context information into the error summary agent; The semantic error description information generation unit is used to analyze and process the original error log and the task failure context information through the error summary agent to generate the semantic error description information.

[0085] Furthermore, the multi-path backtracking module 65 includes: The state rollback unit is used to roll back the execution state of the agent to the checkpoint state after the last successful tool call; A semantic error description information filtering unit is used to exclude failed target tools from the toolset based on the checkpoint status and the semantic error description information, and to re-filter out a set of candidate tools that match the function. An alternative tool selection unit is used to select the tool with the highest real-time reliability score from the candidate tool set as the alternative tool; The parameter correction unit is used to correct the call parameters based on the semantic error description information using the alternative tool, and then re-execute the task.

[0086] Furthermore, the target tool execution module 63 also includes: The current historical execution data update module is used to update the current historical execution data of the target tool based on the execution result, wherein the current historical execution data includes the cumulative number of successful calls, the total number of calls, and delay records; The reliability score recalculation module is used to trigger a recalculation of the reliability score of the target tool based on the updated current historical execution data.

[0087] Furthermore, the multi-path backtracking module 65 also includes: The execution metrics statistics module is used to continuously collect and statistically analyze the execution metrics of the entire process. The execution metrics include the overall task success rate, the average reliability score of the tool, the backtracking trigger frequency, and the backtracking success rate. The alarm information generation module is used to determine whether there are any indicators among the execution indicators that are lower than a preset threshold. If so, an alarm information is generated. The system operation report generation module is used to generate a system operation report based on the execution indicators and the alarm information.

[0088] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been obtained by authorized entities (who have known and consented) or fully authorized by all parties through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0089] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed] for details. Figure 10 , Figure 10 This is a basic structural block diagram of the computer device in this embodiment.

[0090] Computer device 7 includes a memory 71, a processor 72, and a network interface 73 that are interconnected via a system bus. It should be noted that... Figure 10 Only a computer device 7 with three components—memory 71, processor 72, and network interface 73—is shown. It should be understood that implementing all shown components is not required; more or fewer components may be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and embedded devices.

[0091] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0092] The memory 71 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 71 may be an internal storage unit of the computer device 7, such as the hard disk or memory of the computer device 7. In other embodiments, the memory 71 may also be an external storage device of the computer device 7, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 7. Of course, the memory 71 may include both internal storage units and external storage devices of the computer device 7. In this embodiment, the memory 71 is typically used to store the operating system and various application software installed on the computer device 7, such as program code for management methods of intelligent agent toolchains. In addition, the memory 71 may also be used to temporarily store various types of data that have been output or will be output.

[0093] In some embodiments, processor 72 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. This processor 72 is typically used to control the overall operation of computer device 7. In this embodiment, processor 72 is used to run program code stored in memory 71 or process data, for example, to run the program code of the above-described intelligent agent toolchain management method to implement various embodiments of the intelligent agent toolchain management method.

[0094] The network interface 73 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 7 and other electronic devices.

[0095] This application also provides another embodiment, namely, providing a computer-readable storage medium storing a computer program that can be executed by at least one processor to cause the at least one processor to perform the steps of the management method of an intelligent agent toolchain as described above.

[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0097] Obviously, the embodiments described above are merely some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the scope of this application. This application can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of protection of this application.

Claims

1. A method for managing an intelligent agent toolchain, characterized in that, include: Maintain and dynamically update a real-time reliability score for each tool in the toolkit that the agent can invoke; Receive user query task instructions, and determine target tools from the toolset based on the user query task instructions and the reliability analysis; The task is executed using the target tool, and the execution result is obtained. If the execution result is an execution failure, the original error log and failure context information are obtained, and the original error log and failure context information are converted into semantic error description information; Based on the semantic error description information, perform multi-path backtracking and replanning operations to switch to an alternative tool and continue performing the task.

2. The management method for the intelligent agent toolchain according to claim 1, characterized in that, The aforementioned method maintains and dynamically updates a real-time reliability score for each tool in the toolset that the agent can invoke, including: Historical execution data of each tool in the toolset of the intelligent agent within a preset time window are collected according to a preset period, wherein the historical execution data includes historical success rate and historical average response latency; The reliability score of the tool is calculated and updated based on the historical success rate and the historical average response delay according to the first preset formula.

3. The management method for the intelligent agent toolchain according to claim 1, characterized in that, The step of receiving a user query task instruction and determining a target tool from the toolset based on the user query task instruction and the reliability analysis includes: Receive the user query task instruction and calculate the semantic similarity between the query statement in the user query task instruction and the descriptions of each tool in the toolset; A comprehensive score is calculated for each tool based on the semantic similarity and the real-time reliability score of the corresponding tool. The tool corresponding to the highest value in the comprehensive score is selected as the target tool.

4. The management method for the intelligent agent toolchain according to claim 1, characterized in that, If the execution result is an execution failure, then the original error log and failure context information are obtained, and the original error log and failure context information are converted into semantic error description information, including: If the execution result is an execution failure, then obtain the original error log and the failure context information; The original error log and the task failure context information are input into the error summary agent; The error summary agent analyzes and processes the original error log and the task failure context information to generate the semantic error description information.

5. The management method for the intelligent agent toolchain according to claim 1, characterized in that, The step of performing multi-path backtracking and replanning operations based on the semantic error description information to switch to an alternative tool and continue executing the task includes: Roll back the execution state of the agent to the checkpoint state after the last successful tool call; Based on the checkpoint status and the semantic error description information, the failed target tools are excluded from the toolset, and a new set of candidate tools with matching functions is selected. The tool with the highest real-time reliability score is selected from the candidate toolset as the alternative tool. The alternative tool is used to correct the calling parameters based on the semantic error description information, and the task is re-executed.

6. The management method for the intelligent agent toolchain according to any one of claims 1 to 5, characterized in that, After executing the task through the target tool and obtaining the execution result, the method further includes: The current historical execution data of the target tool is updated based on the execution results, wherein the current historical execution data includes the cumulative number of successful calls, the total number of calls, and delay records; Based on the updated current historical execution data, a recalculation of the reliability score of the target tool is triggered.

7. The management method for the intelligent agent toolchain according to any one of claims 1 to 5, characterized in that, After performing multi-path backtracking and replanning operations based on the semantic error description information to switch to an alternative tool and continue executing the task, the method further includes: Continuously collect and analyze the execution metrics of the entire process, including the overall task success rate, the average reliability score of the tool, the backtracking trigger frequency, and the backtracking success rate. Determine whether any of the execution metrics are below a preset threshold; if so, generate an alarm message. A system operation report is generated based on the performance indicators and alarm information.

8. A management device for an intelligent agent toolchain, characterized in that, include: The reliability score maintenance module is used to maintain and dynamically update a real-time reliability score for each tool in the toolkit that the agent can invoke. The target tool determination module is used to receive user query task instructions and determine target tools from the toolset based on the user query task instructions and the reliability analysis. The target tool execution module is used to execute tasks through the target tool and obtain execution results; The description information conversion module is used to obtain the original error log and failure context information if the execution result is execution failure, and convert the original error log and the failure context information into semantic error description information; The multi-path backtracking module is used to perform multi-path backtracking and replanning operations based on the semantic error description information, so as to switch to an alternative tool and continue to execute the task.

9. A computer device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the management method of the intelligent agent toolchain as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the management method of the intelligent agent toolchain as described in any one of claims 1 to 7.

Images