A cloud platform interface calling method, system, device, medium, and product

Abstract

This invention relates to the field of API interface invocation technology, and in particular to a cloud platform API invocation method, system, device, medium, and product. The method involves: acquiring user-input query text; determining several sub-query texts based on the query text; identifying the target interface corresponding to the sub-query vectors of the sub-query texts based on an application programming interface vector index library, and determining the structured tool cards of the target interface based on relevant fields of the target interface; generating an invocation request based on the structured tool cards corresponding to the sub-query texts, which is used to invoke the target interface; and after the sub-query texts have implemented their respective interface invocations, aggregating the results of the interface invocations of the sub-query texts to generate a response result. This invention eliminates the problems of inaccurate target interface selection and low selection efficiency caused by related technologies.

Description

Technical Field

[0001] This invention relates to the field of API interface calling technology, and in particular to a cloud platform interface calling method, system, device, medium and product. Background Technology

[0002] With the rapid development of cloud computing technology, the management of modern cloud platforms (especially private and hybrid cloud environments) is becoming increasingly complex. These platforms provide tens of thousands of application programming interfaces (APIs) covering all aspects of computing, storage, networking, and security, providing powerful capabilities for automated operation and maintenance and management.

[0003] In recent years, the emergence of large language models (LLMs) has brought revolutionary breakthroughs to the interaction with complex systems through natural language. Natural language-to-interface calling technology based on LLMs has thus emerged, its core idea being to enable LLMs to understand user intent and automatically select and call the appropriate APIs to complete tasks.

[0004] The closest existing technology to this invention typically employs an in-context toolcalling pattern. Specifically, developers pre-select and compile a functional description document for the APIs (usually a simplified version of the OpenAPI specification). Each time a user initiates a query, this document, along with the user's query, is submitted as context to a large language model. The LLM then reads and understands this vast context, automatically deciding which API(s) to call and generating the necessary parameters for the call.

[0005] However, when the number of APIs surges from dozens to thousands or even tens of thousands, the context window length of large language models is limited and cannot accommodate the complete description of a massive number of APIs. Forcing them in can lead to information truncation or a sharp drop in model performance. Even if it can accommodate them, LLMs are easily confused by hundreds or thousands of functionally similar APIs, leading to incorrect selections, i.e., choosing APIs with mismatched functions.

[0006] How to efficiently and reliably implement API calls in a massive API environment is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] The purpose of this invention is to provide a cloud platform interface calling method, system, device, medium, and product that can efficiently and reliably realize API interface calling.

[0008] Firstly, a cloud platform interface invocation method is provided, comprising: acquiring query text input by a user; determining several sub-query texts based on the query text, wherein if the query intent corresponding to the query text is a single intent, then the several sub-query texts constitute the query text; if the query intent corresponding to the query text is a complex intent, then the several sub-query texts constitute multiple sub-query texts, and the multiple sub-query texts have an execution order; determining a target interface corresponding to the sub-query vector of the sub-query text based on an application programming interface vector index library, and determining a structured tool card of the target interface based on relevant fields of the target interface; wherein the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; generating an invocation request based on the structured tool card corresponding to the sub-query text, the invocation request being used to implement the invocation of the target interface; after the several sub-query texts have implemented their respective interface invocations, aggregating the results of the interface invocations of the several sub-query texts to generate a response result.

[0009] In a preferred embodiment, the present invention can be further configured to: determine several sub-query texts based on the query text, including: determining an intent detection result based on the query text; if the intent detection result is a single intent, then determining the several sub-query texts as the query text; if the intent detection result is a complex intent, then generating an execution plan based on the query text, the execution plan including multiple sub-task nodes with an execution order; and determining the sub-query text corresponding to each sub-task node based on the execution plan.

[0010] In a preferred embodiment, the present invention can be further configured to: determine an intent detection result based on the query text, including: determining a structural signal score, a semantic signal score, and an entity signal score of the query text; determining a complexity score of the query text based on the structural signal score, the semantic signal score, and the entity signal score; if the complexity score of the query text is greater than a preset complexity threshold, then the intent detection result is determined to be a complex intent; if the complexity score of the query text is not greater than the preset complexity threshold, then the intent detection result is determined to be a single intent.

[0011] In a preferred embodiment, the present invention can be further configured to: generate an execution plan based on the query text, including: performing syntactic analysis on the query text to determine the subtask dependencies of multiple subtask nodes; generating a structured subtask list of multiple subtask nodes corresponding to the query text according to the subtask dependencies; and generating a directed acyclic graph as the execution plan based on the structured subtask list.

[0012] In a preferred embodiment, the present invention can be further configured as follows: generating a directed acyclic graph (DAG) as an execution plan based on the structured subtask list, including: generating the DAG based on the structured subtask list; determining whether the DAG is a complex graph; if so, estimating the cost of different paths in the DAG based on dynamic statistical information stored in the metadata database to obtain the path with the lowest cost; the metadata database is associated with the application programming interface vector index library through a unique interface identifier, the metadata database is constructed based on the metadata corresponding to each interface, and the metadata corresponding to the interface includes static information and dynamic statistical information; updating the DAG based on the path with the lowest cost to update the execution plan.

[0013] In a preferred embodiment, the present invention can be further configured as follows: after updating the directed acyclic graph based on the path with the lowest cost, the invention further includes: determining the target subtask node marked as a write operation in the execution plan; determining the compensation operation corresponding to the target subtask node; and adding the compensation operation as a compensation node to the compensation plan, wherein the execution order of the compensation plan is the reverse of the topological order of the corresponding nodes in the execution plan, and the compensation plan is used to roll back when the subtask in the execution plan fails.

[0014] In a preferred embodiment, the present invention may be further configured as follows: after determining the subquery text corresponding to each subtask node based on the execution plan, the invention further includes: injecting the execution result information of the previous node of each subtask node as a query context into the subquery text, and updating the subquery text corresponding to each subtask node.

[0015] In a preferred embodiment, the present invention can be further configured as follows: determining the target interface corresponding to the subquery vector of the subquery text based on an application programming interface vector index library, including: extracting query metadata based on the subquery text; generating a subquery vector based on the subquery text; filtering a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index library based on the subquery vector; determining a re-ranking score corresponding to the candidate interfaces based on the similarity scores, metadata matching degree, permission availability, interface usage frequency, and error rate of the candidate interfaces; wherein, the metadata matching degree represents the matching degree between the query metadata and the corresponding parameters of the candidate interfaces; the permission availability is the calling interface permission score of the candidate interfaces determined from the metadata database; the interface usage frequency and error rate are the parameters of the candidate interfaces determined from the metadata database; sorting the preset number of candidate interfaces based on the re-ranking score to obtain a candidate interface sequence corresponding to the subquery text; and determining the target interface based on the candidate interface sequence corresponding to the subquery text.

[0016] In a preferred embodiment, the present invention can be further configured as follows: after determining the re-ranking score corresponding to the candidate interface based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate of the candidate interface, the invention further includes: if the highest re-ranking score among the re-ranking scores of a preset number of candidate interfaces is lower than a preset re-ranking score threshold, a clarifying question is generated; after the user inputs supplementary information based on the clarifying question, the re-ranking score is re-determined; if the highest re-ranking score among the re-ranking scores is lower than the preset re-ranking score threshold, a prompt message is generated; if the highest re-ranking score among the re-ranking scores is not lower than the preset re-ranking score threshold, the step of sorting the preset number of candidate interfaces based on the re-ranking score to obtain the candidate interface sequence corresponding to the sub-query text is performed.

[0017] In a preferred embodiment, the present invention can be further configured to: filter a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index based on the subquery vector, including: determining the service domain of the subquery text based on the subquery text; and filtering a preset number of candidate interfaces with the highest similarity scores from the sub-index corresponding to the service domain of the subquery text in the application programming interface vector index.

[0018] In a preferred embodiment, the present invention may be further configured as follows: before selecting a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index based on the sub-query vector, the invention further includes: determining a preset number based on the complexity score of the query text; the complexity score of the query text is a score determined based on the structural signal score, semantic signal score, and entity signal score of the query text.

[0019] In a preferred embodiment, the present invention can be further configured as follows: the relevant fields of the target interface include: key text information, metadata information, and candidate values; based on the relevant fields of the target interface, the structured tool card of the target interface is determined, including: determining the key text information of the target interface from the application programming interface vector index library; determining the metadata information of the target interface from the metadata database; and determining the structured tool card of the target interface based on the key text information, metadata information, and candidate values ​​of the target interface.

[0020] In a preferred embodiment, the present invention can be further configured as follows: after determining the structured tool card of the target interface based on the key text information, metadata information, and candidate values ​​of the target interface, the invention further includes: automatically filling in the missing parameters in the structured tool card based on the query metadata and enumeration information of the target interface; wherein, the query metadata is data extracted from the sub-query text of the target interface, and the enumeration information is information corresponding to the target interface determined from the enumeration table; after automatic filling, if there are missing required parameters, then according to a preset question template, a completion prompt for all missing required parameters is generated; and the structured tool card is filled based on the completion information input by the user.

[0021] In a preferred embodiment, the present invention can be further configured to: generate completion suggestions for all missing required parameters according to a preset question template, including: sorting the missing required parameters according to their information gain values; and generating completion suggestions for all missing required parameters sequentially using the preset question template based on the sorting results; wherein the information gain value is determined based on the information content and filtering capability of the required parameters.

[0022] In a preferred embodiment, the present invention may be further configured as follows: before obtaining the query text input by the user, it further includes: extracting key text information from each of the multiple interface definition files; converting the key text information into semantic vectors using a text embedding model; and constructing an application programming interface vector index library based on the semantic vectors and the corresponding key text information.

[0023] In a preferred embodiment, the present invention can be further configured as follows: before obtaining the query text input by the user, it further includes: extracting the enumeration values, core entities, and terms of each of the multiple interface definition files; based on the core entities and terms, inputting a large language model to determine the synonyms corresponding to the core entities and terms, as well as the mapping between abbreviations and full names; generating standardized definitions based on the core entities and terms, synonyms, and abbreviations; expanding the vocabulary using expert review, the expanded vocabulary including synonyms, abbreviations, and standardized definitions; constructing an enumeration table according to the enumeration values ​​of each of the multiple interface definition files; and constructing a domain dictionary based on the core entities and terms and the expanded vocabulary.

[0024] Secondly, a cloud platform interface call system is provided, comprising: a query acquisition module for acquiring query text input by a user; a text determination module for determining several sub-query texts based on the query text, wherein if the query intent corresponding to the query text is a single intent, then the several sub-query texts constitute the query text; if the query intent corresponding to the query text is a complex intent, then the several sub-query texts constitute multiple sub-query texts, and the multiple sub-query texts have an execution order; a decision module for determining the target interface corresponding to the sub-query vector of the sub-query text based on an application programming interface vector index library, and determining the structured tool card of the target interface based on the relevant fields of the target interface; wherein the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; an execution module for generating a call request based on the structured tool card corresponding to the sub-query text, the call request being used to implement the call to the target interface; after the several sub-query texts implement their respective interface calls, the results of the interface calls of the several sub-query texts are aggregated to generate a response result.

[0025] Thirdly, an electronic device is provided, including a memory for storing a computer program; and a processor for executing the computer program to implement the cloud platform interface invocation method as described in any of the first aspects.

[0026] Fourthly, a non-volatile storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, it implements the cloud platform interface calling method as described in any of the first aspects.

[0027] Fifthly, a computer program product is provided, including a computer program / instruction, which, when executed by a processor, implements the cloud platform interface invocation method as described in any of the first aspects.

[0028] In summary, the cloud platform interface invocation method provided by this invention has the following beneficial technical effects: acquiring the query text input by the user; determining several sub-query texts based on the query text, wherein if the query intent corresponding to the query text is a single intent, then the several sub-query texts constitute the query text; if the query intent corresponding to the query text is a complex intent, then the several sub-query texts constitute multiple sub-query texts, and the multiple sub-query texts have an execution order; determining the target interface corresponding to the sub-query vector of the sub-query text based on the application programming interface vector index library, and determining the structured tool card of the target interface based on the relevant fields of the target interface; wherein the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; generating an invocation request based on the structured tool card corresponding to the sub-query text, the invocation request being used to implement the invocation of the target interface; after the several sub-query texts implement their respective interface invocations, aggregating the results of the interface invocations of the several sub-query texts to generate a response result. This invention does not inject all API interface descriptions into the LLM context. Instead, it performs vector retrieval based on LLM. It pre-converts multiple interface definition files into lightweight semantic vectors to build an index. Furthermore, it introduces an intent analysis mechanism. At runtime, the user query is broken down into several sub-query texts based on the user's intent. The vector of each sub-query text is then matched against the API index to locate the target interface, i.e., the corresponding structured tool card, and to implement the interface call. After each sub-query text implements its respective interface call, the results of the interface calls for the sub-query texts are aggregated to generate a response result. This invention eliminates the problems of inaccurate target interface filtering and low filtering efficiency caused by related technologies.

[0029] In addition, the present invention also provides a cloud platform interface calling system, device, medium and product, all of which have the above-mentioned beneficial technical effects. Attached Figure Description

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

[0031] Figure 1 A flowchart illustrating a cloud platform interface calling method provided in an embodiment of the present invention; Figure 2 A structural diagram of a DAG provided in an embodiment of the present invention; Figure 3 A system structure block diagram provided for an embodiment of the present invention; Figure 4This is a structural diagram of the knowledge and interface index layer provided in the embodiments of the present invention; Figure 5 This is a structural diagram of the query analysis and vector retrieval layer provided in the embodiments of the present invention; Figure 6 This is a structural diagram of the tool decision-making and parameter generation layer provided in the embodiments of the present invention; Figure 7 This is a structural diagram of the execution and synthesis layer provided in an embodiment of the present invention; Figure 8 This is a structural diagram of the hot update and monitoring layer provided in an embodiment of the present invention; Figure 9 This is a structural diagram of a cloud platform interface call system provided in an embodiment of the present invention; Figure 10 This is a structural diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the present invention.

[0033] It should be noted that, in the optional embodiments of the present invention, the data related to object information, etc., requires the permission or consent of the object when the embodiments of the present invention are applied to specific products or technologies. Furthermore, the collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of the present invention involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0034] The terms "including" and "having" in the specification and accompanying drawings of this invention, and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0035] To better understand and explain the solutions of the embodiments of the present invention, some technical terms involved in the embodiments of the present invention will be briefly explained below.

[0036] API is the core object for encapsulation, retrieval, and invocation in this invention.

[0037] LLM is the underlying artificial intelligence technology used in this invention in specific stages (such as AI-assisted generation of domain dictionaries, complex intent recognition, etc.).

[0038] OpenAPI (OpenAPI Specification) is an industry standard format that this invention follows when parsing and understanding interface structures.

[0039] DAG (Directed Acyclic Graph) is the core data structure used by the multi-tool planner of this invention to generate complex task execution plans.

[0040] NER (Named Entity Recognition) is a natural language processing technique used in this invention to extract key information (such as resource name, ID, etc.) from user input during the query preprocessing stage.

[0041] UUID (Universally Unique Identifier) ​​is a common resource identifier format in cloud platforms, and this invention can effectively identify and extract it.

[0042] HTTP (Hypertext Transfer Protocol) is the network communication protocol followed by the interface executor of this invention when it actually calls the cloud platform API.

[0043] JSON (JavaScript Object Notation) is the data exchange format used in this invention when processing API request bodies, response bodies, and generating structured tool cards.

[0044] LTR (Learning to Rank) is a machine learning technique used in this invention to optimize the candidate interface re-ranking model during the feedback and learning phase.

[0045] SLO (Service Level Objective) is a quantitative standard set by this invention to ensure the performance and reliability of backend services such as hot index updates.

[0046] To address the problems of selection difficulties, context window overload, high call costs, and difficulty in handling complex combined tasks when making API calls via natural language in environments with massive application programming interfaces, such as private cloud management platforms, this invention proposes a method and system for making natural language API calls to cloud platforms based on vector retrieval and multi-tool planning.

[0047] To enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0048] Next, we will describe in detail the cloud platform interface calling method, system, device, medium and product provided by the embodiments of the present invention.

[0049] This invention provides a cloud platform interface call method, such as... Figure 1 As shown, the method provided in this embodiment of the invention can be executed by an electronic device, which is a server. This server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, etc., but is not limited to these. The terminal device and electronic device can be directly or indirectly connected via wired or wireless communication. This embodiment of the invention does not impose any limitations on this connection. The method includes: S101. Obtain the query text input by the user; In the query analysis and vector retrieval layer, when a user enters a natural language query, i.e., query text, this layer is responsible for in-depth analysis and understanding of it, and then can retrieve the candidate interface that is most likely to meet the user's intent from the knowledge base.

[0050] In one feasible approach, the query analysis and vector retrieval layer includes a query preprocessing module capable of preprocessing the query text. This preprocessing includes, but is not limited to, any one or more of the following: standardization, synonym replacement, and terminology normalization. Understandably, raw user input is often unstructured, containing colloquial expressions, typos, or non-standard terminology. The query preprocessing module first performs a series of standardization operations on the input text, including: converting full-width characters to half-width characters, unifying capitalization, and removing extra spaces; then, it utilizes a domain dictionary for synonym replacement and terminology normalization, for example, uniformly converting virtual machines (VMs) into standardized terminology cloud hosts within the system.

[0051] S102. Determine several sub-query texts based on the query text. If the query intent corresponding to the query text is a single intent, then the several sub-query texts are the query text. If the query intent corresponding to the query text is a complex intent, then the several sub-query texts are multiple sub-query texts, and the multiple sub-query texts have an execution order. In this embodiment of the invention, after the user inputs the query text into the large language model, the cloud platform interface call method proposed in this invention is implemented based on the large language model.

[0052] In this embodiment of the invention, based on the different query intentions of the query text, it is determined whether a single interface should be executed directly, or whether a collaborative process involving multiple interfaces needs to be planned to complete the task. Several sub-query texts represent at least one sub-query text.

[0053] For a single intent, a single interface can be executed directly. Then, a candidate interface sequence can be determined based on the API vector index library. Subsequently, a structured tool card for the target interface in the candidate interfaces can be determined based on a single-step tool. This structured tool card is generated by filling the parameters of the target interface with preset structured content after the target interface is determined. Then, the task is executed based on this structured tool card to generate the result.

[0054] For complex intents, the query text can be split into multiple subtasks with dependencies. Then, based on these dependencies, the subquery text corresponding to the first subtask is executed first. The candidate interface sequence is determined using the API vector index library. Then, a structured tool card for the target interface is determined using a single-step tool. This structured tool card is generated by filling the parameters of the target interface with preset structured content after the target interface is determined. The task is then executed based on this structured tool card. Then, the second subtask is executed, and so on, until all subtasks are completed.

[0055] S103. Based on the application programming interface vector index library, determine the target interface corresponding to the subquery vector of the subquery text, and based on the relevant fields of the target interface, determine the structured tool card of the target interface; wherein, the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; In related technologies, using massive API documents as context consumes huge amounts of computing resources (Tokens), leading to a sharp increase in the cost and response time of a single call, making it difficult to meet the economic and real-time requirements of enterprise applications.

[0056] In this embodiment of the invention, an API vector index library is set up in the knowledge and interface index layer. Specifically, before obtaining the query text input by the user, the method further includes: extracting the key text information of each of the multiple interface definition files; using a text embedding model to convert the key text information into semantic vectors; and constructing an application programming interface vector index library based on the semantic vectors and the corresponding key text information.

[0057] The API vector index is the core of semantic retrieval. An interface document parsing module reads and parses industry-standard interface definition files, such as the OpenAPI specification document (a standardized format for describing RESTful APIs). The parsing module extracts key text information for each API endpoint, including but not limited to: The interface name (Operation ID) is typically a unique identifier that summarizes a certain function; the interface summary and description provide a detailed textual description of the interface's function and are the most important source of information for understanding the interface's intent; the interface path and request method (Method), such as / servers / {server_id} / reboot and POST, define the resource location and operation type; parameters include parameter name, description, data type, and whether they are required; request and response examples provide specific input and output format examples for the interface call. To ensure context efficiency, usually only examples of required parameters and one most commonly used optional parameter are retained. After extracting the key text information, a text embedding model, such as a language model based on the Transformer architecture, is used to jointly or independently convert the key text information of each interface into a high-dimensional floating-point vector, i.e., a semantic vector; the semantic vectors of all interfaces and their key text information are stored in the API vector index. Of course, the content stored in the API vector index may also include basic search identifiers (such as interface ID, service domain, etc.).

[0058] The API vector index library can be deployed locally in a private cloud environment to ensure data privacy and security. To further optimize retrieval efficiency and accuracy, the API vector index library also supports logical partitioning by service domain or the construction of multiple sub-indexes. For example, all interface vectors related to cloud host management can be stored in one partition, while those related to network management can be stored in another. This allows the search scope to be limited to the relevant sub-indexes when processing domain-specific queries, thereby avoiding the performance overhead and noise interference caused by global searches.

[0059] Furthermore, determining the service domain to which an interface belongs is primarily based on the following key textual information in the interface definition file: 1. Interface Tags: In standard specifications such as Open APIs, interfaces typically include Tags fields specifically for business classification (e.g., directly labeled as cloud host management or security group management). This is the most direct and primary basis for determining the service domain. 2. Interface Path: The unified resource path structure of an interface usually implicitly indicates its service domain affiliation. The basic prefix or core resource terminology of the path (e.g., compute or servers in the path / v1 / compute / servers) can clearly indicate the specific microservice or resource pool to which it belongs. 3. Interface Summary and Description: Domain-specific entity terms contained in the detailed text can assist the system in inferring and confirming which logical service domain the interface belongs to through rules or classification models.

[0060] The subquery text is then fed into the same text embedding model used when building the API vector index, generating a subquery vector. The vector retrieval function then uses this subquery vector as input to perform a similarity search within the API vector index.

[0061] In one feasible implementation, a predetermined number of candidate interface sequences with the highest similarity scores are selected from the application programming interface vector index based on a subquery vector, and then the candidate interface with the highest similarity score in the candidate interface sequence is selected as the target interface. In another feasible implementation, a predetermined number of candidate interface sequences with the highest similarity scores are selected from the application programming interface vector index based on a subquery vector; a re-ranking score is determined for each candidate interface based on its similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate; then the candidate interface with the highest re-ranking score in the candidate interface sequence is selected as the target interface. Users can choose either of the above methods according to their actual needs; this embodiment of the invention is not limited thereto.

[0062] The interface with the highest score in the candidate interface sequence is selected as the target interface. Then, based on the relevant fields of the target interface, a structured tool card for the target interface that follows the tool card minimization protocol is generated.

[0063] Specifically, when generating tool cards, information from three sources is used to populate the structured template: key text information extracted from the parsing module (vector index library payload): such as the interface's unique identifier (tool_id), the service domain it belongs to, a functional summary, and representative examples; non-semantic additional information from the metadata database: such as the list of required parameters (required_params) and the permission tags required for the call (permission_tags); and candidate values ​​(scores) from the sorted target interfaces.

[0064] The tool card minimization protocol aims to provide only the most critical information to large language models or subsequent processing units, and strictly prohibits the inclusion of lengthy texts such as the full Swagger in the processing flow.

[0065] The protocol stipulates that tool cards are of fixed length (e.g., ≤5KB) and contain only the following fields: tool_id: a unique identifier for the interface; service_domain: the service domain to which it belongs; summary: a functional summary (≤200 characters); required_params: a list of required parameters, including name and description (≤80 characters / item); permission_tags: an array of permission tags required for the call; repr_example: a representative example, strictly containing only required parameters and one most commonly used optional parameter (≤400 characters); score: the score after candidate re-ranking (re-ranking is used as an example here); hints: hints or constraints for subsequent steps (≤120 characters).

[0066] The following is an example of the JSON Schema for its structured tool cards: json { "tool_id":"string", "service_domain":"string", "summary":"string(<=200chars)", "required_params":[ {"name":"string","desc":"string(<=80chars)","type":"string|enum|uuid|ip|int"} ], "permission_tags":["role:net.read","scope:server.list"], "repr_example":{"method":"GET","path":" / servers","query":{"os":"centos","limit":50}}, "score":0.0, "hints":"string(<=120chars)" }

[0067] The card will be passed to the subsequent execution layer.

[0068] S104. Based on the structured tool card corresponding to the subquery text, generate a call request, which is used to call the target interface.

[0069] This step is implemented through the execution and composition layer. The execution and composition layer is responsible for actually executing the interface calls and processing and presenting the returned results. All external responses from the execution and composition layer follow a unified structure: {ok,data,meta{trace_id,retries,pages,rate_limit},error{code,msg},suggestion}, forming a reusable external protocol.

[0070] In this embodiment of the invention, the interface executor of the execution and synthesis layer receives tool cards or multi-tool execution plans from the decision layer and converts them into specific HTTP requests.

[0071] In one feasible implementation, the various subquery texts in this invention may have dependencies, i.e., they have a certain execution order. The multi-tool execution plan represents the structured tool cards corresponding to the subquery texts, which are issued sequentially according to the execution order.

[0072] by Figure 2 For example, the query intent of this query text is a complex intent. An execution plan is generated based on the query text. The execution plan includes multiple sub-task nodes with an execution order. The corresponding sub-query text can be determined based on the sub-task nodes. Figure 2 In the text, 1-9 represent sub-task nodes in sequence. Sub-task nodes correspond to sub-query texts. For example, sub-task node 1 corresponds to sub-query text 1', and sub-task node 2 corresponds to sub-query text 2'.

[0073] In this invention, structured tool cards can be generated based on subquery texts 1', 2', and 5', and their respective call requests can be generated to invoke the interface. Then, subquery texts 3' and 4' are executed, generating their respective structured tool cards and call requests to invoke the interface. Next, subquery texts 6' and 7' are executed, generating their respective structured tool cards and call requests to invoke the interface. Then, subquery text 8' is executed, generating its structured tool card and call request to invoke the interface. Finally, subquery text 9' is executed, generating its structured tool card and call request to invoke the interface.

[0074] That is, after constructing the structured tool card, it records which subquery texts can be executed concurrently and which need to be executed sequentially. Then, according to the execution order of these subquery texts, S102, S103, and S104 are executed. After the subquery texts have implemented their respective interface calls, the results of the interface calls of the subquery texts are aggregated to generate the response result.

[0075] Furthermore, the output of the preceding operation of the subquery text with dependencies can be used as the context of the following operation of the dependency, thus enriching the subquery text.

[0076] S105. After several subquery texts have implemented their respective interface calls, the results of the interface calls of the several subquery texts are aggregated to generate a response result.

[0077] Once all calls are successful, the result generator aggregates the results of all steps and synthesizes a clear and complete natural language response.

[0078] As can be seen, in this embodiment of the invention, the invention does not inject the descriptions of all API interfaces into the LLM context. Instead, it performs vector retrieval based on LLM, pre-converting multiple interface definition files into lightweight semantic vectors to build an index library. Furthermore, an intent analysis mechanism is introduced. At runtime, the user query is split into several sub-query texts based on the user intent. The vector of each sub-query text is matched with the API index library to locate the target interface, i.e., the corresponding structured tool card, and realize the interface call. After the interface calls of several sub-query texts are realized, the results of the interface calls of several sub-query texts are aggregated to generate the response result. This invention can eliminate the problems of inaccurate target interface filtering and low filtering efficiency caused by related technologies.

[0079] Furthermore, in one possible implementation of this invention, when generating an HTTP request based on the structured tool card corresponding to the subquery text, the following requirements can be made: Flow control: Strictly schedule tasks according to the DAG plan, manage dependencies, support parallelism, and use the output of the previous step as the input of the next step; Pagination strategy: Automatically process pagination data to ensure complete results are obtained; Rate limiting and retrying: Follow the server's rate limits and use an exponential backoff plus random jitter strategy for retrying; Default parameters are: initial backoff base=200ms, maximum backoff max=5s, backoff factor×2, jitter ±20%, maximum retries 3 times. This strategy is effective for 429 / 5xx error codes or network jitter; Idempotency guarantee: For all write operations, automatically generate and inject an idempotency key to prevent repeated execution from causing unexpected errors; Exception and permission mapping: Capture HTTP or business error codes and uniformly map them to standard error objects. In particular, for permission errors, suggestions will be provided to users on how to request permissions based on the suggestion guide; for compensation transactions, for multi-step write operation tasks, a compensation_map is maintained. When a sub-task node is marked compensable=true, if the sub-task node fails to execute, the corresponding compensation interface defined in the compensation_map will be called in reverse topology order.

[0080] Example as follows: json { "create_server":"delete_server", "attach_volume":"detach_volume", "open_port":"close_port" }

[0081] One possible implementation of this invention involves determining several sub-query texts based on query text, including: determining an intent detection result based on the query text; if the intent detection result is a single intent, then determining several sub-query texts as query texts; if the intent detection result is a complex intent, then generating an execution plan based on the query texts, the execution plan including multiple sub-task nodes with an execution order; and determining the sub-query text corresponding to each sub-task node based on the execution plan.

[0082] As can be seen, in this embodiment of the invention, intent detection is performed based on the query text. If it is a single intent, the query text is not split and is directly used as the unique sub-query text. If it is a complex intent, an execution plan is generated, which includes multiple sub-task nodes, and then the sub-query text corresponding to each sub-task node is determined.

[0083] One possible implementation of this invention involves determining an intent detection result based on query text, including: determining the structure signal score, semantic signal score, and entity signal score of the query text; determining the complexity score of the query text based on the structure signal score, semantic signal score, and entity signal score; determining the intent detection result as a complex intent if the complexity score of the query text is greater than a preset complexity threshold; and determining the intent detection result as a single intent if the complexity score of the query text is not greater than the preset complexity threshold.

[0084] This invention utilizes a hybrid detection model for complex intentions to achieve intention detection. Specifically, to accurately and sensitively identify multi-tool tasks, the model comprehensively evaluates signals across three dimensions (structure, semantics, and entity) to calculate a complexity score. When the score exceeds a preset complexity threshold, the planner is activated. The specific value of the preset complexity threshold can be set by the user according to actual needs.

[0085] The structural signals are identified through syntactic parsing, which uses logical connectors (such as "and," "then," and "after"), parallel structures, or adverbs indicating sequence in the query. Each structural connector is assigned a different weight based on its logical strength. Specifically, the system maintains a predefined mapping table of structural connectors. Based on linguistic rules and business experience, developers manually categorized common logical connectors and preset fixed static weights: High-strength (strong sequential dependency) connectors explicitly indicate multi-step tasks with sequential dependencies, thus receiving higher weights (e.g., preset weights of 0.8 or 1.0). Examples include "then," "after," "first step," and "second step." Medium-strength (parallel execution) connectors indicate the need to perform multiple actions, but not necessarily with strict sequential dependencies, thus receiving medium weights (e.g., preset weights of 0.5). Examples include "and," "simultaneously," and "as well as." Low-strength (weak connection or supplementary explanation) connectors may simply supplement parameters of the same action, receiving lower weights (e.g., preset weights of 0.2). Examples include "in addition" and "also." When processing queries, the system identifies structural words through syntactic analysis and then directly consults the mapping table to obtain the corresponding preset weights. It iterates through all extracted structural words in the user's query text, retrieves the weights corresponding to each structural word from the table, and then sums the weights (or takes the maximum value). Furthermore, to prevent excessively long sentences with many conjunctions from causing the score to increase indefinitely, the sum can be normalized (e.g., using the Sigmoid function to map to between 0 and 1, or setting a score upper limit). The final output is the structural signal score of the query text.

[0086] Entity signals utilize Named Entity Recognition (NER) technology to identify all resource entities contained in the query. The complexity score increases significantly when multiple entities are detected, especially when these entities belong to different service domains (e.g., cloud hosts belong to the compute domain, and firewall policies belong to the network security domain). The score is proportional to the number of cross-domain entities and the distance between domains.

[0087] Specifically, named entity recognition technology is used to extract all resource entities from the query text and determine their respective service domains. The number of identified entities belonging to different service domains is calculated. The degree of business or architectural differences between different service domains (i.e., inter-domain distance) is evaluated, which can be achieved by quantifying the distance weights between different domains (such as compute and network domains) using a service domain matrix. The number of extracted cross-domain entities is then forward-computed with their corresponding inter-domain distances. In other words, the more cross-domain entities identified, and the greater the difference (distance) between the domains to which these entities belong, the higher the final entity signal score.

[0088] For example, compute domains include virtual machines, containers, serverless functions, etc. Network domains include VPCs, subnets, load balancers, IP addresses, etc. Storage domains include cloud disks, object storage buckets, database instances, etc. Security domains include IAM roles, security groups, firewall rules, etc. If the query text is: "Start a virtual machine, mount a 100GB cloud disk, and associate it with the security group - web and VPC - production environment," the service domains corresponding to the existing entities are determined to be: the compute domain corresponding to the virtual machine, the storage domain corresponding to the cloud disk, the security domain corresponding to the security group - web, and the network domain corresponding to the VPC - production environment. The number of entities in the compute domain, storage domain, security domain, and network domain is 1 each. If the determined distance between the compute domain and network domain is 0.6, the distance between the compute domain and storage domain is 0.3, the distance between the compute domain and security domain is 0.8, the distance between the network domain and storage domain is 0.5, the distance between the network domain and security domain is 0.7, and the distance between the storage domain and security domain is 0.9.

[0089] Entity signal score = ,in, i and It represents the number of entities in domains i and j. It is the distance between these two domains. Then, calculate all combinations of different domains: computation and network, (1 1) 0.6 = 0.6; Calculation and storage, (1 1) 0.3 = 0.3; Calculation and security, (1 1) 0.8 = 0.8; Network and storage, (1 1) 0.5 = 0.5; Security and Networks, (1 1) 0.7 = 0.7; Security and storage, (1 1) 0.9 = 0.9; Final score = 0.6 + 0.3 + 0.8 + 0.5 + 0.7 + 0.9 = 3.8. The sum can also be normalized (e.g., using the Sigmoid function to map to a range of 0-1, or setting an upper limit threshold for the score, which can be set according to actual needs).

[0090] The semantic signal takes the user query text as input to a lightweight classification model finely tuned on single-intent / multi-intent corpora. The model outputs a multi-task probability between 0 and 1, which is directly used as the semantic signal score. This model is more focused and less costly than general-purpose large language models.

[0091] Therefore, the complexity score of the query text = w1 Structural signal score + w2 Entity signal score +w3 Semantic signal score. A weighted mechanism is employed to allow the detection model to tolerate colloquial expressions and to detect implicitly complex tasks that, while lacking explicit conjunctions, actually involve multiple operational steps, significantly improving recall and accuracy. Here, w1 is the structural weight, w2 is the entity weight, and w3 is the semantic weight; the values ​​of these three weights can be set based on practical experience. The preset complexity threshold can be set by the user based on practical experience; this embodiment of the invention does not limit it. When the complexity score of the query text is greater than the preset complexity threshold, it is considered a complex intent; otherwise, it is considered a single intent.

[0092] As can be seen, in this embodiment of the invention, the complexity score of the query text is determined by comprehensively considering the structural signal score, semantic signal score, and entity signal score of the query text, and then the accurate intent detection result is determined based on the complexity score and the preset complexity.

[0093] In one feasible approach, after a user inputs query text, it undergoes preprocessing such as standardization to obtain a processed query, and strong signals such as core entities are extracted as metadata. Based directly on the processed query and the extracted entity signals, a hybrid detection model is used to analyze and calculate a complexity score. The task complexity is determined based on the score. If the intent is complex, the query is first decomposed into multiple subqueries and an execution plan is constructed; if the intent is single, no decomposition is performed. Finally, for each specific subquery (or the original single-intent query), a query vector is generated, and candidate interfaces are obtained by searching the index. These candidate interfaces are then scored and sorted based on the strong signal metadata to obtain a final ordered list of interfaces.

[0094] One possible implementation of this invention involves generating an execution plan based on query text, including: performing syntactic analysis on the query text to determine the subtask dependencies of multiple subtask nodes; generating a structured subtask list of multiple subtask nodes corresponding to the query text based on the subtask dependencies; and generating a directed acyclic graph as the execution plan based on the structured subtask list.

[0095] In this embodiment of the invention, the query text can be decomposed based on syntactic dependencies and a rule base. If a complex intent is determined, a multi-tool task is employed, and the planner first performs a deep decomposition of the query text.

[0096] Among them, syntactic analysis is performed on the query text to construct the syntactic dependency tree of the query statement, which is also the subtask dependency relationship.

[0097] Specifically, this involves identifying the core verbs (representing operations) and their subject-verb-object, modifier-adverb-complement, and other relationships with nouns (representing resource entities). These relationships are primarily used to: extract operations and objects, clarify subtask dependencies, and generate structured task instructions. Extracting operations and objects uses subject-verb-object relationships to precisely pinpoint the actions the user wants to perform (core verbs) and the resource objects (nouns) that these actions affect; for example, identifying "create" as an action performed on a cloud host. Clarifying subtask dependencies involves using a syntactic dependency tree to reveal the logical order between actions; for example, creating and mounting a disk shows that mounting depends on the disk's creation, and the disk originates from the creation action, thus determining the logical sequence of task execution. Generating structured task instructions involves transforming these relationships into a structured list of subtasks containing metadata such as subquery tasks, intents, dependencies, and output placeholders. This structured list of subtasks provides precise logical input for subsequently building a directed acyclic graph (DAG) execution plan.

[0098] Furthermore, based on each subtask node in the structured subtask list, a directed acyclic graph is generated as the execution plan, referring to... Figure 2 .

[0099] Based on the dependencies of each subtask node in the structured subtask list, the topology of the execution plan is constructed. Each graph node (ExecutionNode), as a subtask node, not only contains subtask information but also reserves space for subsequent tool selection, parameter filling, retry strategies, and compensation logic.

[0100] Each graph node (ExecutionNode) in the execution plan (a dynamically constructed DAG topology) mainly contains or is marked with the following: Subtask information: Subtask nodes contain basic information about the subtasks decomposed earlier. Reserved logic space: Subtask nodes reserve space for subsequent tool selection, parameter filling, retry strategies, and compensation logic. Compensation operation marker: For write operation nodes with side effects (such as creation operations), they are explicitly marked as compensable=true, thereby triggering the system to generate a companion compensation plan for them.

[0101] This graph supports maximum parallel execution, meaning that all independent subtask nodes can be processed concurrently at the same level of the graph.

[0102] Furthermore, after performing syntactic analysis based on the query text to determine subtask dependencies, the process also includes: sorting and optimizing each subtask in the structured subtask list based on a first rule base. The first rule base represents a rule library containing best practices in areas such as listing before details, primary before subtasks, and query before modification. Even if syntactically ambiguous, the rule base will enforce that creating a cloud host task precedes binding an elastic IP to a cloud host task.

[0103] The first rule base was established through a combination of human experience and domain knowledge engineering: technical personnel summarized the general topological rules for API calls. Operation guidelines and resource dependency logic for various service domains of the cloud platform (such as compute, storage, and network) were transformed into computer-recognizable if-then rules. During operation, experts periodically calibrated and supplemented the rule base based on success / failure feedback from complex task execution. The core content of the dependency order criteria of the first rule base includes: operations on primary resources (such as creating a VPC) must be executed first, followed by operations on secondary resources (such as creating a subnet under a VPC); before performing modification or deletion actions, a query interface must be called to confirm the resource status; list first, details later: if the user does not provide a specific ID, the List interface must be called first to obtain the list, and then the Detail interface must be called according to the filtering conditions; logic optimization rules: used to correct logical deviations that may arise from syntactic analysis (e.g., even if the word order is reversed, the rule base will still force creation to be executed before binding); operation conflict avoidance: the order of mutually exclusive operations is defined to ensure that complex DAGs do not cause resource deadlocks during scheduling.

[0104] Once the DAG graph is obtained, which is also the execution plan, the execution plan can be a structured output. That is, the query text is ultimately decomposed and output as a list of subtasks containing richer metadata. Its format is [{subtask_id, subquery, intent, domain, required_entities, dependencies:[subtask_id_1,...], output_placeholder}]. Here, `dependencies` explicitly declares the IDs of the preceding tasks that the task depends on, while `output_placeholder` defines the key outputs that the task needs to obtain from the preceding tasks (such as `new_disk_id`), providing precise instructions for subsequent dependency analysis and data flow.

[0105] In this embodiment of the invention, an optimized execution plan for a directed acyclic graph (DAG) is dynamically generated based on the decomposed list of structured subtasks.

[0106] One possible implementation of this invention involves generating a directed acyclic graph (DAG) as an execution plan based on a structured subtask list. This includes: generating the DAG based on the structured subtask list; determining whether the DAG is a complex graph; if so, estimating the cost of different paths in the DAG based on dynamic statistical information stored in a metadata database to obtain the path with the lowest cost; the metadata database and the application programming interface (API) vector index library are associated through unique interface identifiers, the metadata database being constructed based on the metadata corresponding to each interface, which includes static information and dynamic statistical information; and updating the DAG based on the path with the lowest cost to update the execution plan.

[0107] In this invention, for complex DAGs, the planner can estimate the execution cost (time and resources) of different paths in the graph based on historical data in the metadata database (such as average interface latency and success rate). When multiple valid topology sorts exist, the system can select the path with the lowest cost to execute, achieving intelligent scheduling.

[0108] Specifically, the complexity of a DAG can be determined by the number of nodes and the characteristics of its topology.

[0109] When the number of subtask nodes N generated by the decomposed subtask list is greater than or equal to a preset node number threshold (which can be set according to actual needs, e.g., 3), it is usually defined as a complex DAG. Regarding topological characteristics: If the subtasks have a clear sequential order (e.g., subtask node a depends on the outputs of subtask nodes b and c), forming a non-linear execution path, it is determined to be a complex DAG. When there are multiple parallel branches with no dependencies in the DAG, resulting in multiple legal execution orders, the system will consider it a complex DAG and trigger the cost estimation function to select the optimal path. If the subtask nodes in the DAG involve multiple different service domains (e.g., computation domain and network domain), the complexity of their collaborative execution and data flow will increase significantly, and it is also considered a complex DAG.

[0110] After determining that the graph is complex, the cost of different paths in the directed acyclic graph is estimated based on the dynamic statistical information stored in the metadata database to obtain the path with the lowest cost.

[0111] Cost estimation is a quantitative assessment of each potential execution path of a DAG by the planner based on historical performance data, i.e., dynamic statistical information, stored in the metadata database.

[0112] In a DAG framework, different paths refer to all legal execution sequences that the system can arrange, provided that all topological ordering constraints are satisfied (i.e., all preceding dependent subtask nodes must execute before subsequent subtask nodes). Figure 2For example, the vertical arrows (such as subtask node 1, subtask node 4, and subtask node 7) represent inviolable timing constraints. When Figure 2 When there are multiple starting subtask nodes with an in-degree of 0, or when there are no direct / indirect dependencies between some subtask nodes, these subtask nodes can be scheduled to be executed at different times, thus forming different paths.

[0113] For example Figure 2 For example: Subtask node 1, subtask node 2, and subtask node 5 have no prior dependencies and belong to the first logical level. Subtask node 3 and subtask node 4 depend on subtask node 1 respectively and belong to the second level.

[0114] Path Difference Examples: Maximum Parallelism: {Subtask Node 1, Subtask Node 2, Subtask Node 5} start simultaneously until {Subtask Node 3, Subtask Node 4} start simultaneously until subsequent nodes. This scheme theoretically has the shortest total execution time. Step-by-Step Interleaving Scheme: First execute subtask nodes 1 to 3 (acquiring basic data), then interleave the execution of subtask nodes 2 and 5, and finally execute subtask nodes 4 to 7. Sequence-Constrained Scheme: If the system's concurrency is limited, subtask nodes 1, 2, and 5 must be queued in sequence (e.g., subtask node 1 to subtask node 2 to subtask node 5, or subtask node 5 to subtask node 2 to subtask node 1), resulting in various permutations and combinations. Due to the extremely high execution flexibility of subtask nodes 2 and 5, the system must determine, through cost estimation, which execution sequence (parallel / serial interleaving) achieves the optimal solution with the shortest overall execution time and lowest execution risk.

[0115] Furthermore, dynamic statistics can be filtered, using the time consumption and success rate within these statistics as evaluation factors. Specifically, time cost: calculate the sum of the historical average time consumption of all node interfaces on the path. For sub-task nodes that can be executed in parallel, the time consumption calculation takes the value of the longest-consuming (bottleneck sub-task node) in the parallel group. Resource / risk cost: weighted based on the reciprocal of the interface success rate; the lower the success rate of an interface, the higher its execution risk and potential retry cost.

[0116] The comprehensive scoring formula is: Cost = ∑[wt1·avg_time_i + ws2·(1 / success_rate_i)]. wt1 and ws2 are preset time and stability weighting coefficients; ∑ represents the summation over all sub-task nodes i in the path. avg_time_i represents the historical average time taken by sub-task node i, and success_rate_i represents the success rate of sub-task node i.

[0117] Furthermore, regarding metadata databases, which are relational or key-value databases containing complex, non-semantic structured information such as complete parameter structures, permission tags, and interface usage frequency statistics, etc.

[0118] Metadatabase storage is a relational or key-value database used to store non-semantic but decision-critical supplementary information for each interface, including: The static information extracted from the interface definition file mainly includes basic information, parameter structure, and permission tags, which are directly extracted during the initial parsing of interface definition files such as OpenAPI. The dynamic statistics recorded in the system operation log mainly refer to usage statistics, which are historical feedback data dynamically recorded and continuously accumulated during actual system operation and interface calls. Basic information includes, but is not limited to: interface ID, service domain name, and version number. Parameter structure includes a list of required / optional parameters and their data types. Usage statistics include historical data such as the frequency of interface calls, success rate, and error rate.

[0119] The metadata database and the application programming interface vector index are linked through unique identifiers for the interfaces (such as interface IDs). The stored metadata primarily includes: basic information (interface ID, associated service domain, version number); parameter structure (list of required parameters, list of optional parameters and their data types); permission tags (marking the user permission level or role required to call the interface, allowing for early filtering of interfaces that users are not authorized to access); and usage statistics (recording historical data such as the frequency, success rate, and error rate of interface calls, which can be used as dynamic weights for ranking candidate tools, prioritizing frequently used and reliable interfaces.

[0120] As can be seen, in this embodiment of the invention, when the directed acyclic graph is a complex graph, cost estimation of different paths can be performed, the path with the lowest cost can be selected, the execution plan can be updated, and the efficiency of interface calls can be improved.

[0121] One possible implementation of this invention, based on the lowest-cost path, after updating the directed acyclic graph, further includes: determining the target subtask node marked as a write operation in the execution plan; determining the compensation operation corresponding to the target subtask node; and adding the compensation operation as a compensation node to the compensation plan, wherein the execution order of the compensation plan is the reverse of the topological order of the corresponding nodes in the execution plan, and the compensation plan is used to roll back when the subtask in the execution plan fails.

[0122] This embodiment of the invention also includes a companion compensation plan. While generating the execution plan, the system generates a compensation plan in parallel. If a critical write operation fails during the execution of a complex task, the compensation operation ensures that the system has an atomic rollback path that requires no temporary computation. When a task fails, the system calls the interfaces defined in `compensation_map` in reverse topology order to undo previously successful steps (e.g., deleting a cloud host that was only partially created), thereby avoiding leaving incompletely configured invalid resources in the cloud environment and ensuring the atomicity of the operation.

[0123] For each write operation node marked as compensable=true in the execution plan (such as create_server), its corresponding compensating operation (such as delete_server) is looked up in the compensation_map and added as a compensating node to the compensation plan. The execution order of the compensation plan is strictly the reverse of the topological order of the corresponding nodes in the main plan. This ensures that the system has an atomic rollback path that does not require temporary computation in the event of a task failure, greatly improving the system's robustness and transaction consistency.

[0124] The compensation_map is a compensation transaction mapping specifically maintained by the system when handling multi-step write operations. It mainly includes the correspondence between the forward operation interface and its corresponding reverse rollback (compensation) interface. For example: create_server (create server) corresponds to delete_server (delete server); attach_volume (attach disk) corresponds to detach_volume (unattach disk); open_port (open port) corresponds to close_port (close port).

[0125] When generating the execution plan (Directed Acyclic Graph), the system identifies write operation nodes with side effects (such as create, mount, etc.) and explicitly marks them as `compensable=true`. For each marked write operation node, the system queries the pre-maintained `compensation_map` to find the rollback interface with the opposite action. For example, the compensation interface for `create_server` (create a cloud host) in the table is `delete_server` (delete a cloud host). The found compensation interface is added as a compensation node to the compensation plan running parallel to the main execution plan. When a critical node fails during the execution of the main execution plan, the system aborts the main plan and triggers the compensation plan. To safely undo successfully executed operations (especially those with sequential dependencies), the compensation plan must execute in a strictly reverse topological order from the main plan nodes. That is, the last successfully executed subtask will be rolled back first, and the first successfully executed subtask will be rolled back last. This ensures that the system has an atomic rollback path that requires no temporary computation.

[0126] For example, a user requests to create a cloud host, then create an Elastic Public IP (IP) and bind them. The main execution plan is built (forward topology order): Sub-task node d (executed in parallel) calls `createServer` to create the cloud host. Sub-task node e (executed in parallel) calls `createEIP` to create the IP. Sub-task node f (dependent on sub-task nodes d and e) calls `attachEipToServer` to bind the IP to the newly created cloud host. The compensation plan is triggered and executed (reverse topology order): Assuming that in actual execution, sub-task nodes d and e both execute successfully, and the cloud host and IP have been physically created. Then, when executing sub-task node f (the binding operation), a failure occurs. At this point, the compensation transaction mechanism is triggered. Since the forward topology order is to create sub-task nodes d and e first, and then bind sub-task node f, reverse execution means that the system will automatically delete the previously successfully created sub-task nodes: executing `deleteEIP(EIP_ID)` and `deleteServer(Server_ID)`. Ultimately, the newly created cloud host and elastic IP were automatically cleaned up by the system, the cloud platform was restored to the clean state before the user initiated the request, and an atomic failure result was reported to the user.

[0127] One possible implementation of this invention, after determining the subquery text corresponding to each subtask node based on the execution plan, further includes: injecting the execution result information of the previous node of each subtask node as a query context into the subquery text, and updating the subquery text corresponding to each subtask node.

[0128] In this embodiment of the invention, when matching a specific interface for each subtask node in the DAG, the process of vector retrieval-candidate rearrangement-single-step tool selection is not repeated in isolation, but a context-aware mechanism is adopted.

[0129] When assigning a tool to the Nth subtask node, information already executed or determined by the previous N-1 subtask nodes (such as the IDs of created resources, queried statuses, etc.) is injected into the query context of the current subtask node. For example, when processing the subtask of mounting a disk, its subquery is dynamically enriched to: Mount a disk for the server with ID srv-xxxx. This greatly reduces the search space of vector retrieval and can even directly locate the unique correct interface through metadata matching, thereby significantly improving the speed and accuracy of tool selection in subsequent steps. In this way, the multi-tool planner transforms a complex natural language problem into an execution plan composed of multiple atomic interface calls, with a clear structure, optimized path, and guaranteed transaction consistency.

[0130] Each subtask node corresponds to a query statement. When constructing the directed acyclic graph (DAG) execution plan, the multi-tool planner includes a subquery for each execution node that explicitly describes the task intent of that node. This subquery is a collection of initial subquery texts with a logical sequence, derived from the semantic analysis of the query statement.

[0131] Furthermore, it is also possible to dynamically inject / assemble / inject into the subquery context of the subtask node during execution.

[0132] For example, suppose the original query includes: create a virtual machine and then bind a new Elastic Public IP address to it. After Phase One, the initial action of sub-task node g might be binding the IP address. When sub-task node g is executed in Phase Two, the system detects that sub-task nodes h (creating the virtual machine) and m (creating the IP address) have completed and output their respective IDs, so it injects them. The query statement for sub-task node g is then dynamically enriched to: bind [output of sub-task node m: EIP_ID] to [output of sub-task node h: Server_ID]. In this way, the originally ambiguous query becomes a highly specific instruction, thereby significantly improving the accuracy of subsequent vector retrieval and interface matching.

[0133] In this embodiment of the invention, the user's complex natural language is deeply decomposed to clarify the logical dependencies of the tasks and construct a directed acyclic graph (DAG). At this time, the sub-task nodes of the DAG store the decomposed sub-query text (e.g., creating a cloud host named web-server-01).

[0134] One possible implementation of this invention involves determining the target interface corresponding to the subquery vector of a subquery text based on an application programming interface (API) vector index library. This includes: extracting query metadata from the subquery text; generating a subquery vector from the subquery text; selecting a predetermined number of candidate interfaces with the highest similarity scores from the API vector index library based on the subquery vectors; determining a rearrangement score corresponding to the candidate interfaces based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate; wherein, metadata matching degree represents the matching degree between the query metadata and the corresponding parameters of the candidate interfaces; permission availability is the calling interface permission score of the candidate interfaces determined from the metadata database; interface usage frequency and error rate are the parameters of the candidate interfaces determined from the metadata database; sorting the predetermined number of candidate interfaces based on the rearrangement score to obtain a sequence of candidate interfaces corresponding to the subquery text; and determining the target interface based on the sequence of candidate interfaces corresponding to the subquery text.

[0135] In this embodiment of the invention, the query preprocessing module of the query analysis and vector retrieval layer can also be equipped with a signal extractor. Using regular expression or named entity recognition (NER) technology, it actively identifies and extracts key information with a clear format or type from the query text as query metadata. This metadata, along with the subsequent vector retrieval results, is used for the accurate ranking of candidate interfaces. The extracted key information includes, for example, IP address (e.g., 192.168.1.10), UUID (universally unique identifier, e.g., a4b6-...), resource status (e.g., running), time range, etc.

[0136] In one feasible approach, a preset number of candidate interfaces with the highest similarity scores can be directly selected from the application programming interface vector index based on the subquery vector.

[0137] In another possible implementation, a predetermined number of candidate interfaces with the highest similarity scores are selected from the application programming interface vector index based on the subquery vector. This includes: determining the service domain of the subquery text based on the subquery text; and selecting a predetermined number of candidate interfaces with the highest similarity scores from the sub-indexes corresponding to the service domains of the subquery text in the application programming interface vector index.

[0138] The search process can be divided into coarse selection and fine ranking. Coarse selection means that if the subquery text contains at least one explicit service domain clue (such as words like "network" or "disk"), or if the intent domain of the query is determined through a lightweight classification model, the search scope will be limited to the corresponding service domain sub-index. Fine ranking means that in the selected sub-index or global index, the cosine similarity between the query vector and all interface vectors is calculated. The top K interfaces with the highest similarity scores are returned as candidate interfaces. The K value of Top-K can be set to 5.

[0139] Furthermore, before selecting a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index based on the subquery vector, the process also includes: determining the preset number based on the complexity score of the query text; the complexity score of the query text is a score determined based on the structural signal score, semantic signal score, and entity signal score of the query text.

[0140] The preset number can be adaptively adjusted based on the complexity score. For complex or multi-domain queries, K=5 is used to ensure recall; for single-domain queries with clear signals, the number is narrowed to K=3 to improve efficiency.

[0141] Understandably, relying solely on vector similarity can sometimes lead to bias. Therefore, after selecting a predetermined number of candidate interfaces with the highest similarity scores, a candidate re-ranking process can be performed to further refine the Top-K candidate interface list returned by vector retrieval, generating a more reliable order.

[0142] In this invention, the reordering scoring mechanism can be: Score = α·cos_sim + β·param_coverage + γ·permission + δ·usage_freq - ε·err_rate.

[0143] `cos_sim`: Vector similarity score, representing the basic semantic matching degree. `param_coverage`: Metadata matching degree, checking whether the strong signals extracted during query preprocessing match the parameter requirements or path patterns of candidate interfaces. The parameter requirements or path patterns of candidate interfaces include: Parameter requirements: The content of relevant parameters of candidate interfaces stored in the metadata database, i.e., the list of required parameters, the list of optional parameters, and their data types, used to accurately verify whether the extracted strong signals can meet the conditions for interface calls. Path patterns: Mainly refers to the content in the application programming interface vector index library, where the library extracts and saves the interface path (e.g., ` / servers / {id}`) during construction and parsing, used for preliminary matching of specific format data or resource identifiers extracted in the query. `permission`: Permission availability, querying the metadata database to negatively penalize or directly filter interfaces that users do not have permission to call. `usage_freq / err_rate`: Data on interface usage frequency and error rate from the dynamic statistics of candidate interfaces stored in the metadata database, providing positive incentives for more frequently used and reliable interfaces, and penalizing interfaces with high error rates. This data is based on statistics from the last N=1,000 calls or the last 7 days using a sliding window; exponential smoothing is used for new interfaces to protect against cold starts. Default coefficients: α=0.55, β=0.20, γ=0.15, δ=0.10, ε=0.30. ε is an independent negative penalty coefficient for the error rate (err_rate), used to deduct the corresponding penalty points from the total score; therefore, it is not included in the normalized summation of the preceding basic weights.

[0144] Then, based on the rearrangement score, a preset number of candidate interfaces are sorted to obtain a sequence of candidate interfaces corresponding to the subquery text.

[0145] Furthermore, in one possible implementation of this invention, after determining the re-ranking score corresponding to a candidate interface based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate of the candidate interfaces, the method further includes: if the highest re-ranking score among the re-ranking scores of a preset number of candidate interfaces is lower than a preset re-ranking score threshold, a clarification question is generated; after the user inputs supplementary information based on the clarification question, the re-ranking score is re-determined; if the highest re-ranking score among the re-ranking scores is lower than the preset re-ranking score threshold, a prompt message is generated; if the highest re-ranking score among the re-ranking scores is not lower than the preset re-ranking score threshold, the step of sorting the preset number of candidate interfaces based on the re-ranking score to obtain the candidate interface sequence corresponding to the sub-query text is performed.

[0146] In this embodiment of the invention, a preset re-ranking score threshold is set. This threshold can be set according to actual needs; for example, τ = 0.62 (this value can be fine-tuned for different service domains, typically within the range of 0.58–0.68). After all candidate interfaces are comprehensively scored, the system obtains a final ordered list. When max(Score) < τ, the system generates a one-time clarification question; after the user provides supplementary information, the system will only retry once. If the recalculated score is still < τ, no matching result is returned, and relevant suggestions are provided, rather than blindly selecting the wrong tool.

[0147] In one specific implementation, the user's input natural language query statement is obtained. The original statement undergoes query preprocessing, terminology standardization, and key entity strong signals are extracted. The entity signals extracted during preprocessing, along with structural and semantic signals, are combined to determine if it represents a complex intent. If not a complex intent (single-step task), vector retrieval and candidate rearrangement are performed based on the preprocessed query to determine a candidate interface sequence. A single-step tool card is then identified and generated. If the intent is complex (multi-step task): the query is decomposed and a Directed Acyclic Graph (DAG) is constructed. For each sub-task node in the DAG, a highly specific node query statement is constructed by injecting context. For the query statement of that sub-task node, underlying capabilities are reused to perform vector retrieval and candidate rearrangement. A tool card is identified and generated for that sub-task node. Parameters are completed for that sub-task node, and the process is strictly scheduled according to the DAG topology.

[0148] One possible implementation of this invention involves the following: the relevant fields of the target interface include key text information, metadata information, and candidate values; based on the relevant fields of the target interface, a structured tool card for the target interface is determined, including: determining the key text information of the target interface from the application programming interface vector index library; determining the metadata information of the target interface from the metadata database; and determining the structured tool card of the target interface based on the key text information, metadata information, and candidate values ​​of the target interface.

[0149] Here, the candidate value represents the score when selecting the target interface from the candidate interface sequence. If the selection criterion is interface similarity, then the candidate value is the similarity score; if the selection criterion is the rearrangement score, then the candidate value is the rearrangement score.

[0150] Furthermore, in one possible implementation of this invention, after determining the structured tool card of the target interface based on the key text information, metadata information, and candidate values ​​of the target interface, the method further includes: automatically filling in missing parameters in the structured tool card based on the query metadata and enumeration information of the target interface; wherein, the query metadata is data extracted from the sub-query text of the target interface, and the enumeration information is information corresponding to the target interface determined from the enumeration table; after automatic filling, if there are missing required parameters, then according to the preset question template, a completion prompt for all missing required parameters is generated; and the structured tool card is filled based on the completion information input by the user.

[0151] After identifying the target API to be called, its parameters need to be filled in. The parameter completion module is responsible for clarification and maximizing information gain in one go.

[0152] In this embodiment of the invention, the parameters are filled in preferentially using strategies such as query metadata extracted by query preprocessing, context mapping, enumeration matching, and default value filling.

[0153] Specifically, for missing required parameters, the system generates completion suggestions for all missing required parameters according to a preset question template. This includes: sorting the missing required parameters according to their information gain values; and generating completion suggestions for all missing required parameters sequentially using the preset question template based on the sorting results. The information gain value is determined based on the information content and filtering capability of the required parameters.

[0154] This invention can also, after trying all autofill strategies, if multiple required parameters are still missing, estimate the information gain (IG) based on the information gain, sort the missing parameters by IG value from high to low, and then use a preset question template to generate a question containing all the information to be completed, which is then asked to the user all at once. The top 1 to 2 IG values ​​are selected to form the question.

[0155] The IG estimation method aims to intelligently determine which piece of information to ask first when multiple pieces of necessary information are missing, in order to achieve the most efficient clarification. The system calculates the corresponding Information Gain (IG) value for each missing parameter and selects the one with the highest score for questioning. This IG value is weighted by information content and filtering capability. Information content (the structural term) is used to assess how much uncertainty clarification of the parameter eliminates. If a parameter has a wide potential range of values ​​(e.g., selecting a server name from hundreds of instances), determining its value eliminates a large number of possibilities, resulting in high information content and a high score. Conversely, if the range of values ​​is narrow (e.g., a yes / no option), the score is low.

[0156] Specifically, the process of determining the information content (structure item) score includes: when a required parameter is found to be missing, the system queries the local metadata enumeration table or requests the cloud platform interface in real time to obtain the total number of valid values ​​for the parameter in the current business context, and records this total number as N. In order to quantify and eliminate uncertainty, the system adopts a simplified calculation model of information entropy. The specific score calculation formula is: score = log2(N). For example, if the missing parameter is the server name, the system finds that there are 256 server instances available under the current user's permissions, i.e., N = 256. Substituting into the formula, the information content score of the parameter is calculated as log2(256) = 8. If the missing parameter is whether to enable the public IP, the system recognizes that the parameter only has two fixed enumeration values, i.e., N = 2. Substituting into the formula, the system calculates that the information content score of the parameter is log2(2) = 1.

[0157] The filtering capability (constraint) is based on historical data, evaluating the effectiveness of this parameter in narrowing down the candidate tool pool through past interactions. Historical data refers to detailed logs of the entire natural language query processing process and basic interface usage statistics, including past user query statements, the system's intermediate decision-making processes, successful query-interface pairings, and quantitative indicators such as the call frequency, success rate, and error rate of relevant interfaces. If history shows that once a certain parameter (such as operating system type) is clearly defined, it can efficiently filter out a large number of irrelevant tools, proving its strong filtering capability and resulting in a higher score. Specifically, historical session samples containing the missing and complete processes of this parameter are retrieved, and the average reduction in the size of the candidate tool pool (or the proportion of irrelevant interfaces excluded) after filling in the parameter value is directly calculated. The higher this proportion, the stronger the parameter's effectiveness in eliminating ambiguity and converging the target in actual business operations, thus the system assigns it a higher filtering capability (constraint) score.

[0158] The two scores are weighted and summed to obtain the overall IG score. Based on the calculated IG score, all missing parameters are sorted from highest to lowest. The top 1-2 parameters in terms of IG score (Top-1-2) are selected, and a question containing the missing information is generated using a preset question template and presented to the user all at once. Through this calculation and sorting mechanism, the system can quickly identify the user's intent, effectively avoiding unnecessary or redundant follow-up questions.

[0159] One possible implementation of this invention involves extracting the enumeration values, core entities, and terms from multiple interface definition files; inputting a large language model based on the core entities and terms to determine the synonyms corresponding to the core entities and terms, as well as the mapping between abbreviations and full names; generating standardized definitions based on the core entities and terms, synonyms, and abbreviations; expanding the vocabulary using expert review, the expanded vocabulary including synonyms, abbreviations, and standardized definitions; constructing an enumeration table based on the enumeration values ​​from multiple interface definition files; and constructing a domain dictionary based on the core entities and terms and the expanded vocabulary.

[0160] To address the limitations of pure vector retrieval in handling specific entities, terms, or states, this layer also constructs and maintains a domain dictionary and enumeration table. Its construction process is a semi-automated workflow combining automated extraction, AI-powered expansion, and expert review.

[0161] The system leverages the capabilities of the API documentation parsing module to systematically extract structured information from specification documents such as OpenAPI as the foundation for its dictionary. Structured information specifically refers to fine-grained, formatted data fragments used to construct the domain dictionary. Specifically, this includes the two items listed below this paragraph: enumeration values, a list of enum fields and their default values ​​defined in the API component (e.g., a status dictionary); and core entities and terms, specific nouns extracted from API paths, tags, and object definitions (e.g., resource names).

[0162] The process involves parsing the components / schemas section of the interface definition file, automatically identifying and extracting all fields marked as enum and their default value lists. For example, the status of a cloud host can be active, shut off, or error. Core nouns and terms are extracted from multiple dimensions of the API, primarily from: resource names in the interface path (e.g., ervers in / servers / {id}), interface tags (e.g., cloud host management), and object names in the component definitions (components / schemas) (e.g., Server, Subnet). These extracted terms form the seed vocabulary of the domain dictionary. Core entities refer to the core resource objects or physical / logical components that are specifically managed and operated in the cloud platform's business logic, such as the concrete things or conceptual entities like servers (servers / cloud hosts) and Subnet (subnets) mentioned in the documentation. The terminology list refers to the collection of extracted nouns and terms within a specific domain.

[0163] The core entities and terminology list extracted in the previous step are fed into a large language model (LLM). Through carefully designed prompts, the model is instructed to perform the following tasks, exponentially enriching the dictionary: Synonym generation: generating common synonyms, near-synonyms, or colloquial expressions for each core entity. For example, for cloud hosts, the model will generate virtual machines, VMs, servers, etc. Abbreviation-to-full name mapping: identifying and generating the correspondence between common abbreviations and their full names in the domain, such as EIP corresponding to Elastic Public IP and VPC corresponding to Virtual Private Cloud. Standardized definitions: generating a concise, standardized definition for each core term for subsequent possible disambiguation or document generation. The domain dictionary and enumeration table are constructed using the above methods.

[0164] Furthermore, the AI-generated content will be presented in a structured format (such as JSON) to domain experts or development engineers for final review. Experts are responsible for correcting any errors that the AI ​​may produce, supplementing specialized terminology for specific business scenarios, and ultimately confirming the accuracy and completeness of the dictionary.

[0165] Through the above process, the system constructs a comprehensive and structured domain knowledge base. This dictionary is not only used for synonym replacement and terminology standardization in the query preprocessing stage, but also plays a crucial role in the automatic parameter filling stage, ensuring that the system can accurately extract precise values ​​from natural language that meet the interface requirements. For example, when a user asks about the status of my virtual machine, the system can use the dictionary to know that virtual machine is a synonym for cloud host, and that its status must be one of several predefined enumerated values.

[0166] In one possible implementation of this invention, to ensure the continuous availability and performance evolution of the system, this invention also designs a background hot update and monitoring layer with quantitative indicators. This layer can realize index update services, usage feedback and learning.

[0167] For the index update service, the cloud platform's interfaces change with version iterations. In this embodiment of the invention, it also includes: automatically and incrementally updating the API vector index library, domain dictionary, and metadata database storage by listening for change events in the interface definition file. Furthermore, this process has clear Service Level Objectives (SLOs): Index building SLO ≤ 5 minutes / 10,000 interfaces; Blue-green switching SLO ≤ 1 second; Failure rollback SLO ≤ 10 seconds to complete traffic rollback.

[0168] For the use of feedback and learning, this embodiment of the invention further includes: recording the entire processing process of each natural language query as feedback data; iteratively training the candidate reordering module using the feedback data; fine-tuning the text embedding model when the number of high-quality query-interface pairings in the feedback data exceeds a preset pairing threshold and the first-result hit rate is lower than a preset hit threshold; monitoring key indicators and issuing an alert when the key indicators exceed the corresponding alarm thresholds. The preset pairing threshold, preset hit threshold, and alarm threshold can all be set according to actual needs.

[0169] The feedback data mainly refers to the anonymous, end-to-end query and execution lifecycle logs recorded in detail by the system, specifically including: the user's original natural language query statements, process data, result data, and indicator data.

[0170] Process data represents the decision context generated in the system, such as extracted strong signals (entities, enumeration values), the Top-K candidate interface list retrieved by vector retrieval, and initial scores. Result data represents the ultimately successfully executed query-interface pairing records (i.e., high-quality positive samples), or records that triggered compensation mechanisms or failed to execute (negative samples). Metric data represents whether a one-time clarification was triggered, whether the clarification was successful, the time taken for the interface call (latency), the amount of token consumed, and the specific error code, etc.

[0171] The feedback data is used as training samples to retrain a lightweight learning-to-rank model periodically (e.g., weekly). The lightweight learning-to-rank model continuously optimizes the system's candidate re-ranking module, improving the accuracy of tool selection (first-place hit rate). Initially, re-ranking is based on manually set static weights (e.g., α·cos_sim + β·param + ...). This model dynamically adjusts the scoring mechanism by continuously learning from feedback data, reducing the probability of large language models producing illusions. Furthermore, this embodiment of the invention includes an automatic rollback mechanism; if the new model's online performance declines, it automatically switches back to the old version.

[0172] For fine-tuning of the embedding model, when enough high-quality query-interface pairing data is accumulated (e.g., more than 10,000 records) and the first-result hit rate is lower than a certain threshold, fine-tuning of the text embedding model is triggered to improve the recall accuracy of the vector database in the coarse-ranking stage.

[0173] For monitoring and alarms, key metrics are integrated into the dashboard, with alarm thresholds set. The list of key dashboard metrics includes, but is not limited to: Selection layer: Top-K coverage, first-order hit rate, clarification trigger rate, clarification success rate on the first attempt, and parameter auto-completion rate; Performance layer: end-to-end P50 / P95 latency and average total tokens; Result layer: selection accuracy, task completion rate, execution error rate (including permission error rate), and compensation transaction trigger rate; System layer: index building time and switching time.

[0174] Furthermore, in this embodiment of the invention, the following requirements can be met: Top-K ≤ 5; tool cards ≤ 5KB; examples in the cards strictly contain only required parameters + 1 optional parameter; and Few-shot template caching is used for high-frequency service domains. Subsequently, A / B testing is performed: a task set containing at least 200 real-world scenario triples is constructed. The task set is constructed using stratified sampling: 40 tasks each by service domain (compute / network / storage / monitoring / security) and task type (query / statistics / change). This set must include at least 30 complex task subsets (composite tasks with ≥3 sub-task nodes in a DAG), and their completion rates are reported separately. Regular comparisons are performed with the baseline system, with core metrics being average total token consumption, average end-to-end latency, and task accuracy / completion rate. The bootstrap method is used to calculate the 95% confidence interval (CI).

[0175] Based on any of the above embodiments, see Figure 3 The core idea of ​​this invention lies in constructing an interface knowledge base based on vectorized representation. Through semantic similarity retrieval, it efficiently filters a small number of highly relevant candidate interfaces from a massive global interface set based on user-input natural language queries. Then, through an intelligent decision-making and planning layer, it precisely selects, fills in parameters, and even combines and arranges these candidate interfaces, ultimately transforming them into precise calls to one or more specific interfaces at the cloud platform's underlying layer. This method not only significantly reduces the contextual burden and computational overhead of large language models during the tool selection phase but also endows the system with the ability to understand and execute complex, multi-step tasks through a multi-tool planning mechanism.

[0176] The system proposed in this invention can be divided into five core layers, from bottom to top: the knowledge and interface index layer, the query analysis and vector retrieval layer, the tool decision and parameter generation layer, the execution and synthesis layer, and the hot update and monitoring layer that runs through all layers. This layered architecture ensures that the responsibilities of each part of the system are clear, highly decoupled, and easy to expand and maintain.

[0177] See Figure 4 , Figure 4 This is a structural diagram of the knowledge and interface index layer provided in the embodiments of the present invention.

[0178] The knowledge and interface index layer includes: an API vector index library for automatic parsing of OpenAPI specification documents; extraction of name, summary, path, and parameters; generation of semantic vectors based on text embedding models; privatization and local deployment of the vector database; construction of sub-indexes by service domain partitioning; and support for efficient similarity retrieval and filtering. A domain dictionary and enumeration table are used for automatic extraction of enumeration values ​​and core entity terms; AI-assisted generation of synonyms and abbreviation mappings; expert review and calibration for human-machine collaborative construction; support for terminology standardization and disambiguation; and automatic parameter filling and precise value extraction. The metadata database is a relational / key-value database used to store interface IDs, service domains, and version numbers; setting parameter structures, including required / optional lists and types; setting permission tags, user permission levels or roles; usage statistics such as frequency, success rate, and error rate; and association with the vector index library via IDs.

[0179] See Figure 5 , Figure 5 This is a structural diagram of the query analysis and vector retrieval layer provided in the embodiments of the present invention.

[0180] The query analysis and vector retrieval layer includes: The query preprocessing module has the following functions: standardization, full-width and half-width characters, and case-sensitive matching; domain dictionary synonym replacement and normalization; signal extractor, regular expression, NER; identification of IP, UUID, status, and time range; and strong signals as metadata for accurate sorting.

[0181] The vector retrieval tool has the following functions: query text embedding to generate query vectors; coarse selection of service domains and fine ranking of similarity; cosine similarity calculation to return Top-K candidates; K=5 for complex queries and K=3 for simple queries; adaptive adjustment to ensure recall and efficiency.

[0182] The candidate rearrangement module has the following functions: multi-factor weighting: α·cos_sim+β·param_coverage+γ·permission+δ·usage_freq-ε·err_rate; default coefficients α=0.55, β=0.20, γ=0.15; low confidence threshold T=0.62 triggers clarification; permission awareness, interface usage frequency, and error rate penalties. The low confidence threshold can be set according to actual needs.

[0183] See Figure 6 , Figure 6 This is a structural diagram of the tool decision and parameter generation layer provided in the embodiments of the present invention.

[0184] The tool decision and parameter generation layer includes: The single-step tool router has the following functions: select the highest-scoring candidate interface to generate a tool card with a minimized protocol; the card is ≤5KB and contains required parameters + 1 optional parameter; strict fields: tool_id, summary, params, permission_tags, and repr_example.

[0185] The multi-tool planner has the following functions: hybrid weighted detection model activation; syntactic dependency analysis and rule base decomposition; dynamic DAG construction and cost optimization; associated compensation plan generation; and context-aware subtask allocation.

[0186] The parameter completion module has the following functions: automatic filling of strong signals; context mapping and enumeration matching; information gain (IG) estimation and sorting; one-time clarification of Top-1~2 IG parameters; and avoiding multiple rounds of follow-up questions to improve efficiency.

[0187] See Figure 7 , Figure 7 This is a structural diagram of the execution and synthesis layer provided in an embodiment of the present invention.

[0188] The execution and composition layer includes: The interface executor has the following functions: DAG task scheduling and parallel execution; paging strategy, rate limiting and retry; idempotency guarantee and permission mapping; compensating transactions: reverse topology rollback; exponential backoff + jitter: base=200ms, max=5s.

[0189] The results generator has the following functions: converting raw objects (raw JSON) into user-friendly answers; multi-task result aggregation and analysis; structured output and natural language synthesis; unified response protocol: ok, data, meta, error, including trace_id, retries, and rate_limit metadata.

[0190] See Figure 8 , Figure 8 This is a structural diagram of the hot update and monitoring layer provided in an embodiment of the present invention.

[0191] The hot update and monitoring layer includes: The index update service has the following functions: monitoring interface definition file changes; incrementally updating the index and metadata; blue-green switching ≤1 second | rollback ≤10 seconds; building Service Level Target (SLO): 5 minutes / 10,000 interfaces.

[0192] Using feedback and learning, it features: regular optimization of online learning ranking (LTR); fine-tuning of embedded models and automatic rollback; real-time monitoring dashboards and alerts; key metrics: hit rate, latency, and token consumption.

[0193] Specifically, this invention provides a method for calling natural language to cloud platform interfaces based on vector retrieval and multi-tool planning, including: Indexing steps: Parse the definition documents of multiple application interfaces in the cloud platform, extract semantic information for each interface including function description, path, and parameters, and use a text embedding model to convert the semantic information into semantic vectors, thereby building an API vector index library; Retrieval and Reordering Steps: Receive the natural language query input by the user, vectorize the query text, and perform a semantic similarity search in the API vector index to obtain a preliminary set of candidate interfaces; then, reorder the preliminary candidate interfaces through a comprehensive scoring model to generate an ordered final candidate interface list. The comprehensive scoring model considers at least the semantic similarity score and the matching degree between the entity information extracted from the natural language query and the interface parameters. Decision and planning steps: Analyze the intent complexity of the natural language query. If it is determined to be a single intent, select the highest-ranked interface from the final candidate interface list as the tool to be executed. If it is determined to be a complex intent, activate the multi-tool planner, decompose the natural language query into multiple sub-tasks with dependencies, and construct a directed acyclic graph for these sub-tasks as an execution plan. Parameter population and execution steps: For each subtask in the tool to be executed or the execution plan, automatically populate the parameters required for its call; after populating the parameters, call one or more corresponding APIs; and generate the final response to the user based on the API's return result.

[0194] Furthermore, based on any of the above embodiments, the embodiments of the present invention involve single-step tool invocation and multi-tool planning and execution.

[0195] The single-step tool invocation process can include: s1. The user inputs a natural language query. s2. The query analysis and vector retrieval layer performs query preprocessing and vectorization, retrieves Top-K candidate interfaces, and then performs permission-aware reordering. s3. If the highest score is lower than the confidence threshold τ, a one-time clarification process is initiated, and the user retries only once after supplementing the information. If the requirements are still not met, the process terminates. s4. Otherwise, the single-step tool router selects the interface with the highest score and generates a minimal tool card. s5. The parameter completion module attempts to automatically fill in all required parameters. If any are missing, a one-time clarification is performed. s6. If all required parameters have been filled, the tool card is handed over to the interface executor for invocation. s7. The result generator synthesizes the execution results into a unified response structure and returns it to the user.

[0196] The multi-tool planning and execution process can include: user input of complex natural language queries. The system, through rule or LLM analysis, determines it to be a multi-tool task and activates the multi-tool planner. The planner decomposes the query into multiple subqueries and generates an execution plan containing dependencies. For each sub-task node in the plan, the system executes steps s2 to s6 of the single-step tool call flow concurrently or sequentially. The interface executor schedules the interface calls of all sub-tasks according to the topological order of the execution plan and caches the intermediate results of each step. If any critical sub-task fails, it is handled according to a preset strategy (such as termination or compensation), and the error is logged. After all sub-tasks are successfully executed, the result generator aggregates all intermediate results, performs comprehensive analysis and summarization, and generates the final complex answer.

[0197] Furthermore, this invention includes exception handling and fallback strategies. When the highest score of a candidate interface is lower than a threshold τ, a clarification strategy is executed. If the score remains lower than τ after clarification and retry, the user is informed that the corresponding function cannot be found, and suggestions are provided.

[0198] During the candidate reordering phase, interfaces without sufficient permissions have been demoted or filtered. If permission errors still occur during the execution phase, the system will return a clear permission deficiency message and, according to the suggestion guide, advise the user to contact the administrator to request the appropriate permissions.

[0199] For failed nodes in a multi-tool plan, retries based on exponential backoff are supported. If the retries still fail, the plan can choose to terminate the entire task and report the failed node, or execute a compensation transaction to roll back the changes, depending on the strategy defined in the plan.

[0200] If core dependencies such as the vector database fail, the system can automatically downgrade to a traditional search method based on keyword matching to ensure the availability of basic functions.

[0201] Furthermore, in this embodiment of the invention, the entire system is designed to run on the customer's private cloud or local data center, ensuring that data does not leave the domain. Neither tool cards nor system logs contain the main text of sensitive business data input by the user; only necessary metadata and hashed parameter examples are retained. When recording user feedback data for model iteration, all information involving personal identity or sensitive business data is anonymized or desensitized. Each component of the system strictly adheres to the principle of least privilege during its own operation and when calling downstream interfaces on behalf of the user. All permission policies are configurable and auditable.

[0202] In summary, this invention effectively addresses the challenges of API calls from natural language to cloud platforms in massive API scenarios by constructing a layered, decoupled system that supports semantic retrieval and intelligent planning. It not only significantly improves the efficiency and accuracy of tool selection through vector retrieval and reduces reliance on large language models, but also achieves the understanding and automated execution of complex, multi-step tasks through a multi-tool planning mechanism.

[0203] Compared to existing technologies, this invention, through its unique system architecture and processing flow, brings the following significant benefits: This invention liberates large language models from the daunting task of sifting through thousands of APIs through a two-stage filtering mechanism of vector retrieval and metadata rearrangement. LLM only needs to make final decisions among a very small number (e.g., Top-5) of highly relevant candidate tools, greatly narrowing the context window and thus significantly reducing token consumption and computational latency. This translates to lower single-call costs and faster response times, making large-scale application in production environments possible. This invention decomposes natural language queries into directed acyclic graph execution plans and generates accompanying compensating transactions, enabling the system to understand and execute complex tasks. When the cloud platform adds or changes APIs, the index update service can automatically monitor the changes and seamlessly update the vector index library and metadata in an incremental, blue-green deployment manner, ensuring the system can continuously adapt to the rapidly iterating cloud environment. The design incorporates multi-layered fault tolerance and optimization mechanisms, ensuring the system performs more intelligently in the face of various anomalies. This invention supports fully private deployment, ensuring that all business data and API information remain on the enterprise intranet, resolving data privacy concerns associated with public cloud LLM services. The system adheres to the principles of data minimization and anonymization in logging, data transmission, and other processes, and is deeply integrated with the cloud platform's own permission system to ensure security.

[0204] This embodiment provides a specific example. The operations engineer enters the following command in the conversational terminal of the private cloud platform: I need to create a virtual machine named web-server-01, configured with 2 cores and 4GB of memory, using the CentOS 8 system, and then bind it to a new Elastic IP address with a bandwidth of 10Mbps.

[0205] Upon receiving the instruction, the system of this invention executes the following scheme: The knowledge and interface index layer is pre-built. Upon initial system deployment or cloud platform API version update, the knowledge and interface index layer automatically completes all preparatory work. It scans the OpenAPI documentation of all cloud platform services, extracting path, method, description, and parameter information from thousands of APIs such as createServer (create a cloud host), createEIP (create an Elastic Public IP), and attachEipToServer (bind an Elastic Public IP to a cloud host), converting them into semantic vectors and storing them in a locally deployed vector database. Simultaneously, a domain dictionary has been established, and the synonym relationships between virtual machines and cloud hosts, and between Elastic Public IPs and EIPs, have been recorded.

[0206] Query analysis and multi-tool planning. Upon input of the above commands, the query analysis and vector retrieval layer intervenes first. The query preprocessing module normalizes the virtual machine into a standard terminology cloud host. Simultaneously, the signal extractor utilizes Named Entity Recognition (NER) technology to extract multiple key entities: {Name: web-server-01, Configuration: 2 cores, 4GB memory, Operating System: CentOS 8, Resource Type: Elastic Public IP, Bandwidth: 10Mbps}.

[0207] The hybrid detection model of the multi-tool planner is triggered. Logical connectives indicating sequence are detected from the query, and two core resource entities (cloud host and elastic public IP) belonging to the compute and network domains are identified. The calculated complexity score far exceeds the threshold, indicating a multi-tool task, thus activating the multi-tool planner.

[0208] Query decomposition and dynamic programming. The planner performs syntactic dependency analysis on the query and, combined with the domain rule of "master first, sub-matter first," decomposes the task into a list of subtasks with dependencies. A directed acyclic graph (DAG) execution plan is generated: Subtask node p (in parallel) creates a cloud host. The corresponding subquery is to create a cloud host named web-server-01 with 2 cores, 4GB of memory, and a CentOS 8 system. Subtask node q (in parallel) creates an Elastic Public IP address. The corresponding subquery is to create an Elastic Public IP address with a bandwidth of 10Mbps. Subtask node h (dependent on subtask nodes p and q) binds the IP address. The corresponding subquery is to bind [output of subtask node q: EIP_ID] to [output of subtask node p: Server_ID]. Simultaneously, the system generates a contingency plan: if subtask node h fails, deleteEIP(EIP_ID) and deleteServer(Server_ID) are executed in reverse order.

[0209] Subtask Tool Selection and Parameter Population. Assign tools and populate parameters for each node in the DAG: Subtask node p: Performs vector retrieval on the subquery text "Create a cloud host named web-server-01, configured with 2 cores and 4GB memory, using CentOS 8 system". The createServer interface scores highest after candidate rearrangement. The parameter completion module automatically populates parameters from the extracted entities: name="web-server-01", flavor="2c4g", image="CentOS8". All required parameters are satisfied. Subtask node q: Performs vector retrieval on the subquery text "Create an elastic public IP with a bandwidth of 10Mbps". The createEIP interface scores highest. The parameter completion module populates the parameter: bandwidth=10. Subtask node h: Performs vector retrieval on the subquery text "Bind IP". The attachEipToServer interface scores highest. Its parameters server_id and eip_id are marked as dependent on the output of the preceding node and are temporarily left blank. The ellipsis indicates abbreviated specific business or semantic content.

[0210] Execution and Synthesis. The interface executor receives the complete DAG plan and concurrently sends the API requests for sub-task node p (calling createServer) and sub-task node q (calling createEIP) to the cloud platform. Assuming sub-task node p succeeds, it returns {"server_id":"srv-abcdef123"}; sub-task node q succeeds, returning {"eip_id":"eip-987xyz","ip_address":"123.45.67.89"}. The executor captures these outputs and uses them to populate the parameters of sub-task node h, then initiates a third API call: attachEipToServer(server_id="srv-abcdef123",eip_id="eip-987xyz"). Assuming all calls succeed, the result generator aggregates the results of all steps and synthesizes a clear and complete natural language response.

[0211] The system returns the final result to the user. The system replies to the operations engineer: Operation successful. A cloud host named web-server-01 (ID: srv-abcdef123) has been created, and a new elastic public IP address of 123.45.67.89 has been successfully created and bound to it.

[0212] If, for example, subtask node h fails during this process, the compensation transaction mechanism will be triggered, and the system will automatically delete the created cloud host and elastic IP, and then report an atomic failure result to the user.

[0213] The following describes a system provided by an embodiment of the present invention. The system described below can be referred to in correspondence with the method described above. The system of this embodiment is installed in an electronic device. Figure 9 , Figure 9 This is a structural block diagram of a system according to one embodiment of the present invention, including: a query acquisition module 210, used to acquire query text input by a user; a text determination module 220, used to determine several sub-query texts based on the query text, wherein if the query intent corresponding to the query text is a single intent, then the several sub-query texts are query text; if the query intent corresponding to the query text is a complex intent, then the several sub-query texts are multiple sub-query texts, and the multiple sub-query texts have an execution order; a decision module 230, used to determine the target interface corresponding to the sub-query vector of the sub-query text based on the application programming interface vector index library, and to determine the structured tool card of the target interface based on the relevant fields of the target interface; wherein the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; an execution module 240, used to generate a call request based on the structured tool card corresponding to the sub-query text, the call request being used to implement the call of the target interface; after the several sub-query texts implement their respective interface calls, the results of the interface calls of the several sub-query texts are aggregated to generate a response result.

[0214] In one possible implementation, the text determination module 220 is configured to: determine the intent detection result based on the query text; if the intent detection result is a single intent, determine several sub-query texts as query texts; if the intent detection result is a complex intent, generate an execution plan based on the query texts, the execution plan including multiple sub-task nodes with an execution order; and determine the sub-query text corresponding to each sub-task node based on the execution plan.

[0215] In one possible implementation, the text determination module 220 determines the intent detection result based on the query text, and is used to: determine the structural signal score, semantic signal score, and entity signal score of the query text; determine the complexity score of the query text based on the structural signal score, semantic signal score, and entity signal score of the query text; if the complexity score of the query text is greater than a preset complexity threshold, then the intent detection result is determined to be a complex intent; if the complexity score of the query text is not greater than the preset complexity threshold, then the intent detection result is determined to be a single intent.

[0216] In one possible implementation, the text determination module 220 generates an execution plan based on the query text, which is used to: perform syntactic analysis based on the query text to determine the subtask dependencies of multiple subtask nodes; generate a structured subtask list of multiple subtask nodes corresponding to the query text according to the subtask dependencies; and generate a directed acyclic graph as the execution plan based on the structured subtask list.

[0217] In one feasible approach, the text determination module 220 generates a directed acyclic graph (DAG) as an execution plan based on a structured list of subtasks. This is used to: generate the DAG based on the structured list of subtasks; determine whether the DAG is a complex graph; if so, estimate the cost of different paths in the DAG based on dynamic statistical information stored in the metadata database, obtaining the path with the lowest cost; the metadata database is associated with the application programming interface (API) vector index library through unique interface identifiers, and the metadata database is built based on the metadata corresponding to each interface, which includes static information and dynamic statistical information; and update the DAG based on the path with the lowest cost to update the execution plan.

[0218] In one possible implementation, the text determination module 220 is further configured to: determine the target subtask node marked as a write operation in the execution plan; determine the compensation operation corresponding to the target subtask node; and add the compensation operation as a compensation node to the compensation plan, wherein the execution order of the compensation plan is the reverse of the topological order of the corresponding nodes in the execution plan, and the compensation plan is used to roll back when the subtask in the execution plan fails.

[0219] In one possible implementation, the text determination module 220 is further configured to: inject the execution result information of the previous node of each subtask node as a query context into the subquery text, and update the subquery text corresponding to each subtask node.

[0220] In one possible implementation, the decision module 230 is configured to: extract query metadata based on the subquery text; generate a subquery vector based on the subquery text; filter a predetermined number of candidate interfaces with the highest similarity scores from an application programming interface vector index based on the subquery vector; determine the reorder score corresponding to the candidate interfaces based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate; wherein, metadata matching degree represents the matching degree between the query metadata and the corresponding parameters of the candidate interfaces; permission availability is the calling interface permission score of the candidate interfaces determined from the metadata database; usage frequency and error rate are the parameters of the candidate interfaces determined from the metadata database; sort the predetermined number of candidate interfaces based on the reorder score to obtain a sequence of candidate interfaces corresponding to the subquery text; and determine the target interface based on the sequence of candidate interfaces corresponding to the subquery text.

[0221] In one possible implementation, the decision module 230 is further configured to: generate a clarifying question if the highest rearranged score among the rearranged scores of a preset number of candidate interfaces is lower than a preset rearranged score threshold; re-determine the rearranged score after the user inputs supplementary information based on the clarifying question; generate a prompt message if the highest rearranged score among the rearranged scores is lower than the preset rearranged score threshold; and perform the step of sorting the preset number of candidate interfaces based on the rearranged scores to obtain a candidate interface sequence corresponding to the subquery text if the highest rearranged score among the rearranged scores is not lower than the preset rearranged score threshold.

[0222] In one possible implementation, the decision module 230 selects a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index based on the subquery vector, for: determining the service domain of the subquery text based on the subquery text; and selecting a preset number of candidate interfaces with the highest similarity scores from the sub-indexes corresponding to the service domains of the subquery text in the application programming interface vector index.

[0223] In one possible implementation, the decision module 230 is further configured to: determine a preset quantity based on the complexity score of the query text; the complexity score of the query text is a score determined based on the structural signal score, semantic signal score, and entity signal score of the query text.

[0224] In one feasible approach, the relevant fields of the target interface include: key text information, metadata information, and candidate values; the decision module 230 determines the structured tool card of the target interface based on the relevant fields of the target interface, for the following purposes: determining the key text information of the target interface from the application programming interface vector index library; determining the metadata information of the target interface from the metadata database; and determining the structured tool card of the target interface based on the key text information, metadata information, and candidate values ​​of the target interface.

[0225] In one possible implementation, the decision module 230 is further configured to: automatically fill in missing parameters in the structured tool card based on the query metadata and enumeration information of the target interface; wherein, the query metadata is data extracted from the subquery text of the target interface, and the enumeration information is information corresponding to the target interface determined from the enumeration table; after automatic filling, if there are missing required parameters, then generate completion prompts for all missing required parameters according to a preset question template; and fill in the structured tool card based on the completion information input by the user.

[0226] In one feasible approach, the decision module 230 generates completion suggestions for all missing required parameters according to a preset question template. This is used to: sort the missing required parameters according to their information gain values; and generate completion suggestions for all missing required parameters sequentially using the preset question template based on the sorting results. The information gain value is determined based on the information content and filtering capability of the required parameters.

[0227] One possible implementation also includes: an API vector index library building module for extracting key text information from multiple interface definition files; converting the key text information into semantic vectors using a text embedding model; and building an application programming interface vector index library based on the semantic vectors and the corresponding key text information.

[0228] One feasible approach also includes: a domain dictionary and enumeration table construction module, used to extract the enumeration values, core entities, and terms from multiple interface definition files; based on the core entities and terms, inputting a large language model to determine the synonyms corresponding to the core entities and terms, as well as the mapping between abbreviations and full names; generating standardized definitions based on the core entities and terms, synonyms, and abbreviations; expanding the vocabulary using expert review, the expanded vocabulary including synonyms, abbreviations, and standardized definitions; constructing an enumeration table based on the enumeration values ​​from multiple interface definition files; and constructing a domain dictionary based on the core entities and terms and the expanded vocabulary.

[0229] Figure 10 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 10 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0230] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0231] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0232] The memory 60 may include one or more non-volatile storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0233] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0234] Those skilled in the art will understand that Figure 10 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0235] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0236] Based on this, embodiments of the present invention also provide a non-volatile storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the method described above.

[0237] Based on this, embodiments of the present invention also provide a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the above-described method.

[0238] The foregoing has provided a detailed description of a cloud platform interface calling method, system, device, medium, and product provided by embodiments of the present invention. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0239] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0240] The foregoing has provided a detailed description of the cloud platform interface calling method, system, device, medium, and product provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this invention. It should be noted that those skilled in the art can make various improvements and modifications to this invention without departing from its principles, and these improvements and modifications also fall within the protection scope of this invention.

Claims

1. A method for calling a cloud platform interface, characterized in that, include: Get the query text entered by the user; Based on the query text, several sub-query texts are determined. If the query intent corresponding to the query text is a single intent, then the several sub-query texts are the query text. If the query intent corresponding to the query text is a complex intent, then the several sub-query texts are multiple sub-query texts, and the multiple sub-query texts have an execution order. The target interface corresponding to the subquery vector of the subquery text is determined based on the application programming interface vector index library, and the structured tool card of the target interface is determined based on the relevant fields of the target interface; wherein, the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; Based on the structured tool card corresponding to the subquery text, a call request is generated, which is used to invoke the target interface; After the subquery texts have implemented their respective interface calls, the results of the interface calls for the subquery texts are aggregated to generate a response result.

2. The cloud platform interface calling method according to claim 1, characterized in that, Based on the query text, several sub-query texts are determined, including: Based on the query text, determine the intent detection result; If the intent detection result is a single intent, then the plurality of sub-query texts are determined to be the query text; If the intent detection result is a complex intent, an execution plan is generated based on the query text. The execution plan includes multiple sub-task nodes with an execution order. Based on the execution plan, the sub-query text corresponding to each subtask node is determined.

3. The cloud platform interface calling method according to claim 2, characterized in that, Based on the query text, determine the intent detection result, including: Based on the query text, determine the structural signal score, semantic signal score, and entity signal score of the query text; The complexity score of the query text is determined based on the structural signal score, the semantic signal score, and the entity signal score of the query text. If the complexity score of the query text is greater than a preset complexity threshold, then the intent detection result is determined to be a complex intent; If the complexity score of the query text is not greater than the preset complexity threshold, then the intent detection result is determined to be a single intent.

4. The cloud platform interface calling method according to claim 2, characterized in that, Based on the query text, an execution plan is generated, including: Based on the query text, perform syntactic analysis to determine the subtask dependencies of multiple subtask nodes; Based on the subtask dependencies, a structured subtask list of multiple subtask nodes corresponding to the query text is generated; Based on the structured list of subtasks, a directed acyclic graph is generated as the execution plan.

5. The cloud platform interface calling method according to claim 4, characterized in that, Based on the structured list of subtasks, a directed acyclic graph is generated as an execution plan, including: Based on the structured list of subtasks, a directed acyclic graph is generated; Determine whether the directed acyclic graph is a complex graph; If so, the cost of different paths in the directed acyclic graph is estimated based on the dynamic statistical information stored in the metadata database to obtain the path with the lowest cost; the metadata database is associated with the application programming interface vector index library through the unique identifier of the interface, and the metadata database is built based on the metadata corresponding to each interface, which includes static information and dynamic statistical information. The directed acyclic graph is updated based on the path with the lowest cost to update the execution plan.

6. The cloud platform interface calling method according to claim 5, characterized in that, After updating the directed acyclic graph based on the path with the lowest cost, the process further includes: Identify the target subtask nodes marked as write operations in the execution plan; Determine the compensation operation corresponding to the target subtask node; and add the compensation operation as a compensation node to the compensation plan, wherein the execution order of the compensation plan is the reverse of the topological order of the corresponding nodes in the execution plan, and the compensation plan is used to roll back when the subtask in the execution plan fails.

7. The cloud platform interface calling method according to claim 2, characterized in that, Based on the execution plan, after determining the sub-query text corresponding to each sub-task node, the process further includes: The execution result information of the previous node of each subtask node is injected into the subquery text as the query context, and the subquery text corresponding to each subtask node is updated.

8. The cloud platform interface calling method according to claim 1, characterized in that, Determining the target interface corresponding to the subquery vector of the subquery text based on the application programming interface vector index library includes: Extract query metadata based on the subquery text; Generate a subquery vector based on the subquery text; Based on the subquery vector, a preset number of candidate interfaces with the highest similarity scores are selected from the application programming interface vector index library; The re-ranking score corresponding to the candidate interface is determined based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate of the candidate interface; wherein, the metadata matching degree represents the matching degree between the query metadata and the corresponding parameters of the candidate interface; the permission availability is the calling interface permission score of the candidate interface determined from the metadata database; the interface usage frequency and error rate are parameters of the candidate interface determined from the metadata database. Based on the rearrangement score, a preset number of candidate interfaces are sorted to obtain a sequence of candidate interfaces corresponding to the subquery text; The target interface is determined based on the candidate interface sequence corresponding to the subquery text.

9. The cloud platform interface calling method according to claim 8, characterized in that, After determining the re-ranking score corresponding to the candidate interface based on the similarity score, metadata matching degree, permission availability, interface usage frequency, and error rate of the candidate interface, the process further includes: If the highest reorder score among the reorder scores of a preset number of candidate interfaces is lower than a preset reorder score threshold, a clarification question is generated. After the user inputs supplementary information based on the clarifying question, the re-ranking score is determined again; If the highest rearranged score is lower than the preset rearranged score threshold, a prompt message will be generated. If the highest rearranged score in the rearranged scores is not lower than a preset rearranged score threshold, then the step of sorting a preset number of candidate interfaces based on the rearranged scores to obtain the candidate interface sequence corresponding to the subquery text is performed.

10. The cloud platform interface calling method according to claim 8, characterized in that, Based on the subquery vector, a predetermined number of candidate interfaces with the highest similarity scores are selected from the application programming interface vector index, including: Determine the service domain of the subquery text based on the subquery text; From the sub-index corresponding to the service domain of the sub-query text in the application programming interface vector index library, a preset number of candidate interfaces with the highest similarity scores are selected.

11. The cloud platform interface calling method according to claim 8, characterized in that, Before selecting a preset number of candidate interfaces with the highest similarity scores from the application programming interface vector index based on the subquery vector, the process further includes: A preset number is determined based on the complexity score of the query text; the complexity score of the query text is a score determined based on the structural signal score, semantic signal score, and entity signal score of the query text.

12. The cloud platform interface calling method according to claim 1, characterized in that, The relevant fields of the target interface include: key text information, metadata information, and candidate values; Based on the relevant fields of the target interface, the structured tool cards of the target interface are determined, including: Determine the key text information of the target interface from the application programming interface vector index library; From the metadata database, determine the metadata information of the target interface; Based on the key text information, metadata information and candidate values ​​of the target interface, the structured tool card of the target interface is determined.

13. The cloud platform interface calling method according to claim 12, characterized in that, After determining the structured tool card for the target interface based on its key text information, metadata information, and candidate values, the process further includes: Based on the query metadata and enumeration information of the target interface, the missing parameters in the structured tool card are automatically filled; wherein, the query metadata is data extracted from the subquery text of the target interface, and the enumeration information is information corresponding to the target interface determined from the enumeration table; After autofill, if any required parameters are missing, the system will generate completion suggestions for all missing required parameters according to the preset question template. Fill in the structured tool cards based on the information provided by the user input.

14. The cloud platform interface calling method according to claim 13, characterized in that, For any missing required parameters, generate completion suggestions based on a preset question template, including: Missing required parameters are sorted according to their information gain values ​​from highest to lowest. Based on the sorting results, a preset question template is used to generate completion suggestions for all missing required parameters in sequence; The information gain value is determined based on the information content and filtering capability of the required parameters.

15. The cloud platform interface calling method according to claim 1, characterized in that, Before obtaining the query text entered by the user, the following steps are also included: Extract key text information from multiple interface definition files; convert the key text information into semantic vectors using a text embedding model; and build an application programming interface vector index library based on the semantic vectors and the corresponding key text information.

16. The cloud platform interface calling method according to claim 1, characterized in that, Before obtaining the query text entered by the user, the following steps are also included: Extract the enumeration values, core entities, and terms from each of the multiple interface definition files; Based on core entities and terms, input a large language model to determine the synonyms corresponding to the core entities and terms, as well as the mapping between abbreviations and full names; Generate standardized definitions based on core entities, terms, synonyms, and abbreviations; Expand the vocabulary using expert review; the expanded vocabulary includes synonyms, abbreviations, and standardized definitions. Based on the enumeration values ​​of the various interface definition files, an enumeration table is constructed; A domain dictionary is constructed based on core entities and terms, as well as extended vocabulary.

17. A cloud platform interface call system, characterized in that, include: The query retrieval module is used to retrieve the query text input by the user; The text determination module is used to determine several sub-query texts based on the query text. If the query intent corresponding to the query text is a single intent, then the several sub-query texts are the query text. If the query intent corresponding to the query text is a complex intent, then the several sub-query texts are multiple sub-query texts, and the multiple sub-query texts have an execution order. The decision module is used to determine the target interface corresponding to the subquery vector of the subquery text based on the application programming interface vector index library, and to determine the structured tool card of the target interface based on the relevant fields of the target interface; wherein, the application programming interface vector index library includes: key text information and corresponding semantic vectors of multiple interface definition files; The execution module is used to generate a call request based on the structured tool card corresponding to the subquery text, the call request being used to implement the call to the target interface; after the subquery texts have implemented their respective interface calls, the module aggregates the results of the interface calls of the subquery texts to generate a response result.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the cloud platform interface invocation method as described in any one of claims 1 to 16.

19. A non-volatile storage medium, characterized in that, The non-volatile storage medium stores a computer program, which, when executed by a processor, implements the steps of the cloud platform interface invocation method as described in any one of claims 1 to 16.

20. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the cloud platform interface invocation method as described in any one of claims 1 to 16.

Images