An external service call exception repair method and related device

Abstract

The application discloses an external service call exception repair method and related device, and relates to the field of computers, which comprises the following steps: when an execution agent receives a call failure prompt information returned by an external tool, obtaining a request parameter set when the execution agent calls the external tool, constructing a plurality of shadow requests in orthogonality for the request parameter set, testing the external tool based on the plurality of shadow requests, obtaining a response result returned by the external tool, performing logical intersection analysis according to the response result, determining a target request parameter and a target constraint condition that cause the external tool to fail to call from the request parameter set, generating a new call request according to the target request parameter and the target constraint condition, and sending the new call request to the external tool to continue executing a current task based on the new call request. The application quickly finds a fault point based on a shadow request, so that a more accurate new call request can be generated, and the success rate and efficiency of a task in a scene where a call failure prompt information is ambiguous are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and related apparatus for repairing external service call anomalies. Background Technology

[0002] In current interaction architectures between agents based on large language models and external tools, the large language model in the agent often makes blind guesses when faced with call failure messages returned by external tools. This is because the call failure messages are general status codes (such as HTTP 500 / 400) or vague general error messages (such as System Error, Invalid Request). As a result, the large language model in the agent may regenerate incorrect tool call requests, or regenerate correct tool call requests only after multiple failed calls, leading to task execution failure or low efficiency. Summary of the Invention

[0003] In view of the above problems, this application provides a method and related apparatus for repairing external service call anomalies, so as to quickly generate a correct call request when an external tool call fails. The specific solution is as follows:

[0004] The first aspect of this application provides a method for repairing external service call exceptions, including:

[0005] When the executing agent receives a call failure message from an external tool, it obtains the set of request parameters when the executing agent calls the external tool;

[0006] Multiple orthogonal shadow requests are constructed for the request parameter set. The external tool is tested based on the multiple shadow requests to obtain the response result returned by the external tool. The shadow requests are obtained by modifying one or more request parameters in the request parameter set.

[0007] Logical intersection analysis is performed based on the response results to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters. The target constraints are used to limit the conditions that the target request parameters must meet to enable the external tool call to succeed.

[0008] A new invocation request is generated based on the target request parameters and the target constraints, and sent to the external tool to continue executing the current task based on the new invocation request.

[0009] In one possible implementation, constructing multiple orthogonal shadow requests for the request parameter set includes:

[0010] The diagnostic agent is invoked to perform a risk assessment on each request parameter in the request parameter set based on the schema definition of the external tool, and obtains an error risk score corresponding to each request parameter. The agent then determines one or more request parameters with the highest error risk score from the request parameter set and constructs the multiple shadow requests for the one or more request parameters.

[0011] In one possible implementation, the step of performing logical intersection analysis based on the response result to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters includes:

[0012] The diagnostic agent is invoked, and logical intersection analysis is performed based on the response results to obtain the constraint conditions corresponding to each of the more than one request parameters.

[0013] The decision-making agent is invoked to determine the target request parameter from the one or more request parameters based on the constraints corresponding to each request parameter, and to determine the constraint corresponding to the target request parameter from the constraints corresponding to each request parameter, as the target constraint.

[0014] One possible implementation also includes:

[0015] The decision-making agent is invoked to obtain the parameter dependency topology graph corresponding to the request parameter set. Based on the parameter dependency topology graph, the associated request parameters that have a dependency relationship with the target request parameter are determined from the request parameter set. The target request parameter and the associated request parameters are used as parameters to be corrected.

[0016] The step of generating a new call request based on the target request parameters and the target constraints includes:

[0017] The new call request is generated based on the parameters to be corrected and the target constraints.

[0018] In one possible implementation, generating the new invocation request based on the parameter to be corrected and the target constraint includes:

[0019] Invoke the decision-making agent to generate a correction mask based on the parameter to be corrected. The correction mask is used to indicate that the parameter to be corrected should be modified, but other request parameters in the request parameter set other than the parameter to be corrected are frozen.

[0020] The execution agent is invoked to generate the correction parameters corresponding to the parameters to be corrected based on the correction mask and the target constraints.

[0021] The status merging module is invoked to merge the corrected parameters with the other request parameters to generate the new request.

[0022] In one possible implementation, testing the external tool based on the plurality of shadow requests includes:

[0023] The diagnostic agent is invoked to perform asynchronous testing on the external tool based on the multiple shadow requests.

[0024] One possible implementation also includes:

[0025] When the agent receives a call failure message from an external tool, it stores the intermediate data of the currently executed task.

[0026] The step of continuing to execute the current task based on the new call request includes: continuing to execute the current task based on the new call request and the intermediate task data.

[0027] In one possible implementation, constructing multiple orthogonal shadow requests for the request parameter set, testing the external tool based on the multiple shadow requests, and obtaining the response result returned by the external tool includes:

[0028] The interface attributes of the target application programming interface in the external tool are parsed to determine whether the target application programming interface is idempotent and whether it is a read-only operation, wherein the target application programming interface is the interface used by the target tool to interact with the executing intelligent agent;

[0029] If the target application programming interface is a read-only operation or is idempotent, then multiple orthogonal shadow requests are constructed for the request parameter set, and the external tool is tested based on the multiple shadow requests to obtain the response result returned by the external tool.

[0030] One possible implementation also includes:

[0031] If the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests are constructed for the request parameter set. The external tool is simulated and tested based on the multiple shadow requests within a pre-built interceptor to obtain a simulated response result, which is used as the response result returned by the external tool.

[0032] Alternatively, if the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests containing test identifiers are constructed for the request parameter set, and the multiple shadow requests containing test identifiers are tested in the simulation test environment of the external tool to obtain the response result from the simulation test environment, which is used as the response result returned by the external tool.

[0033] A second aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the external service call exception repair method described in the first aspect or any implementation thereof.

[0034] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:

[0035] The memory is used to store computer programs;

[0036] The processor is used to execute the computer program so that the electronic device can implement the external service call exception repair method of the first aspect or any implementation thereof.

[0037] The fourth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the external service call anomaly repair method described in the first aspect or any implementation thereof.

[0038] By employing the above technical solution, the external service call anomaly repair method provided in this application obtains the request parameter set when the executing agent receives a call failure message returned by an external tool. To determine the target request parameter causing the external tool call failure from the request parameter set, this application can further construct multiple orthogonal shadow requests for the request parameter set, test the external tool based on these shadow requests, and obtain the response results returned by the external tool. Since each shadow request modifies one or more request parameters in the request parameter set, logical intersection analysis based on the response results can determine the target request parameter and target constraint condition that caused the external tool call failure from the request parameter set. Therefore, a new call request is generated based on the target request parameter and target constraint condition and sent to the external tool, allowing the current task to continue execution based on the new call request. Thus, when the executing agent fails to call an external tool, this application can quickly locate the target request parameter and its implicit target constraint condition through multiple orthogonal shadow requests, thereby generating a more accurate new call request and improving the task success rate and efficiency in scenarios with ambiguous call failure messages. Attached Figure Description

[0039] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0040] Figure 1 A schematic diagram of a system architecture provided for this application;

[0041] Figure 2 A flowchart illustrating an external service call exception repair method provided in this application;

[0042] Figure 3 Signaling diagram of the collaborative operation of various modules in an abnormal system for external service calls;

[0043] Figure 4 A schematic diagram of an external service call exception repair device provided in this application;

[0044] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0045] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0046] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0047] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0048] This application provides a method and related apparatus for repairing external service call anomalies, which can be applied to scenarios where an intelligent agent calls external tools to perform the current task.

[0049] For example, in a scenario where an agent is used to purchase tickets, the agent needs to call the ticket purchase API (Application Programming Interface) to purchase tickets. When the agent receives an error code or a ticket purchase failure message from the ticket purchase API, the method in this application can be used to locate the request parameters and corresponding constraints of the ticket purchase failure, such as the date format should be YYYYMMDD. This allows for the rapid generation of a correct new call request, which in turn enables the ticket purchase to be completed more quickly.

[0050] It should be noted that the above scenarios are merely examples and are not intended to limit this application.

[0051] Optionally, the external service call exception repair method provided in this application can be applied to, for example... Figure 1 The system architecture shown includes a terminal 100 and a server 200. The server 200 may include one or more servers (…). Figure 1 (This example uses a server as an illustration).

[0052] Either terminal 100 or server 200 can be used independently to execute the external service call exception repair method provided in the embodiments of this application. Alternatively, terminal 100 and server 200 can also be used collaboratively to execute the external service call exception repair method provided in the embodiments of this application.

[0053] The following description Figure 1The product form of the mid-terminal 100;

[0054] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0055] To enable those skilled in the art to better understand this application, the external service call exception repair method of this application embodiment will be described in detail below with reference to the accompanying drawings.

[0056] Reference Figure 2 , Figure 2 This application provides a flowchart illustrating an external service call exception repair method. Figure 2 As shown, the external service call exception repair method may include:

[0057] Step S201: When the executing agent receives a call failure message returned by the external tool, obtain the request parameter set when the executing agent calls the external tool.

[0058] Specifically, when a user initiates a task instruction described in natural language, the executing agent can receive the task instruction and use the reasoning capabilities of a large model to transform the task instruction into a structured invocation request, and then invoke external tools to execute the current task based on the structured invocation request.

[0059] Generally, if there are no exceptions in the call request and the called service, the external tool can execute the task normally and return a 200 OK status code indicating that the task was successfully executed. However, there may be instances where the external tool fails to execute due to incorrect request parameters in the call request, such as incorrect format or out-of-range values, or an exception in the called service. When the external tool fails to execute, it will return a call failure message.

[0060] Optionally, the failure message can be a vague message, such as an HTTP 400 Bad Request indicating that the call request sent by the executing agent has an error. Of course, it can also be other messages, and this application does not make any specific limitations.

[0061] In this embodiment, when the executing agent receives a call failure message returned by the external tool, it can obtain the request parameter set when the executing agent calls the external tool. The request parameter set refers to the set of all request parameters in the call request.

[0062] For example, in a ticket purchase scenario, the request parameter set could be: {User ID: "000001", Seat: "Second Class Seat", Date: "20250210"}.

[0063] Step S202: Construct multiple orthogonal shadow requests for the request parameter set, test the external tool based on the multiple shadow requests, and obtain the response results returned by the external tool.

[0064] In this embodiment, in order to accurately locate the erroneous request parameters in the call request, multiple orthogonal shadow requests can be constructed for the request parameter set. For example, multiple shadow requests can be constructed using an orthogonal mutation algorithm.

[0065] Here, a shadow request is obtained by modifying one or more request parameters in the request parameter set. That is, while keeping most of the request parameters in the request parameter set unchanged, a few or one request parameters in the request parameter set are modified for "compliance". "Compliance" means that the modified value is consistent with the parameter type of the request parameter. For example, if the request parameter is a numeric type, the modified value is a numeric value; if the request parameter is a date type, the modified value is a date.

[0066] Orthogonality means that multiple shadow requests do not affect business data and that there are no conflicts between multiple shadow requests.

[0067] Furthermore, tests on external tools can be initiated based on multiple shadow requests, that is, multiple shadow requests are sent to the external tool respectively, and the response results returned by the external tool are listened to, such as pass or rejection.

[0068] Optionally, asynchronous testing of external tools can be performed based on multiple shadow requests, that is, multiple shadow requests can be sent asynchronously and concurrently to the interface of external tools to improve testing efficiency.

[0069] For example, in a high-speed rail ticket booking scenario, the original API request is {"date": "tomorrow", "seat": "second class seat", "uuid": 1001}, which results in an API error. To address this, multiple shadow requests can be constructed as follows, yielding the following response:

[0070] Shadow request A (test date): {"date": "2025-01-01", "seat": "Second Class Seat", ...}, returned success (passed);

[0071] Shadow request B (seat measurement): {"date": "tomorrow", "seat": "business class", ...}, returned failure (rejection).

[0072] Considering that some external tools do not support shadow mode, sending multiple shadow requests directly to an external tool that does not support shadow mode will cause the external tool to change its physical environment after executing each shadow request, resulting in irreversible consequences. This will cause the response results for multiple shadow requests to become invalid. For example, in a payment tool that does not support shadow mode, the tool will respond to each payment request (shadow request) and perform the actual payment operation, resulting in changes in the amount. As a result, the physical environment of each shadow request during testing has changed, which undermines the original intention that the physical environment on which the shadow request and the real request depend is consistent.

[0073] Therefore, optionally, before constructing multiple shadow requests in this step, you can first determine whether the external tool supports shadow mode. Only if shadow mode is supported can you test according to the above process to obtain the response results.

[0074] Optionally, the process of determining whether an external tool supports shadow mode may include: parsing the interface attributes of the target application programming interface (hereinafter referred to as the target API interface) in the external tool to determine whether the target API interface is idempotent and whether it is a read-only operation. Here, the target API interface refers to the interface used by the external tool to interact with the executing agent. If the target API interface is a read-only operation or is idempotent, then the target API interface is determined to support shadow mode. Conversely, if the target API interface is not a read-only operation and is not idempotent, then the target API interface is determined to not support shadow mode.

[0075] Based on this, when the target application programming interface is a read-only operation or has idempotency, multiple orthogonal shadow requests can be constructed for the request parameter set. The external tool can be tested based on the multiple shadow requests to obtain the response results returned by the external tool.

[0076] In one possible implementation, considering that the external tool does not support shadow mode, although it is not possible to directly test the external tool, the above response results can be obtained through simulation testing.

[0077] Specifically, if the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests are constructed for the request parameter set. The external tool is simulated and tested based on the multiple shadow requests within the pre-built interceptor to obtain the simulated response result, which is then used as the response result returned by the external tool.

[0078] Optionally, interceptors can exist at any of the following levels: the code layer, the HTTP (Hypertext Transfer Protocol) client layer, or the API gateway layer.

[0079] In other words, the multiple shadow requests constructed in this embodiment can be sent to the interceptor. The interceptor will automatically intercept the actual physical execution of the external tool and call the internal response simulator to simulate the business logic of the external tool. Based on the results of the simulation test, a simulated response result that is completely consistent with the real response format will be constructed and returned.

[0080] In another possible implementation, if the external tools do not support shadow mode, the above response results can also be obtained by testing in a simulation test environment.

[0081] Specifically, if the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests containing test identifiers are constructed for the request parameter set. Based on the multiple shadow requests containing test identifiers, the test is performed in the simulation test environment of the external tool, and the response result from the simulation test environment is obtained as the response result returned by the external tool.

[0082] Optionally, the test identifier can be a Dry-Run identifier, and the corresponding simulation test environment is a trial run environment; the test identifier can also be a Sandbox environment identifier, in which case the simulation test environment is a sandbox environment.

[0083] Of course, the above process of constructing a shadow request and conducting simulation or simulation testing is only an example. There may be other methods, and this application does not impose any specific limitations.

[0084] It is understandable that there may be a situation where multiple shadow requests fail to call the external tool. In this embodiment, optionally, a repair retry threshold can be set. When testing the external tool based on multiple shadow requests, if multiple shadow requests fail to call the external tool, a retry is initiated based on multiple shadow requests, or multiple shadow requests are reconstructed and tested on the external tool until the repair retry threshold is reached.

[0085] Optionally, if the call still fails when the repair retry amplitude is reached, the retry will stop and a specific system-level error will be returned for manual intervention.

[0086] Step S203: Perform logical intersection analysis based on the response results to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters.

[0087] Among them, the target constraint condition is used to limit the conditions that the target request parameters must meet for the external tool to be successfully invoked. In other words, the target constraint condition can characterize the physical boundary of the target request parameters causing the external tool to fail to be invoked.

[0088] For example, taking the shadow request and response results shown above as an example, shadow request A was successfully called, but shadow request B failed. This indicates that the request parameters in shadow request A are either unformatted or out of range. Through logical intersection analysis, it can be determined that the seat parameter is correct, but the date field does not support natural language format. Therefore, the target request parameter is "date=tomorrow", and the target constraint is "date is in YYYY-MM-DD format".

[0089] Step S204: Generate a new call request based on the target request parameters and target constraints, and send it to an external tool to continue executing the current task based on the new call request.

[0090] As mentioned earlier, by using shadow request detection and logical intersection analysis, the source of the fault can be accurately located. This allows the generation of a new call request whose target request parameters meet the target constraints. The new call request is then sent to an external tool, which can then continue executing the current task based on the new call request.

[0091] The external service call exception repair method provided in this application obtains the request parameter set when the executing agent receives a call failure message returned by an external tool. To determine the target request parameter that caused the external tool call failure from the request parameter set, this application can further construct multiple orthogonal shadow requests for the request parameter set, and test the external tool based on these shadow requests to obtain the response results returned by the external tool. Since each shadow request modifies one or more request parameters in the request parameter set, logical intersection analysis based on the response results can determine the target request parameter and target constraint that caused the external tool call failure from the request parameter set. Therefore, a new call request is generated based on the target request parameter and target constraint and sent to the external tool, allowing the current task to continue execution based on the new call request. Thus, when the executing agent fails to call an external tool, this application can quickly locate the target request parameter and its implicit target constraint through multiple orthogonal shadow requests, thereby generating a more accurate new call request and improving the task success rate and efficiency in scenarios with ambiguous call failure messages.

[0092] In some embodiments of this application, the processes of step S202 "constructing multiple orthogonal shadow requests for the request parameter set, testing the external tool based on the multiple shadow requests, and obtaining the response results returned by the external tool" and step S203 "performing logical intersection analysis based on the response results to determine the target request parameters and target constraints that cause the external tool call to fail from the request parameter set" are described.

[0093] Considering that there may be many request parameters in the request parameter set, if a corresponding shadow request is built for each request parameter, it may be necessary to construct a large number of shadow requests, which would require frequent calls to external tools and may cause service blocking and other problems.

[0094] To improve fault location efficiency, this embodiment can perform risk assessment on each request parameter in the request parameter set based on the schema definition of external tools, obtain the error risk score corresponding to each request parameter, determine one or more request parameters with the highest error risk score from the request parameter set, and construct multiple shadow requests for one or more request parameters.

[0095] More specifically, the schema of an external tool defines the complexity of all supported request parameters, such as regular expression constraints, enumeration types, and date formats. In this embodiment, static pattern matching can be used to quickly scan the set of request parameters in the call request, and the error risk score corresponding to each request parameter can be determined according to the complexity defined in the schema of the external tool. For example, date type request parameters may have multiple formats, while integer type request parameters (such as user identification) are simpler and have a lower probability of error. Therefore, the error risk assessment of date type request parameters is higher than that of integer type request parameters.

[0096] Since the higher the error risk score of a request parameter, the more likely that request parameter is to be the source parameter that causes the external tool call to fail, in order to quickly locate the source of the fault, this embodiment can construct multiple shadow requests for only one or more request parameters with the highest error risk score in the request parameter set.

[0097] Furthermore, the constructed shadow requests can be sent sequentially or asynchronously to an external tool to obtain a response from the external tool. This response is used to characterize whether the external tool can respond to the shadow requests and execute the tasks indicated by the shadow requests.

[0098] In one possible implementation, the process of constructing multiple shadow requests and testing external tools based on the shadow requests can be implemented by a diagnostic agent. That is, in this embodiment, the diagnostic agent can be invoked to perform a risk assessment on each request parameter in the request parameter set based on the schema definition of the external tool, obtain the error risk score corresponding to each request parameter, determine one or more request parameters with the highest error risk score from the request parameter set, construct multiple shadow requests for one or more request parameters, test the external tool based on the multiple shadow requests, and obtain the response results returned by the external tool.

[0099] To trigger the diagnostic agent to perform the above functions, optionally, this embodiment can also configure a collaborative scheduling center. When the execution agent receives a call failure message, it can send data such as the request context, request parameter set, and call failure log to the collaborative scheduling center. For example, the execution agent can encapsulate the request context, request parameter set, and call failure log into an exception snapshot, and then broadcast it as a broadcast help signal, so that the collaborative scheduling center can receive the broadcast help signal. Furthermore, the collaborative scheduling center can trigger a diagnostic event based on the broadcast help signal, causing the diagnostic agent to perform the above functions.

[0100] The request context mentioned above refers to the background information of the request parameter set, that is, the content in the call request other than the request parameters. Optionally, the request context may include one or more of the following: user intent, hard constraints, user information, and historical dialogue.

[0101] For example, the user intent is "I want to buy a train ticket to xx", the hard constraint is "I am a student, I only want to sit in second class, don't buy me a business class seat", the user information is "User ID 000001 corresponds to ID number 1xxx, account balance 200 yuan", and the history of the conversation is "The user just changed the date from February 9th to February 10th".

[0102] Of course, the request context may also include other information, such as the request address, which is not specifically limited in this application.

[0103] The above call failure log includes one or more of the status code and error message.

[0104] For example, the error code is "HTTP 400 Bad Request" and the error message is "Invalid Date Format".

[0105] Furthermore, in order to accurately locate the source of the fault, this embodiment can perform logical intersection analysis based on the response results to obtain the constraint conditions corresponding to each of the more than one request parameters. Through these constraint conditions, the boundary range of each request parameter that causes the external tool call to fail can be determined.

[0106] Optionally, the process of “performing logical intersection analysis based on the response results to obtain the constraints corresponding to each of the more than one request parameters” can be implemented by calling the diagnostic agent.

[0107] Optionally, in order to determine the target request parameters and target constraints, this embodiment can also configure a decision agent, which can be invoked to determine the target request parameters from one or more request parameters based on the constraints corresponding to each request parameter, and to determine the constraints corresponding to the target request parameters from the constraints corresponding to each request parameter, as the target constraints.

[0108] Considering the potential dependencies between request parameters—for example, in a fixed time period, the start time and end time parameters might be dependent on each other, requiring corresponding modifications to the end time parameter when the start time parameter is changed—it's possible that in some scenarios, even if some parameters don't cause the call to the external tool to fail, they still need to be modified.

[0109] Based on this, optionally, in order to more comprehensively determine all the request parameters that need to be modified, this embodiment can also call the decision intelligence to obtain the parameter dependency topology graph corresponding to the request parameter set, and determine the associated request parameters that have a dependency relationship with the target request parameter from the request parameter set according to the parameter dependency topology graph, and take the target request parameter and associated request parameters as parameters to be modified.

[0110] For example, if the target request parameter is a start time parameter, then the associated request parameter can be an end time parameter.

[0111] Optionally, the parameter-dependent topology graph can be pre-built or generated based on the constraints corresponding to each of the more than one request parameters. This embodiment does not impose any specific limitations.

[0112] Accordingly, the process of step S204 "generating a new call request based on the target request parameters and target constraints" may include: generating a new call request based on the parameters to be corrected and the target constraints.

[0113] It should be understood that, generally, if two request parameters have a dependency relationship, then the two request parameters are usually of the same parameter type. Therefore, if the target constraint condition corresponding to the target request parameter has been determined, the constraint condition corresponding to the associated request parameter can reuse the target constraint condition, without having to determine the constraint condition for the associated request parameter again.

[0114] In this embodiment, by introducing an orthogonal active detection mechanism, shadow requests for high-risk request parameters can be automatically constructed in the black-box state of fuzzy errors returned by external tools (such as APIs). This allows for more accurate location of specific error parameters (i.e. target request parameters) and their implicit business constraints, improving the robustness of the system in scenarios with missing documents or non-standard error reporting.

[0115] In some other embodiments of this application, the process of "generating a new call request based on the parameters to be corrected and the target constraints" mentioned above is similar to the process of "generating a new call request based on the target request parameters and the target constraints" in step S204. The process of "generating a new call request based on the parameters to be corrected and the target constraints" will be used as an example in the following description. The process of "generating a new call request based on the target request parameters and the target constraints" in step S204 can be referred to accordingly.

[0116] In one possible implementation, the generation of new call requests can be implemented by an agent. However, considering that the output of the large language model within the agent is random, it may unintentionally tamper with other request parameters that have already been tested while correcting the parameters to be corrected, leading to a chain reaction of "fixing the old problem and introducing a new one", which seriously affects the stability of the task.

[0117] To address the aforementioned issues, this embodiment provides a parameter freezing strategy.

[0118] Optionally, this embodiment can call a decision agent to generate a correction mask based on the parameter to be corrected. The correction mask is used to indicate that the parameter to be corrected should be modified, but other request parameters in the request parameter set other than the parameter to be corrected are frozen. Then, the execution agent is called to generate the correction parameter corresponding to the parameter to be corrected based on the correction mask and the target constraint. Finally, the state merging module is called to merge the correction parameter with other request parameters to generate a new call request.

[0119] Optionally, JSON Merge Patch technology can be used to merge the corrected parameters with other request parameters to generate a new call request.

[0120] Referring again to the example of "high-speed rail ticket booking" above, the decision-making agent can construct a correction mask based on the parameters to be corrected, which can be "MASK = {date: ACTIVE, seat: FROZEN, uuid: FROZEN}". The system can then generate a repair instruction: "You are currently in repair mode. The parameters seat='second class seat' and uuid=1001 have been physically locked by the system and modification is strictly prohibited. Please only correct the date field from 'tomorrow' to a string conforming to the YYYY-MM-DD format." This repair instruction is then input into the execution agent, which can correct the date field, obtaining the corrected parameter in YYYY-MM-DD format, such as "2025-12-28", and then use JSON Merge. The Patch technology structurally merges the corrected parameters with other frozen request parameters, i.e., Merge(Frozen:{"seat":"Second Class Seat","uuid":1001},Patch:{"date":"2025-12-28"}), and reassembles them in real time into a new call request that conforms to the API specification, such as {"date":"2025-12-28","seat":"Second Class Seat","uuid":1001}.

[0121] In this embodiment, the verified request parameters are forcibly locked by modifying the mask, which blocks the random bias that may be introduced during the probability generation process of the large language model. This transforms the repair process from an uncontrollable full rewrite to a controllable incremental patch, effectively preventing the problem of other correct parameters being tampered with due to the correction of one error, and significantly improving the success rate of complex tasks.

[0122] In one possible implementation, to avoid the external tool needing to re-execute the task from scratch after generating a new call request, this embodiment can also suspend the current task state and store the intermediate data of the currently executed task when the executing agent receives the call failure prompt information returned by the external tool. Then, after sending the new call request to the external tool in step S204, the process of the external tool "continuing to execute the current task based on the new call request" can include: continuing to execute the current task based on the new call request and the intermediate task data.

[0123] This embodiment saves intermediate task data, enabling external tools to resume interrupted tasks upon receiving new call requests. This significantly reduces computing power consumption and end-to-end task response latency, thus optimizing the user experience.

[0124] To enable those skilled in the art to better understand this application, the complete process is described in detail through the following embodiments.

[0125] In one possible implementation, the external service call exception repair method provided in this application can be applied to an external service call exception system. Optionally, the external service call exception system may include: an execution agent, a diagnostic agent, a decision agent, a state merging module, and a collaborative scheduling center.

[0126] The functions of each module are described below:

[0127] The Cooperative Scheduling Center, serving as the core scheduling and message bus of the entire system, is responsible for monitoring the operational status of each agent and distributing tasks. Upon receiving a broadcast distress signal from an executing agent, this module suspends the current main task thread and dynamically activates the diagnostic or decision-making agent. It ensures the asynchronous execution of fault handling processes, preventing a single error from blocking other concurrent tasks and subsequent pipeline tasks.

[0128] The execution agent is responsible for the concrete implementation of business logic and direct interaction with external tools. This module receives task instructions from upstream, breaks them down into specific call requests (i.e., API calls or MCP (Model Context Protocol) server call requests). During the call process, it continuously monitors the return status. Once it captures an abnormal response other than 200 OK (such as a 400 error or a vague business error), it immediately stops retrying, reports a snapshot of the current call request, call failure logs, and other data to the collaborative scheduling center, and enters a "pending repair" state, waiting to receive the correction mask from the decision agent.

[0129] Diagnostic agent: Responsible for in-depth root cause analysis of fuzzy errors. This module does not rely on the general reasoning capabilities of large models. Instead, based on the MCP protocol or API Schema definition, it automatically constructs a set of shadow requests that do not affect business data using orthogonal mutation algorithms. Based on the response results of the shadow request probes, it instantly locks down the fault boundary through logical intersection analysis and generates a fault report.

[0130] The decision-making agent is responsible for formulating safe remediation strategies and directing the execution agents. This module receives reports from the diagnostic agent and, combined with the original task context, constructs a parameter freeze strategy. It identifies all validated correct parameter fields and marks them as "frozen areas," while only marking diagnosed error fields as "areas to be repaired." Finally, it generates a strongly constrained correction mask and prompt instructions, which are then sent to the execution agent, requiring it to regenerate the error items without modifying the frozen areas.

[0131] The State Merging Module is responsible for reassembling the corrected parameters into a complete request package. This module receives incremental fragments (i.e., JSON containing only the corrected parameters) generated by the executing agent based on the correction mask. Using JSON Merge Patch technology, it structurally merges these fragments with the correct parameters locked in the historical request, ensuring that the new call request sent to external tools corrects the errors while perfectly preserving the user's original intent, achieving lossless repair.

[0132] External tools: Serving as a communication bridge between the system and heterogeneous external environments, these are typically MCP invocation tools. They are responsible for standardizing the return formats of different protocols, uniformly mapping heterogeneous error codes into common exception signals that the system can recognize, for the executing agent to capture.

[0133] See Figure 3 The diagram shown is a signaling diagram illustrating the collaborative operation of various modules in an external service call exception system.

[0134] Step S301: The agent receives the call failure message returned by the external tool.

[0135] Specifically, when a user initiates a task instruction described in natural language to the system, the executing agent receives the task instruction and uses the deep reasoning capabilities of the large language model to transform the natural language task instruction into a structured call request, which is then sent to an external tool. Due to the complexity of the external environment, such as delayed API documentation updates or model illusions, the external tool will return a vague call failure message without specifying the exact reason for the error.

[0136] Step S302: The intelligent agent sends out a broadcast distress signal.

[0137] In this embodiment, after receiving the call failure message, the executing agent does not blindly retry. Instead, it encapsulates the current request context, request parameter set, call failure log and other data into an abnormal snapshot, and then broadcasts it in the form of a broadcast help signal.

[0138] Optionally, the executing agent can then enter a suspended state, release computing resources, and wait for rescue instructions from the cooperative network, thus avoiding API rate limiting or blocking caused by continuous erroneous calls.

[0139] Step S303: After receiving the broadcast distress signal, the collaborative dispatch center triggers a diagnostic event.

[0140] Step S304: The diagnostic agent performs a diagnosis and generates a diagnostic report.

[0141] Optionally, the diagnostic agent can perform risk assessment on each request parameter in the request parameter set based on the schema definition of an external tool, obtain the error risk score corresponding to each request parameter, determine one or more request parameters with the highest error risk score from the request parameter set, construct multiple shadow requests for one or more request parameters, and perform logical intersection analysis based on the response results to obtain the constraints corresponding to each of the one or more request parameters. Finally, the constraints corresponding to each of the one or more request parameters are packaged into a diagnostic report.

[0142] Step S305: The diagnostic agent sends the diagnostic report to the decision agent and simultaneously sends a notification of diagnostic completion to the collaborative scheduling center.

[0143] Step S306: The collaborative scheduling center triggers a decision event.

[0144] Step S307: The decision-making agent makes a decision, determines the parameters to be corrected and the target constraints, and generates a repair instruction.

[0145] Optionally, the decision agent determines the target request parameter from one or more request parameters based on the constraints corresponding to each request parameter, and determines the constraints corresponding to the target request parameter from the constraints corresponding to each request parameter, which serve as the target constraints, and generates a correction mask based on the target request parameter.

[0146] Optionally, the decision-making agent can also obtain the parameter dependency topology graph corresponding to the request parameter set, determine the associated request parameters that have a dependency relationship with the target request parameter from the request parameter set based on the parameter dependency topology graph, take the target request parameter and associated request parameters as parameters to be corrected, and generate a correction mask based on the parameters to be corrected.

[0147] As mentioned earlier, the decision-making agent can also generate repair instructions based on the correction mask and target constraints.

[0148] Step S308: The decision-making agent sends the repair instruction to the execution agent.

[0149] Step S309: Execute the agent's response repair command, generate correction parameters, and send the correction parameters to the state merging module.

[0150] Specifically, the executing agent, based on the repair instructions and under the constraint of the mask, can generate JSON-formatted correction parameters with minimal token consumption.

[0151] Step S310: The state merging module generates a new call request.

[0152] Optionally, the state merging module performs a JSON Merge Patch operation, which seamlessly merges the newly generated corrected parameters with the other frozen request parameters to obtain a new call request.

[0153] After this, the executing agent can initiate a retry for the external tool based on the new call request. Since all the request parameters in the new call request are correct parameters verified by the shadow request probe, the external tool can successfully complete the task based on the new call request and return the task result. Finally, the executing agent returns the task result to the user, forming a closed loop.

[0154] In summary, the external service call exception repair method provided in this application may include the following four stages: task initiation and exception suspension, concurrent shadow detection, policy arbitration and mask generation, incremental repair and closed-loop retry.

[0155] Optionally, in the first stage, the executing agent runs on the central coordination scheduling unit, which parses the task instructions issued by the user, drives the network adapter to issue the original call request, and when the network adapter receives the call failure message returned by the external tool, the interrupt controller suspends the current task state, and the fusion controller uses direct memory access (DMA) to transfer the current register state of the task intermediate data, as well as the request context, request parameter set and other data, to the fixed state memory.

[0156] In the second phase, the collaborative scheduling center operates within the central collaborative scheduling unit, while the diagnostic agent and decision-making agent operate within the inference and masking computation unit. This allows the central collaborative scheduling unit to wake up the inference and masking computation unit and load the API schema. The inference and masking computation unit then utilizes the parallel computing capabilities of the GPU to perform regular expression matching and enumeration scanning on the request parameter set, outputting a list of high-risk parameters. This list includes at least one request parameter with the highest error risk score. Based on the orthogonal mutation algorithm, multiple non-conflicting shadow requests (also known as shadow request packets) are quickly generated in the GPU memory. The isolated diagnostic sandbox unit then uses multi-channel network adaptation to simultaneously send multiple shadow requests to external tools on independent physical ports and collects the response results from the external tools for each shadow request. Finally, the inference and masking computation unit performs logical intersection operations based on the response results, instantly locking down the fault boundary range and generating a diagnostic report.

[0157] In the third stage, the inference and masking computation unit constructs a parameter dependency topology graph in the video memory based on the diagnostic report, and generates a binary mask matrix (i.e., a correction mask) aligned with the structure of the requested parameter set, with the correct parameters set to 1 and the parameters to be corrected set to 0.

[0158] In the fourth stage, the central coordination and scheduling unit receives the repair instruction generated based on the correction mask. It generates the corresponding correction parameters only for the parameters to be corrected with a mask of 0. Then, it drives the fusion controller to use the aggregation function of DMA to embed the correction parameters into the designated empty slots of the frozen area storing the correct parameters according to the address offset defined by the mask. This completes the physical reassembly of the JSON Merge Patch, obtains a new call request, and then pushes the new call request to the external tool to retry the call.

[0159] The following is a specific scenario to illustrate each of the above processes, in order to facilitate understanding.

[0160] A bank compliance officer gave an instruction to the AI ​​audit assistant using natural language: "Query all cross-border transfer records of account 6222-0088 in the fourth quarter of 2025, and the amount exceeds $50,000."

[0161] Bank compliance personnel issued a task command via natural language: "Query all cross-border transfer records of account 6222xxxx in the fourth quarter of 2025, with amounts exceeding $50,000." This task command invokes the bank's core accounting system. This system has an outdated interface, highly inconsistent error messages (only returning "System Error 9001"), and extremely strict and ambiguous requirements regarding date formats and monetary units. This may lead to the following process:

[0162] Step 1: Compliance personnel input task instructions.

[0163] Step 2: The executing agent converts the task instruction into an API call request for the core system: {"acct_id":"6222-0088","amount":"50,000","currency":"USD","period":"2025-Q4","type":"CROSS_BORDER"}, and sends the call request to the core accounting system.

[0164] Step 3: The core system returns Error 9001: Invalid Filter Condition (no specific field specified). The agent intercepts the exception, suspends the task, and prevents the generation of invalid audit logs.

[0165] Step 4: The coordination and scheduling center triggers a diagnostic event. The diagnostic agent's static analysis identifies amount (a string containing commas) and period (quarter description) as high-risk items. Based on this, it constructs and concurrently sends shadow requests (using a test account or read-only permissions):

[0166] Shadow Request A (to measure amount): Change amount to 50000 (a pure number), keep everything else unchanged; return failure.

[0167] Shadow request B (time measurement): Decompose period into start: 20251001, end: 20251231; returns failure.

[0168] Shadow Request C (Double Correction): Simultaneously modify the amount to 5,000,000 (converted to "cents") and the time format; returns success.

[0169] Step 5: Analyze and generate a diagnostic report based on the response results returned by the core accounting system. The core content is that the accounting system requires the amount unit to be "cent" (int), and the time needs to be split into Start / End and the format is YYYYMMDD.

[0170] Step 6: The decision-making agent formulates a strategy: forcefully freeze acct_id and type (absolutely do not change the account incorrectly because of the amount, which would lead to checking someone else's transaction history and causing a major compliance incident), and the parameters to be corrected are amount and period.

[0171] Step 7: Upon receiving the repair instruction, the agent converts 50,000 USD into 5,000,000 points, converts Q4 into a specific date range, and generates correction parameters.

[0172] Step 8: The state merging module generates a new call request {"acct_id":"6222-0088","amount":5000000, "currency":"USD","start_date":"20251001","end_date":"20251231", "type": "CROSS_BORDER"}.

[0173] Step 9: The execution agent initiates a retry based on the new call request, obtains the query result set returned by the core system, and generates an audit report based on the query result set to provide feedback to the compliance personnel.

[0174] It should be noted that the above scenarios and processes are merely examples, and there may be other implementation methods and scenarios, which are not specifically limited in this application.

[0175] The above describes a method for repairing external service call anomalies provided by embodiments of this application. The following describes the apparatus for performing the above-described method for repairing external service call anomalies.

[0176] Please see Figure 4 , Figure 4This is a schematic diagram of an external service call exception repair device provided in an embodiment of this application. Figure 4 As shown, the external service call exception repair device may include:

[0177] The data acquisition unit 401 is used to acquire the request parameter set when the execution agent calls the external tool after receiving a call failure prompt message returned by the external tool;

[0178] The shadow detection unit 402 is used to construct multiple orthogonal shadow requests for the request parameter set, test the external tool based on the multiple shadow requests, and obtain the response result returned by the external tool. The shadow request is obtained by modifying one or more request parameters in the request parameter set.

[0179] The response analysis unit 403 is used to perform logical intersection analysis based on the response results to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters. The target constraints are used to limit the conditions that the target request parameters must meet to enable the external tool call to succeed.

[0180] The request retry unit 404 is used to generate a new call request based on the target request parameters and target constraints, and send it to an external tool to continue executing the current task based on the new call request.

[0181] The modules in the aforementioned external service call anomaly repair device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the computer device's memory as software, so that the processor can invoke and execute the operations corresponding to each module.

[0182] This application also provides an electronic device, which may include at least one processor and a memory connected to the processor, wherein:

[0183] Memory is used to store computer programs;

[0184] The processor is used to execute computer programs to enable electronic devices to implement any of the external service call exception repair methods provided in the embodiments of this application.

[0185] refer to Figure 5 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0186] like Figure 5 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0187] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0188] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the external service call exception repair methods provided in this application.

[0189] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the external service call exception repair methods provided in this application.

[0190] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0191] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred 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 readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0192] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0193] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for repairing external service call exceptions, characterized in that, include: When the executing agent receives a call failure message from an external tool, it obtains the set of request parameters when the executing agent calls the external tool; Multiple orthogonal shadow requests are constructed for the request parameter set. The external tool is tested based on the multiple shadow requests to obtain the response result returned by the external tool. The shadow request is obtained by modifying one or more request parameters in the request parameter set. Logical intersection analysis is performed based on the response results to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters. The target constraints are used to limit the conditions that the target request parameters must meet to enable the external tool call to succeed. A new invocation request is generated based on the target request parameters and the target constraints, and sent to the external tool to continue executing the current task based on the new invocation request.

2. The method for repairing external service call anomalies according to claim 1, characterized in that, The construction of multiple orthogonal shadow requests for the request parameter set includes: The diagnostic agent is invoked to perform a risk assessment on each request parameter in the request parameter set based on the schema definition of the external tool, and obtains an error risk score corresponding to each request parameter. The agent then determines one or more request parameters with the highest error risk score from the request parameter set and constructs the multiple shadow requests for the one or more request parameters.

3. The method for repairing external service call anomalies according to claim 2, characterized in that, The step of performing logical intersection analysis based on the response result to determine the target request parameters and target constraints that cause the external tool call to fail from the set of request parameters includes: The diagnostic agent is invoked, and logical intersection analysis is performed based on the response results to obtain the constraint conditions corresponding to each of the more than one request parameters. The decision-making agent is invoked to determine the target request parameter from the one or more request parameters based on the constraints corresponding to each request parameter, and to determine the constraint corresponding to the target request parameter from the constraints corresponding to each request parameter, as the target constraint.

4. The method for repairing external service call anomalies according to claim 3, characterized in that, Also includes: The decision-making agent is invoked to obtain the parameter dependency topology graph corresponding to the request parameter set. Based on the parameter dependency topology graph, associated request parameters that have a dependency relationship with the target request parameter are determined from the request parameter set. The target request parameter and the associated request parameter are used as parameters to be corrected. The step of generating a new call request based on the target request parameters and the target constraints includes: The new call request is generated based on the parameters to be corrected and the target constraints.

5. The method for repairing external service call anomalies according to claim 4, characterized in that, The step of generating the new call request based on the parameters to be corrected and the target constraints includes: Invoke the decision-making agent to generate a correction mask based on the parameter to be corrected. The correction mask is used to indicate that the parameter to be corrected should be modified, but other request parameters in the request parameter set other than the parameter to be corrected are frozen. The execution agent is invoked to generate the correction parameters corresponding to the parameters to be corrected based on the correction mask and the target constraints. The status merging module is invoked to merge the corrected parameters with the other request parameters to generate the new request.

6. The method for repairing external service call anomalies according to any one of claims 1-5, characterized in that, Also includes: When the agent receives a call failure message from an external tool, it stores the intermediate data of the currently executed task. The step of continuing to execute the current task based on the new call request includes: continuing to execute the current task based on the new call request and the intermediate task data.

7. The method for repairing external service call anomalies according to claim 1, characterized in that, The process of constructing multiple orthogonal shadow requests for the request parameter set, testing the external tool based on the multiple shadow requests, and obtaining the response results returned by the external tool includes: The interface attributes of the target application programming interface in the external tool are parsed to determine whether the target application programming interface is idempotent and whether it is a read-only operation, wherein the target application programming interface is the interface used by the external tool to interact with the executing intelligent agent; If the target application programming interface is a read-only operation or is idempotent, then multiple orthogonal shadow requests are constructed for the request parameter set, and the external tool is tested based on the multiple shadow requests to obtain the response result returned by the external tool.

8. The method for repairing external service call anomalies according to claim 7, characterized in that, Also includes: If the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests are constructed for the request parameter set. The external tool is simulated and tested based on the multiple shadow requests within a pre-built interceptor to obtain a simulated response result, which is used as the response result returned by the external tool. Alternatively, if the target application programming interface is not a read-only operation and is not idempotent, then multiple orthogonal shadow requests containing test identifiers are constructed for the request parameter set, and the multiple shadow requests containing test identifiers are tested in the simulation test environment of the external tool to obtain the response result from the simulation test environment, which is used as the response result returned by the external tool.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the external service call exception repair method as described in any one of claims 1 to 8.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the external service call anomaly repair method as described in any one of claims 1 to 8.

Images