Calling method, device and electronic equipment of application programming interface

Abstract

This application discloses a method, apparatus, and electronic device for invoking an application programming interface (API), relating to the field of computer software technology. The method includes: determining a target subgraph in a knowledge graph that matches a query intent; compressing the target subgraph to obtain a target feature representation; retaining a first type of field within the target subgraph and compressing a second type of field in the target subgraph to obtain summary information; encoding the target subgraph into a graph embedding vector; and using a generative model to analyze the target feature representation, the first type of field, the summary information, and the graph embedding vector to obtain a directed graph representing an API call sequence. This solves the technical problem of high API call failure rate and low API call efficiency caused by the inability to efficiently and accurately convert natural language queries into executable API call sequences, achieving the technical effect of improving the logical correctness, execution success rate, and response efficiency of API call plans.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a method, apparatus, and electronic device for invoking an application programming interface. Background Technology

[0002] With the deepening development of cloud computing and digital transformation, the number of Application Programming Interfaces (APIs) managed by modern cloud management platforms is growing exponentially, often reaching tens or even hundreds of thousands. These APIs are the core interfaces for realizing automated resource deployment, operation and maintenance orchestration, and service integration, and their efficient invocation directly determines the intelligence level and operation and maintenance efficiency of the cloud platform.

[0003] Related technologies attempt to improve human-computer interaction efficiency by implementing end-to-end conversion of API calls based on natural language. However, when applied to large-scale, dynamically evolving private cloud API scenarios, these technologies have revealed serious technical shortcomings:

[0004] First, the lack of structured dependency understanding leads to execution failures. Large language models are essentially statistical language models and lack a deep understanding of the real dependencies between APIs (such as "a cloud disk must be created first, then mounted to a virtual machine"). Without explicit structural constraints, large language models are prone to generating logically flawed call sequences, such as attempting to mount a disk before creating a virtual machine, using non-existent parameter names, or calling deprecated interfaces, resulting in "illusionary" calls with extremely low success rates, severely limiting system usability.

[0005] Secondly, the limited context length leads to inefficiency. Large language models have a limited input context window, while the official documentation for each API typically includes lengthy natural language descriptions. To cover a sufficient number of APIs, vector retrieval is required to filter relevant APIs. However, even with this, a single call still requires inputting hundreds to thousands of tokens, resulting in high inference costs and significant response latency, making it difficult to meet real-time requirements.

[0006] There is currently no effective solution to the above problems. Summary of the Invention

[0007] This application provides a method, apparatus, and electronic device for invoking an application programming interface (API), which at least solves the problems in related technologies where natural language queries cannot be efficiently and accurately converted into executable API call sequences, resulting in high API call failure rates and low API call efficiency.

[0008] This application provides a method for invoking an Application Programming Interface (API), comprising: receiving query content; determining a target subgraph in a knowledge graph that matches the query intent of the query content, wherein the nodes in the knowledge graph include: API nodes representing APIs; compressing the target subgraph to obtain a target feature representation; retaining a first type of field in the target subgraph and compressing a second type of field in the target subgraph to obtain summary information; wherein the first type of field is used to at least represent the parameter metadata when the API node is invoked, and the second type of field is used to at least represent the descriptive information of the parameter metadata; encoding the target subgraph into a graph embedding vector; encapsulating the target feature representation, the first type of field, the summary information, and the graph embedding vector into a prompt message, and analyzing the encapsulation result using a generative model to obtain a directed graph; converting the directed graph into an API invocation sequence and executing the API invocation sequence.

[0009] This application also provides an application programming interface (API) invocation device, comprising: a receiving module for receiving query content; a determining module for determining a target subgraph in a knowledge graph that matches the query intent of the query content, wherein the nodes in the knowledge graph include: API nodes representing APIs; a first processing module for compressing the target subgraph to obtain a target feature representation; a second processing module for retaining a first type of field in the target subgraph and compressing a second type of field in the target subgraph to obtain summary information; wherein the first type of field is used to at least represent the parameter metadata when the API node is invoked, and the second type of field is used to at least represent the descriptive information of the parameter metadata; an encoding module for encoding the target subgraph into a graph embedding vector; an encapsulation module for encapsulating the target feature representation, the first type of field, the summary information, and the graph embedding vector into prompt information, and using a generative model to analyze the encapsulation result to obtain a directed graph; and an execution module for converting the directed graph into an API invocation sequence and executing the API invocation sequence.

[0010] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the calling method of any of the above-described application programming interfaces when executing the computer program.

[0011] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of calling the method of any of the above-described application programming interfaces.

[0012] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of calling the method of any of the above-described application programming interfaces.

[0013] This application addresses the technical problems of high failure rates and low efficiency of API calls caused by the inability to efficiently and accurately convert natural language queries into executable API call sequences. By identifying a target subgraph matching the query intent within a knowledge graph, compressing the target subgraph to obtain target feature representations, retaining the first type of fields within the target subgraph, and compressing the second type of fields to obtain summary information, and encoding the target subgraph into graph embedding vectors, and by using a generative model to analyze the target feature representations, the first type of fields, summary information, and graph embedding vectors to obtain a directed graph representing the API call sequence, this application achieves the technical effect of improving the logical correctness, execution success rate, and response efficiency of API call plans. Attached Figure Description

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

[0015] Figure 1 A flowchart illustrating a method for invoking an application programming interface (API) as provided in this application embodiment;

[0016] Figure 2 A flowchart illustrating a knowledge graph generation method provided in this application embodiment;

[0017] Figure 3 A flowchart illustrating a subgraph query method provided in an embodiment of this application;

[0018] Figure 4 A structural diagram of an application programming interface retrieval and planning system provided in this application embodiment;

[0019] Figure 5 A structural diagram of an application programming interface (API) invocation device provided in an embodiment of this application;

[0020] Figure 6 This is a hardware structure block diagram of a computer terminal for a method of calling an application programming interface provided in an embodiment of this application. Detailed Implementation

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

[0022] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

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

[0024] The specific application environment architecture or specific hardware architecture on which the execution of the calling methods of the application programming interface depends is described here.

[0025] The embodiments of this application provide a method for calling an application programming interface (API). The method is described in detail in conjunction with the execution flow of the API calling method (the technical terms involved must be explained).

[0026] Step S101: Receive query content.

[0027] The query content refers to semantic instructions entered by the user in natural language to request the cloud platform to perform specific operations or complete specific tasks. The query content expresses the user's desired business goal or operational objective, rather than a specific system call command. Query content originates from various interaction channels, including but not limited to: natural language chat interfaces, voice input, operation and maintenance work order systems, and semantic instruction modules of automated scripts.

[0028] Step S102: Determine the target subgraph in the knowledge graph that matches the query intent of the query content, wherein the nodes in the knowledge graph include: application programming interface nodes for representing application programming interfaces.

[0029] In this knowledge graph, nodes represent each available application programming interface (API) in the cloud platform. Each node corresponds to a specific API operation, such as creating a virtual machine, mounting a cloud disk, or querying network configuration. The API node stores API information, including but not limited to: a unique identifier, a function summary, the structure definition of input parameters (such as parameter name, type, whether it is required, and enumeration values), and security permission requirements.

[0030] API nodes establish semantic and logical relationships through edges. Edges represent the type of relationship between APIs. For example, a directed edge of type "DEPENDS_ON" indicates that the "Mount Cloud Disk" API can only be called after the "Create Virtual Machine" and "Create Cloud Disk" APIs have been successfully executed. An undirected edge of type "CO_OCCURS_WITH" indicates that the "Query Monitoring Data" and "View Resource Usage" APIs are frequently called consecutively by the same user within a similar timeframe. Edges can also be accompanied by weight values ​​to characterize the strength or confidence of the relationship. These weights can be calculated by combining the frequency of occurrence in historical call logs, success rate, and confidence scores derived from generative model-assisted inference.

[0031] Key fields of the API node include, but are not limited to: `id` (unique identifier of the API), `summary` (functional summary), `parameters` (structured definition of the parameter list), `compressed_description` (compressed long text description or its semantic vector), and `security_scope` (the scope of security permissions required for the call).

[0032] Key fields for edges include, but are not limited to: `type` (relationship type, such as dependency, similarity, etc.), `weight` (relationship strength), `valid_from` (relationship effective time), and `valid_to` (relationship expiration time).

[0033] It should be noted that the knowledge graph is a dynamically evolving attribute graph, with each node and edge carrying a version and timestamp. It can be updated in real time as APIs are added, modified, or deprecated, thus ensuring that the graph always remains consistent with the actual interface status of the platform.

[0034] Step S103: Compress the target sub-image to obtain the target feature representation.

[0035] Step S104: Retain the first type of fields in the target subgraph and compress the second type of fields in the target subgraph to obtain summary information; wherein, the first type of fields are used to represent at least the parameter metadata when the API node is called, and the second type of fields are used to represent at least the description information of the parameter metadata.

[0036] The first type of field includes, but is not limited to: parameter name, data type, required field, and enumeration value; the second type of field includes, but is not limited to: descriptive text of parameters, API function descriptions, and other unstructured long text.

[0037] It is worth explaining that steps S103 and S104 adopt a dual-channel compression mechanism, which can retain the structured semantics and accurate interface signatures necessary for API calls with minimal context overhead. This avoids the token explosion and inference delay caused by directly inputting lengthy natural language descriptions into large language models, and overcomes the problem of planning failure caused by the loss of key call parameters due to oversimplification of information in a single compression method.

[0038] In step S103, the target feature representation is generated in a channel by compressing the inter-node dependencies of the target subgraph. This serves as a compact representation of the task skeleton, enabling the generative model to perceive the overall logical context of API calls.

[0039] Step S104 is implemented in another channel by distinguishing field types. For the first type of field, the structured meta-information that directly affects the legality of API calls is fully preserved using the original text pass-through method, ensuring that the generative model has precise syntactic constraints when constructing parameters. For the second type of field, it is compressed into semantically condensed summary fragments using a lightweight summarization model, significantly reducing the text volume without losing the core intent.

[0040] Steps S103 and S104 work together through dual channels, enabling the prompts in the final input generative model to have both the ability to accurately predict structural navigation parameters. This significantly reduces model inference costs and improves response speed and scalability while ensuring the correctness of API call plan logic and the feasibility of execution.

[0041] Step S105: Encode the target subgraph into a graph embedding vector.

[0042] In step S105, a graph neural network can be used to learn structured features of the target subgraph, mapping the semantic and topological information of each API node and its associated edges in the target subgraph into a high-dimensional real-valued feature vector. Specifically, this includes the following steps: taking the original semantic vector of the node (such as a compressed description vector) and the type and weight of the edge as input, and using multiple rounds of graph convolution or graph attention mechanisms, the final embedded representation of each node not only reflects its own function but also aggregates its contextual relationships in the local structure of the subgraph.

[0043] It should be noted that although the target feature representation generated in step S103 and the graph embedding vector generated in step S105 originate from the same target subgraph, their essence and function are completely different. The target feature representation and the graph embedding vector together constitute a dual guidance system for the generative model. The target feature representation is a parameter-level identity identifier oriented towards interface calls, while the graph embedding vector is a structure-level behavioral constraint oriented towards task logic.

[0044] Specifically, the target feature representation in step S103 involves quantizing and compressing the topological structure of the target subgraph and the original embedding vectors of nodes / edges, then encapsulating them into a compact structured representation (such as...). <gpkt>Essentially, it is a low-dimensional, discretized, and indexable collection of metadata. Its core function is to provide the generative model with the precise identity information required for API calls. That is, by explicitly telling the generative model through index mapping (index_map) that "index 0 corresponds to vm:create, index 1 corresponds to disk:create", it ensures that the generative model can accurately reference the real parameters when generating specific calls, avoiding illegal calls caused by loss of semantics due to compression.

[0045] The graph embedding vector generated in step S105 is a high-dimensional continuous feature vector output after multi-layer message passing and aggregation of the target subgraph. Its dimension can be 512 or 768 or higher. The graph embedding vector does not include any API names or parameter details, but only includes the deep structural relationships and task patterns between APIs in the target subgraph. For example, abstract patterns such as creating resources → connecting resources and parallel deployment → collaborative monitoring are used as navigation instructions input to the generative model to structurally constrain the generative model's generation logic, forcing the generative model to follow the implicit dependency order in the target subgraph, thereby completely suppressing the illusionary calls caused by the generative model's lack of domain knowledge.

[0046] Step S106: Encapsulate the target feature representation, the first type of field, the summary information, and the graph embedding vector into the prompt information, and use a generative model to analyze the encapsulation result to obtain a directed graph.

[0047] Generative models include, but are not limited to, large language models (LLMs) that can automatically generate structured output content based on input prompts.

[0048] In step S106, the target feature representation (i.e., the structured vector package, such as...) <gpkt>This is used to provide a unique identity index and interface skeleton for the generative model's API, enabling the generative model to accurately identify "API 0 is for creating a virtual machine and API 1 is for creating a hard disk", avoiding calling errors due to name confusion or abbreviation ambiguity.

[0049] The first type of fields (parameter name, type, enumeration value, required field, etc.) are provided in the original text to ensure that the generative model has accurate syntax and legal basis when filling in the call parameters. For example, "type must be ssd or hdd, and cannot be written as SSD arbitrarily".

[0050] The summary information retains the condensed semantics of the API function, helping the generative model understand that "creating a cloud disk" is for providing storage space, rather than network configuration, thereby assisting in parameter inference and intent alignment.

[0051] Graph embedding vectors, as high-dimensional structural features, do not carry specific API names. Instead, they convey deep task patterns, such as "resources must be initialized before performing join operations," to the generative model in a mathematical form. Graph embedding vectors act as logical filters, forcing the generative model to maintain consistency with the dependency topology in the target subgraph when generating call sequences, thus preventing illegal planning involving out-of-order, circular, or missing nodes.

[0052] After receiving the aforementioned multimodal prompts, the generative model performs probability sampling based on the constraint space collaboratively constructed by these prompts. Specifically, the generative model uses index mapping to determine the set of callable APIs, verifies the legality of the input based on the original parameter text, understands the operation intent through summarization, and, guided by graph embedding vectors, outputs a directed acyclic graph that satisfies semantic requirements, conforms to topological constraints, and has complete and valid parameters. This achieves a high-precision and high-reliability mapping from natural language intent to executable cloud operations.

[0053] Step S107: Transform the directed graph into an API call sequence and execute the API call sequence.

[0054] The API call sequence is a list of API requests executed in a specific order. Each request corresponds to a specific API operation (such as creating a virtual machine or mounting a hard disk), and the requests are arranged according to the dependencies in a directed acyclic graph to ensure that subsequent tasks are executed only after the preceding tasks are completed.

[0055] In summary, steps S101 to S107 above achieve the goal of accurately conveying API functions and dependencies with extremely low context overhead by using a dual-channel compression mechanism to separate key structural information and redundant semantic descriptions, and by combining graph embedding vectors as structural constraints injected into the generative model. This results in a significant improvement in the logical correctness, execution success rate, and response efficiency of the API call plan without relying on fine-tuning of the generative model.

[0056] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0057] Figure 2 A flowchart of a knowledge graph generation method provided in this application embodiment is shown below. Figure 2 As shown, the knowledge graph in step S102 is generated through the following steps:

[0058] Step S201: Obtain the API definition file.

[0059] In step S201, the latest version of the API definition file (also known as the API description file, which can be in OpenAPI / Swagger format) is automatically collected from the cloud platform's configuration center or code repository as the input source for knowledge graph construction. For example, a configurable document parser periodically scans a specified code repository or configuration center to obtain the latest API definition file.

[0060] Step S202: Extract the first type of fields and the second type of fields from the API definition file.

[0061] In step S202, the structured information of each API is divided into two categories: the first category of fields contains precise parameter information necessary for execution planning, such as interface path, method, parameter name, data type, whether it is required, enumeration value, etc.; the second category of fields contains natural language descriptive content, such as function summary, detailed parameter description, response example, etc.

[0062] For example, for each API definition file, extract the following core fields and transform each API (i.e., a path and method combination in the document, such as "POST / v1 / servers") into an initial node in the graph: API Unique Identifier: For example, `servers:create`, as the node's primary key. Function Description: Natural language text describing the API's purpose. Operation Tags: Used for business classification, such as virtual machine management, network configuration, etc. Input Parameters: Includes parameter name, data type, required status, description, constraints (such as maximum, minimum, enumerated values), and other detailed information. Request Body: For methods such as POST and PUT, parse its data structure, media type, and mode. Response Format: Parse the response structure and description under different status codes, such as success (e.g., 200 OK) and failure (e.g., 400 Bad Request, 404 Not Found). Security and Authentication Information: Define the authentication scheme and permission scope required to call this API.

[0063] Step S203: Compress the fields in the second type of fields that do not belong to the preset field set to obtain non-key semantic representations.

[0064] In step S203, only the original text of the preset list fields (such as parameter name and type) is retained, while the remaining descriptive text (such as lengthy function descriptions) is compressed into fixed-length semantic vectors through a lightweight summarization model to form compact non-critical semantic representations, thereby reducing the input burden of the generative model.

[0065] It is worth noting that fields included in the preset field set will be preserved in the original text even if they are long texts. In addition, non-key semantic representations include: fixed-length summaries or high-density semantic vectors, where the target length N of the summary can also be configured (e.g., N∈[128,256]) to achieve a balance between information density and contextual overhead.

[0066] Step S204: Generate API nodes based on key structured information and non-key semantic representations, wherein the key structured information includes the first type of fields and the fields in the second type of fields that belong to the preset field set.

[0067] In step S204, the fields belonging to the preset set in the first type of fields and the second type of fields (such as parameter name, type, enumeration value) are used as key structured information and merged with the compressed semantic vector to form a lightweight and semantically complete API node. This API node retains the interface signature required for precise calls and expresses the semantic summary through vectors.

[0068] Step S205: Determine the relationships between API nodes.

[0069] In step S205, by analyzing the platform's historical call logs, the sequence model is used to identify the order of frequently occurring API calls (such as "create hard disk" followed by "mount hard disk"), automatically inferring relationships such as dependencies and collaborations, and marking each relationship with a strength weight and effective time.

[0070] Step S206: Generate a knowledge graph based on the relationships between API nodes.

[0071] In step S206, all API nodes are used as vertices of the graph, and the inferred relationships are used as directed edges to construct a knowledge graph with attributes and timestamps.

[0072] Steps S201 to S206 above employ a hierarchical information processing mechanism that combines structured field retention with intelligent compression of non-critical semantics. While fully preserving the precise parameter structure necessary for API calls (such as parameter names, types, required fields, and enumeration values), semantic compression is performed on lengthy descriptive text to achieve lightweight expression of API nodes. Combined with automatically extracted node relationships, a dynamic API knowledge graph that is semantically accurate, compact, and capable of efficient retrieval and reasoning is constructed, which can significantly reduce the context overhead of generative models.

[0073] According to some optional embodiments of this application, step S203 can be implemented as follows: A text compression model is used to compress fields in the second type of fields that do not belong to a preset field set to obtain non-key semantic representations; wherein, the text compression model is trained through the following steps: obtaining API function description text; performing text cleaning and word segmentation on the API function description text to obtain an initial training sample set; using the encoding network to be trained to extract the initial semantic distribution features of the function description text in the latent space of the initial training sample set, wherein the latent space is used to represent the semantic mapping relationship of the API function description text; constructing positive and negative sample pairs based on the initial training sample set; in the latent space, using a contrastive loss function to minimize the semantic bias loss between the initial semantic distribution features and the positive samples, while maximizing the semantic distance between the initial semantic distribution features and the negative samples, so that the encoding network learns the core semantic information in the API function description text; limiting the dimension of the output features in the output layer of the encoding network, and obtaining the text compression model when the contrastive loss function satisfies a preset convergence condition.

[0074] In this embodiment, a pre-trained text compression model is used to semantically compress long text fields in the second type of fields (i.e., natural language descriptive content, such as function summary, parameter details, etc.) in the API definition file that do not belong to the preset field set (such as parameter name, type, enumeration value, etc.) to generate fixed-dimensional non-key semantic representations (i.e. semantic vectors) to reduce the token overhead of subsequent generative model inputs while retaining the core semantics.

[0075] Specifically, the text compression model is trained through the following steps:

[0076] We collect raw API function description text from a massive amount of historical API definition files as the basis for semantic learning;

[0077] Perform text cleaning (such as removing HTML tags, redundant spaces, and special symbols) and word segmentation on the functional description text to build a standardized initial training sample set;

[0078] The samples are fed into an encoding network to be trained (such as a lightweight Transformer or a variant of BERT), which maps the text to a low-dimensional latent space, where the latent space encodes the semantic structure of the API function description in vector form, so that semantically similar descriptions are close in distance in the vector space.

[0079] To guide the model in learning discriminative semantic features, positive and negative sample pairs are constructed based on the initial training sample set. Positive samples are semantically equivalent descriptions of the same API in different document versions, while negative samples are semantically unrelated or functionally different API description texts.

[0080] In the latent space, the model optimizes through a contrastive loss function: minimizing the semantic bias between positive samples with the same API (bringing closer similar semantics); and maximizing the semantic distance with negative samples (pushing away irrelevant semantics).

[0081] At the same time, the vector dimension is forcibly limited (e.g., 128 or 256 dimensions) in the output layer of the encoding network to ensure that the compressed representation is compact and stable;

[0082] When the contrastive loss function converges to a preset threshold after several iterations, the model learns to retain only the core semantics of the API function. At this point, training stops, and the final text compression model is output.

[0083] Through the above steps, each API node in the knowledge graph is no longer a simple copy of the original document, but a composite information body that has undergone structured refinement and intelligent compression. For example, an API node for creating a virtual machine has the following internal attributes:

[0084] `{id:"vm:create",summary:"Create a new cloud server",compressed_description:"Vector[...]",parameters:[{name:'image_id',type:'string',required:true},...],...}`.

[0085] The above steps enable efficient expression while preserving semantics, thereby supporting subsequent low-overhead graph retrieval and generative model interaction.

[0086] According to some optional embodiments of this application, determining the association between API nodes in step S205 can be achieved as follows: obtaining call logs; reconstructing the call logs based on session identifiers to obtain a global API call sequence; processing the global API call sequence using a sequence processing model to obtain the association between API nodes; wherein, the sequence processing model is trained through the following steps: extracting multiple historical API call sequences from historical call logs, dividing each historical API call sequence into an input subsequence and a corresponding target API node using a sliding window; mapping the input subsequence to a latent feature vector at a time step using a neural network model, and predicting the probability distribution of the API node appearing at the next time step based on the latent feature vector; calculating the prediction deviation between the probability distribution and the target API node using a loss function, and adjusting the parameters of the neural network model based on the prediction deviation until the loss function meets the preset convergence condition to obtain the sequence processing model.

[0087] In this embodiment, API call records initiated by real users or system services within a certain period of time are collected from the call logs of the cloud management platform. Each call log entry includes information such as the call time, caller identity, API identifier (e.g., vm:create), request parameters, and return status.

[0088] To restore the complete operational intent of a user or task, the call log is reconstructed based on session identifiers (such as user token, request ID, business work order number, etc.). Multiple discrete API calls belonging to the same business process or the same user operation session are aggregated into a global API call sequence in chronological order (e.g., [disk:create,vm:create,disk:attach]), thereby revealing the true call sequence and dependencies between APIs.

[0089] Furthermore, by using the trained sequence processing model, the global API call sequence is modeled, the relationship between different API nodes is automatically inferred, and the strength weight of each relationship is calculated.

[0090] Specifically, the sequence processing model is trained through the following steps:

[0091] Multiple historical API call sequences were extracted from massive historical call logs and used as training samples;

[0092] Each historical sequence is segmented using a sliding window technique:

[0093] Slide a window of length k, taking the first k API nodes as the input subsequence and the (k+1)th node as the corresponding target API node (i.e. the next API to be called), to construct a large number of training sample pairs in the form of: input subsequence: [api_A,api_B,api_C] → target API: api_D;

[0094] Each input subsequence is fed into a neural network model, which encodes each API node in the sequence as a latent feature vector at time steps, and captures long-term dependencies and contextual patterns in the call order through recursion or self-attention mechanisms.

[0095] The neural network model is based on the last hidden feature vector and outputs a probability distribution vector through a fully connected layer, representing the predicted probability of the next most likely API node in the current context (i.e., the classification confidence of all candidate APIs).

[0096] The cross-entropy loss function is used to calculate the prediction deviation between the predicted probability and the real target API node, and the backpropagation algorithm is used to continuously adjust the parameters of the neural network model (such as weights and biases) to minimize the overall loss.

[0097] When the loss function stabilizes after several iterations on the validation set and meets the preset convergence conditions (such as the loss value being lower than a threshold or the validation accuracy no longer improving), training stops, and the sequence processing model is finally obtained.

[0098] After training, the attention weights or state transition probabilities within the sequence processing model implicitly learn the strength and order of associations between APIs. For example, if the model always predicts `api_C` with a high probability after seeing `api_B`, it can establish a directed edge of type "DEPENDS_ON" between `api_B` and `api_C` and assign it a weight based on that probability.

[0099] It's important to note that API documentation typically describes only the functionality of a single API, rarely explicitly declaring dependencies or business process relationships between APIs. For example, creating a virtual machine with a new data disk mounted requires first calling the API for creating a cloud disk, then calling the API for creating the virtual machine, and finally calling the API for mounting the cloud disk to the virtual machine. This implicit dependency is crucial for intelligent task planning. The above steps, through sequence modeling and self-supervised learning based on real call logs, mine valuable relational information from historical operation logs, thereby automating the construction of API dependencies without manual rule intervention, significantly improving the authenticity, dynamism, and scalability of the knowledge graph.

[0100] In some optional embodiments of this application, step S206 can be implemented as follows: extract the association strength quantization parameters between adjacent API nodes, and determine the association strength quantization parameters as the initial weights of the directed edges between the corresponding API nodes; if the initial weights are not lower than a preset weight threshold, write the corresponding directed edges as valid dependency edges into the knowledge graph; if the initial weights are lower than the preset weight threshold, determine the corresponding directed edges as candidate edges, and perform the following steps: obtain the non-key semantic representations of the source API node and the destination API node corresponding to the candidate edge, and combine the non-key semantic representations with the preset verified dependency pairs to generate a knowledge graph. The system generates prompts representing the logical relevance of business processes. These prompts are then input into a generative model, which analyzes the sequential dependencies between the source and destination API nodes in terms of functional semantics to obtain logical confidence. If the logical confidence exceeds a first threshold, historical call context, including that of the source API node, is extracted from historical session data. The destination API node is then injected into the historical call context for simulated execution, and the parameter passing status and response status code are detected during the simulated execution. If the parameter passing status conforms to the preset input specification of the destination API node and the response status code is a preset success code, the candidate edge is written into the knowledge graph as a valid dependency edge.

[0101] In this embodiment, the association strength quantization parameter is used as the initial weight of the corresponding directed edge to construct the original dependency graph. The association confidence feature value is calculated based on the state transition probability and / or co-occurrence frequency between API nodes.

[0102] All candidate edges are filtered based on a preset weight threshold (denoted as θ0, for example, 0.6): if the initial weight is ≥ θ0, the relationship is determined to be a strong dependency, and it is directly written into the knowledge graph as a valid dependency edge (type: DEPENDS_ON) to complete the structured modeling; if the initial weight is < θ0, the relationship is determined to be a weak association or potential dependency, and it is marked as a candidate edge. An enhanced verification process based on semantic reasoning is initiated to avoid incorrect dependency building or omission of key logic.

[0103] For each candidate edge (source API node → destination API node), perform the following enhanced validation:

[0104] Extract the non-critical semantic representations of the source and destination API nodes corresponding to the candidate edge, and combine them with pre-defined verified dependency pair samples (such as positive examples of high-frequency successful paths verified by [create_disk→attach_disk], [create_network→create_vm], etc.) to construct a prompt message to represent the business logic relevance. For example: Given the following successful dependency pairs: Create cloud disk → Mount cloud disk, Create network → Create virtual machine. Existing candidate pair: Query image list → Create virtual machine. Please analyze: In the business process, is it necessary to query the image list first before successfully creating the virtual machine? Please output in the format "Yes / No, confidence level p".

[0105] The above prompt information is input into the generative model. Based on its deep understanding of API semantics, the generative model analyzes whether there is a reasonable pre-dependency logic between the source node and the destination node at the functional semantic level, and outputs the logical confidence (p). If the logical confidence p > τ1 (the first threshold, such as 0.8), the online behavior verification stage is entered; otherwise, the candidate edge is directly discarded.

[0106] Retrieve all successful call sessions containing source API nodes from the historical call logs, and extract their complete historical call context (including preceding call sequence, parameter values, response status codes, execution timestamps, etc.). Inject the target API node into this context to simulate the scenario in which it is called, forming a virtual execution chain.

[0107] The simulator verifies the validity of the injected parameters (such as type matching, required fields, and compliant enumeration values) according to the parameter input specifications in the API definition (from the first type of field), and simulates the response status codes returned by the system after the call (such as 200, 400, 503, etc.).

[0108] If the parameter transmission status fully meets the input requirements of the target API node, and the simulated response status code is a preset success code (such as 200, 201), then the candidate edge is determined to have real business feasibility; the candidate edge is then upgraded to a valid dependency edge, written into the API knowledge graph, and its source label is set to: source=LLM+replay+online(0). At the same time, the edge is assigned an initial weight = p×historical co-occurrence frequency to reflect both semantic and behavioral support; and a validity period (default 7 days) is set, requiring future review of its actual online execution performance.

[0109] It should be noted that all candidate edges written into the knowledge graph (regardless of whether they come from strong weights or semantic enhancement) must undergo online feedback verification: when the edge is observed to have been successfully executed M times (e.g., M=10) in the actual call path, its weight will be automatically increased, the source label will be updated to source=LLM+replay+online(M), and the validity period restriction will be lifted, making it a stable dependency.

[0110] As some optional embodiments of this application, the above-mentioned method of writing candidate edges as valid dependency edges into the knowledge graph when the parameter transmission status conforms to the preset input specification of the target API node and the response status code is a preset success code can be achieved through the following steps: when the parameter transmission status conforms to the preset input specification of the target API node and the response status code is a preset success code, determine that the candidate edge has passed the verification of the simulated execution and generate corresponding identification information, wherein the identification information is used to characterize the verification source; write the candidate edge into the candidate edge pool and configure an initial observation counter for the candidate edge; obtain the execution flow of the production environment and extract the actual call path of the candidate edge in the execution flow; when the actual call path is executed successfully, perform an accumulation operation on the initial observation counter; in response to the initial observation counter reaching a preset advancement threshold, remove the candidate edge from the candidate edge pool and write it into the knowledge graph as a valid dependency edge.

[0111] In this embodiment, after generative model reasoning and simulated execution verification, if it is determined that the candidate edge is semantically logically reasonable and feasible in terms of parameter constraints and response states, the following structured verification and advancement process is executed:

[0112] If, during the simulation, the parameter passing status fully conforms to the preset input specification of the target API node (i.e., all required parameters exist, types match, enumeration values ​​are valid, and nesting structure is correct), and the response status code returned by the simulation is a preset success code (such as 200, 201, or 204), then the candidate edge is determined to have passed the offline simulation verification, and identification information is generated to clearly record the source and verification path of the dependency relationship.

[0113] The format of the identification information is as follows: source=LLM+replay+online(0), where LLM indicates that the dependency is derived from the semantic reasoning of the generative model; replay indicates that the dependency is verified by the simulation of the historical session context replay; online(0) indicates that no actual call has been observed in the real production environment (initial value is 0).

[0114] Furthermore, candidate edges verified through simulation are written into a candidate edge pool, which is a buffer independent of the main knowledge graph that temporarily stores relationships to be verified. Simultaneously, an initial observation counter is configured for each candidate edge, with an initial value of 0, to record the number of times it is successfully invoked in a real production environment.

[0115] Continuously monitor the production environment execution flow of the cloud management platform (i.e., the API call sequence initiated by real users or automated tasks) and extract the actual call path including the candidate edge in real time (e.g., [api_A,api_B,api_C], where api_B→api_C is the candidate edge).

[0116] Whenever a candidate edge is successfully executed in the production environment (i.e., both the source API and the destination API return a success status code, and there is no abnormal rollback downstream), the initial observation counter for the candidate edge is automatically incremented (+1) to indicate that the dependency has been verified once in real business.

[0117] Furthermore, when the observation counter of a candidate edge reaches a preset advancement threshold (denoted as M, e.g., M=10), it is determined that the dependency relationship has been repeatedly and stably verified in real-world scenarios, possessing high-confidence business universality. At this point, the advancement process is triggered: the candidate edge is removed from the candidate edge pool; the candidate edge is formally written into the knowledge graph as a valid dependency edge (type:DEPENDS_ON); the candidate edge source tag is updated to: source=LLM+replay+online(M) to clarify that it is an authoritative dependency jointly supported by semantic reasoning, replay verification, and M successful online iterations; its effective time limit (if previously set) is removed, making it a long-term stable graph relationship.

[0118] If a candidate edge fails to reach the advancement threshold M within a set period (e.g., 30 days), or if it is erroneously invoked in the production environment (e.g., 4xx / 5xx), its confidence level will be automatically reduced, or a new semantic reasoning will be triggered. If necessary, it will be downgraded or deleted to ensure the cleanliness of the knowledge graph.

[0119] Optionally, during the process of writing candidate edges as valid dependency edges into the knowledge graph, a corresponding weight correction coefficient is configured for the valid dependency edges based on the identification information to correct the initial weights; the corrected weights of the valid dependency edges carrying identification information are greater than the initial weights.

[0120] It is worth noting that in the process of writing candidate edges as valid dependency edges into the knowledge graph, the credibility level of the verification path is extracted from the identification information carried by the edge based on the evidence sources accumulated during the verification process, and the weight correction coefficient is dynamically configured accordingly to perform multiplicative correction on the original initial weights.

[0121] The aforementioned identification information records how the dependency was confirmed, such as whether it was derived solely from statistical co-occurrence, or through generative model semantic reasoning, historical session simulation, and the number of successful calls in a real production environment. Different verification paths correspond to different correction coefficients. For example, an edge verified solely through semantic reasoning and simulation has a correction coefficient of 1.2; an edge verified through semantic reasoning and simulation and successfully called more than ten times online can have a correction coefficient of 1.8 or even higher. The corrected final weight is equal to the initial weight multiplied by this coefficient. Therefore, the corrected weight of a valid dependency edge carrying high-confidence identification information is always greater than its original initial weight.

[0122] The above steps can ensure that the strength of each dependency edge in the knowledge graph not only reflects the statistical frequency, but also embodies the comprehensive credibility of its semantic rationality and real behavior verification.

[0123] Figure 3 A flowchart of a subgraph query method provided in an embodiment of this application is shown below. Figure 3 As shown, step S102 can be achieved through the following steps:

[0124] Step S301: Vectorize the query content to obtain the query vector.

[0125] In step S301, a natural language query input from the user, such as "create a virtual machine with 8 cores, 32GB of memory, and a 500GB SSD," is received. This query is then converted into a fixed-dimensional dense numerical vector, i.e., a query vector, using a pre-trained dual-encoder query encoder. The query vector is a high-dimensional semantic representation after semantic modeling, capable of capturing the implicit intent, entities, and operational goals within the query. For example, semantic elements such as "create," "virtual machine," "8 cores," and "SSD" are encoded as specific directions and intensities in the vector space.

[0126] Step S302: Calculate the semantic similarity between the query vector and the API vector of the API node in the knowledge graph, and select one or more candidate API nodes with semantic similarity greater than a preset similarity threshold as initial seed nodes in the knowledge graph.

[0127] In step S302, vector similarity is calculated between the query vector and the API vector (generated by the compressed semantic encoding of the API) corresponding to each API node in the knowledge graph. Vector similarity calculations may include cosine similarity or Euclidean distance. When the similarity between an API vector and the query vector exceeds a preset threshold (e.g., 0.75), the API node is considered a semantically highly relevant candidate node and is selected as an initial seed node. For example, if the query mentions virtual machines or SSDs, nodes such as "vm:create", "disk:create", and "flavors:list" might be selected as seeds to ensure that the retrieval starting point covers the core functional intent.

[0128] Step S303: Starting from the initial seed node, iteratively traverse along the directed edges in the knowledge graph to identify associated API nodes that have a direct or indirect relationship with the initial seed node.

[0129] In step S303, starting from the initial seed node selected in the previous step, a breadth-first or weighted depth-first traversal is performed along the directed edges defined in the knowledge graph (such as "DEPENDS_ON" and "CO_OCCURS_WITH"), expanding the search scope layer by layer. During the traversal, attention is paid to directly connected neighbors, as well as nodes whose relevance scores are propagated to second-order, third-order, and even further nodes, thereby identifying associated API nodes that, although not directly matching the query semantics, have functional dependencies or collaborative relationships with the seed node. For example, "volume-attachments:create", although not directly appearing in the query, is included in the search scope because it depends on "vm:create" and "disk:create".

[0130] Step S304: Obtain the target directed edge between the initial seed node and the associated API node.

[0131] In step S304, after the traversal is completed, all directed edges participating in the traversal path are extracted from the knowledge graph, i.e., target directed edges. These target directed edges connect the initial seed node to all identified associated API nodes, forming the topological skeleton of the subgraph. The target directed edges carry initial weights, which are generated by historical call log statistics or semantic reasoning models, representing the strength or credibility of the dependency in real-world usage. For example, the initial weight of "vm:create→volume-attachments:create" can be 0.85, reflecting its high-frequency co-occurrence and strong logical coupling.

[0132] Step S305: Sort the API nodes by importance based on semantic similarity and the initial weights corresponding to the directed edges of the target, and construct the target subgraph according to the sorting results.

[0133] In step S305, an importance score is calculated for each candidate API node. This importance score is a weighted function of semantic similarity (from step S302) and the initial weights of the connecting edges (from step S304), for example, importance = α × semantic similarity + β × maximum weight of the incoming edges. Through sorting, core nodes with high semantic matching and strong structural connections are prioritized, while low-relevance or isolated nodes are filtered out. Using the top-N nodes in the sorting result and their respective directed edges as building blocks, a compact, functionally complete, and semantically focused target subgraph is constructed. This target subgraph includes not only APIs directly involved in the user query but also implicitly dependent APIs necessary to complete the task.

[0134] Steps S301 to S305 above enable the accurate and efficient retrieval of subgraph structures strongly related to the user's query intent from the knowledge graph. This not only takes into account the breadth of semantic matching and the depth of graph dependencies, but also comprehensively considers node relevance and edge strength, thereby constructing a target subgraph that is semantically accurate, topologically complete, and structurally compact. This significantly improves the completeness of API retrieval and the targeting of planning context, while reducing the input redundancy of generative models and ensuring high coverage and logical rationality of API links required for complex tasks.

[0135] As some optional embodiments of this application, step S301 can be implemented as follows: The query content is vectorized using a dual encoder model to obtain a query vector; wherein the dual encoder model is trained through the following steps: obtaining historical API call logs and corresponding historical work order description information; extracting association pairs between historical query content and API nodes from the historical API call logs and corresponding historical work order description information, and using these association pairs as initial training samples; generating pseudo-query text based on the description information of API nodes to construct enhanced training samples; inputting the initial training samples and enhanced training samples into the dual encoder model respectively to obtain the corresponding query vector and API vector, wherein the dual encoder model includes... The system includes a first encoder for encoding query content and a second encoder for encoding APIs. A contrastive learning task is used to calculate the distance between the query vector and the API vector in the same semantic space, and the representations in the semantic space are aligned based on this distance. Simultaneously with the contrastive learning task, the system is jointly trained using a tool usage detection task and a domain vocabulary alignment task. The tool usage detection task determines whether the query content has an API call intent, and the domain vocabulary alignment task establishes a mapping relationship between different terminology databases. The parameters of the dual-encoder model are adjusted based on the weighted loss function of the contrastive learning task, the tool usage detection task, and the domain vocabulary alignment task until a preset training objective is met, resulting in the dual-encoder model.

[0136] In this embodiment, the training process of the dual encoder model starts from the real environment, collecting historical API call logs and their corresponding historical work order descriptions, and extracting pairs of "user natural language query - actual API call node" as initial training samples. These initial training samples are used to realistically reflect the mapping relationship between user intent and API functionality.

[0137] To further expand the training data and enhance the model's generalization ability, semantically equivalent pseudo-query text can be automatically generated based on the description information of each API node. For example, the API description "create a cloud hard drive" can be transformed into "I want to build a hard drive" to form enhanced training samples, enabling the model to better understand the same intent behind different expressions.

[0138] Then, in the dual-encoder model, the first encoder encodes the query text into a query vector, and the second encoder encodes the compressed description of the API node into an API vector. The two share a semantic space to ensure comparability.

[0139] During training, the model promotes the structured alignment of the semantic space by minimizing the vector distance between positive sample pairs (queries and their corresponding APIs) and maximizing the distance between negative sample pairs (queries and irrelevant APIs) through a contrastive learning task.

[0140] Building upon this foundation, the model simultaneously executes two auxiliary tasks: 1. Tool usage detection task: This task determines whether a query actually involves an API call, such as distinguishing between "restart server" and "what's the weather like today," to filter invalid requests; 2. Domain vocabulary alignment task: By introducing a cloud platform terminology library (such as VPC, EIP, snapshots), the model is forced to learn to map user colloquial expressions and standard terms to the same vector region. For example, "Elastic Public IP" and "EIP" are similar in the vector space.

[0141] Finally, the loss functions of the three tasks—contrastive learning, tool usage detection, and domain terminology alignment—are weighted and fused to jointly optimize the parameters of the dual encoder model until the model reaches convergence on the validation set, completing training. The trained dual encoder model can accurately understand user intent, identify real call requests, align domain terms, and generate highly semantically consistent query vectors.

[0142] As some alternative embodiments of this application, step S303 can be implemented as follows: Based on the semantic similarity between the query vector and the initial seed nodes, assign initial relevance scores to each initial seed node; using the initial relevance scores as a basis, propagate the relevance score of the current node to its neighboring nodes along the directed edges in the knowledge graph in multiple rounds until a preset propagation depth is reached; wherein, in each round of propagation, the score of the current node is weighted based on the initial weights of the directed edges to calculate the new relevance scores of the neighboring nodes; the new relevance scores obtained by each neighboring node in the multiple rounds of propagation are accumulated to obtain the cumulative relevance score of each neighboring node. The process involves: 1) Selecting initial associated API nodes from all neighboring nodes whose cumulative relevance score exceeds a preset threshold; 2) Matching business scenario nodes corresponding to the query content in the association model, where the association model includes the relationship between query intent, business scenario, and API nodes. The association model is used to represent the logical aggregation relationship between API nodes that do not have a direct dependency relationship in a specific business scenario; 3) Determining a first set of API nodes that have a mapping relationship with business scenario nodes in the association model; 4) Selecting API nodes related to the query intent from the first set of API nodes and adding the selected API nodes to the initial associated API nodes to obtain associated API nodes.

[0143] In this embodiment, starting with the initial relevance score, a multi-round propagation process is initiated on the knowledge graph: in each round, the current node distributes its accumulated relevance score along its outgoing edges according to the edge weights, and passes it to its directly connected neighboring nodes. The edge weights represent the strength of the dependency relationship; the higher the weight, the greater the proportion of the score passed.

[0144] It should be noted that the above propagation process continues until the preset propagation depth is reached (e.g., 3 hops), ensuring that the relevance can spread from semantically matching nodes to functionally dependent deep nodes, such as from "vm:create" to "volume-attachments:create".

[0145] In each round, neighboring nodes receive scores from multiple parent nodes and accumulate these new scores to form a cumulative relevance score for each node. This cumulative relevance score represents its overall relevance in both semantic and structural dimensions. Nodes with cumulative scores exceeding a preset threshold are selected as initial associated API nodes, forming the core candidate set based on structural propagation.

[0146] This embodiment further introduces an association model, which is used to explicitly record the aggregation relationship between query intent, business scenario, and API nodes, in order to capture APIs that do not have direct dependencies but are often used together in a specific business context. For example, in the "monitoring and alarm" scenario, "query virtual machine status" and "query physical machine load" have no call order dependency, but are frequently used in parallel because they both belong to operation and maintenance monitoring tasks.

[0147] Based on the current query content, match the business scenario node to which it belongs, extract the first set of API nodes that are strongly associated with the scenario, and then filter out the semantically related but not covered by the preceding propagation API nodes from the first set of API nodes in combination with the query intent, and add them to the candidate set.

[0148] Finally, the initial associated API nodes and the supplementary API nodes expanded according to business scenarios together constitute a complete set of associated API nodes, which not only ensures the rigor of the dependency relationship, but also covers the implicit collaboration needs in the business context, significantly improving the completeness and scenario applicability of the tool recall.

[0149] In some optional embodiments, step S103 can be implemented as follows: obtaining the pre-trained embedding vectors corresponding to the API nodes in the target subgraph; performing bit-width compression-based quantization processing on the pre-trained embedding vectors to obtain quantized feature vectors; assigning logical indices to the API nodes in the target subgraph and generating an index lookup table to record the mapping relationship between logical indices and API node identifiers; encapsulating the quantized feature vectors, the index lookup table, and the version identifier information of the target subgraph into a preset format of graphic compressed data packet to obtain the target feature representation.

[0150] In this embodiment, a high-dimensional pre-trained embedding vector generated during the knowledge graph training phase for each API node is extracted from the target subgraph. The pre-trained embedding vector encodes the functional semantics and structural location information of the API and is a deep representation of the node.

[0151] To reduce data volume, this embodiment performs bit-width compression-based quantization processing on the pre-trained embedding vectors. For example, the original 32-bit floating-point number (float32) is compressed into an 8-bit integer (int8). While preserving the key vector direction and relative distance, the storage space of a single vector is reduced by more than 75%, generating a compact quantized feature vector.

[0152] At the same time, a unique logical index (such as 0, 1, 2, etc.) is assigned to each API node in the subgraph, and an index lookup table is built to clearly record the mapping relationship between each logical index and the original unique identifier of the API node (such as "vm:create" "disk:create"), so that the generative model can quickly backtrack to the original API definition through the index in subsequent inference.

[0153] In addition, the API knowledge graph version identifier (such as v2.1.0) corresponding to the current target subgraph is retained as a version context to ensure that the graph information used by the generative model is consistent with the current state and to avoid calling errors caused by API changes.

[0154] Finally, the quantized feature vectors (structural semantics), index lookup table (name mapping), and version identifier (time-sensitive anchor) are packaged into a unified graphical compressed data package (e.g., JSON or binary encapsulation format) according to a preset structure. <gpkt>This graph compression data package serves as the target feature representation. It occupies only a tiny amount of token space, yet it can fully carry the topological structure, semantic relationships, and API mapping logic of the subgraph. This allows generative models to understand the task skeleton with minimal overhead, without needing to read lengthy API documentation, achieving the goal of efficient context compression by using vectors to pass structure and indexes to restore details.

[0155] On the other hand, steps S103 and S104 can be implemented as follows: The retrieved target subgraph is compressed using a dual-channel method: firstly, a structure vectorization channel, used for encapsulating the quantized node / edge embeddings into `...` <gpkt>The first channel carries a graph version and index, enabling generative models to align key plaintext fields with the index during inference. The second channel is a block-level text channel, used to summarize long descriptive text and implement a plaintext pass-through strategy for parameter names / types / requirements and enumeration values. These two channels are encapsulated side-by-side within the hint, reducing context length while maintaining semantic fidelity of parameters and interface signatures.

[0156] It's worth explaining that the core objective of steps S103 and S104 is to address a crucial problem: after identifying several potentially related APIs through graph retrieval, how to efficiently and accurately organize this API information into a compact context and input it into the generative model so that the model can understand and formulate an execution plan. If too much information is provided, it will exceed the input length limit (Token limit) of the generative model, resulting in high cost and low efficiency. If too little information is provided, or if it is too vague, the generative model will be unable to formulate an accurate and executable plan.

[0157] To address the aforementioned issues, steps S103 and S104 propose a dual-channel compression strategy. A specific example will be provided below for detailed explanation.

[0158] User request: "I want to create a virtual machine with a 2-core CPU and 4GB of memory, and mount a new 50GB SSD cloud disk."

[0159] 1. Preliminary Steps. First, the user request is converted into a vector. A search of the API knowledge graph reveals the following highly related API nodes: `vm:create` (create virtual machine), `disk:create` (create cloud disk), and `disk:attach` (attach cloud disk to virtual machine). Furthermore, the dependencies between these API nodes are clear: `disk:attach` depends on the successful execution of `vm:create` and `disk:create`. Next, these three API nodes and their inter-node dependencies are extracted to form a temporary, small graph (the target subgraph), i.e., `ApiSubgraph`. This target subgraph is a structured representation of the user's current intent, "create a virtual machine with a new hard drive."

[0160] 2. Context compression. The `ApiSubgraph` is compressed into the final text, which is then fed into the generative model. This is where the dual-channel compression comes into play.

[0161] Channel 1: Structure Vectorization Channel (` <gpkt>The goal of this channel is to tell the generative model the skeleton and relationships of the task, rather than the details. The specific function of channel one is as follows.

[0162] (1) Embedding and Quantization: Obtain the pre-trained mathematical representations (embedding vectors) of the three API nodes `vm:create`, `disk:create`, and `disk:attach` in the knowledge graph. The embedding vectors include rich semantics such as the API's function and characteristics. To save space, the embedding vectors are quantized and compressed, for example, from 32-bit floating-point numbers to 8-bit integers.

[0163] (2) Pack into ` <gpkt>These quantized vectors, along with the graph version number and a crucial `index_map` (index table), are packaged into a special, compact format, represented in text as ` <gpkt>`graph_version`: `v2.1.0` (tells the generative model which version of the API graph to use); `index_map`: `{0:"vm:create",1:"disk:create",2:"disk:attach"}` (this is a "dictionary" that tells the generative model that index `0` refers to the `vm:create` API, index `1` refers to `disk:create`, and so on).

[0164] Understandable, <gpkt>For generative models, a package is like a highly condensed summary that can quickly decode "Oh, this task involves three APIs, their IDs are xxx, and there are dependencies between them", thus grasping the task structure at a macro level.

[0165] Channel Two: Block-level Text Channel. The goal of Channel Two is to provide the essential, precise parameter and interface information that generative models need for precise planning. Specifically, it iterates through each API in the subgraph and generates their text descriptions according to rules:

[0166] For `vm:create`: long description (summary): "This interface is used to create a new virtual machine instance on a cloud platform..." -> summary -> "Create a new cloud server". Key parameters: `name:string`, `image_id:string`, `instance_type:string`, `security_group:list` -> retained in the original text because these must be used precisely during planning.

[0167] For the long description of `disk:create`: "This interface is used to create a new cloud disk, with different types and capacities to choose from...", summarize it as "Create a new cloud disk". Key parameters: `size:int`, `type:string` (enumeration values: `ssd`, `hdd`), `zone:string` -> retained in the original text. Especially the enumeration values ​​`ssd` and `hdd`, which must precisely tell the LLM which valid options are available.

[0168] For the long description of `disk:attach`: "This interface is used to mount an existing cloud disk to a virtual machine...", the summary is: "Mounting a cloud disk to a virtual machine". Key parameters: `disk_id:string`, `vm_id:string` -> retained in the original text.

[0169] Furthermore, after dual-channel compression, the final combined context is as follows:

[0170] ```text

[0171] [USER_QUERY]

[0172] I want to create a virtual machine with a 2-core CPU and 4GB of memory, and mount a new 50GB SSD cloud disk.

[0173] [CONTEXT]

[0174] / / Channel 1: Structured information, allowing LLM to understand the skeleton first

[0175] <gpkt>

[0176] graph_version:v2.1.0

[0177] index_map:{0:"vm:create",1:"disk:create",2:"disk:attach"}

[0178] / / (This also includes vector representations of quantized API nodes and edges, which are omitted here)

[0179] < / gpkt>

[0180] / / Channel Two: Textual Information, providing precise details needed for planning

[0181] ---API:vm:create---

[0182] Summary: Creating a new cloud server

[0183] Parameters:

[0184] -name:instance_type,type:string,required:true,description:"Instance specifications, e.g., 2c4g (2 cores 4GB)"

[0185] -name:image_id,type:string,required:true,description:"Image ID"

[0186] -...

[0187] ---API:disk:create---

[0188] Summary: Creating a new cloud disk

[0189] Parameters:

[0190] -name:size,type:int,required:true,description:"Hard disk capacity, unit GB"

[0191] -name:type,type:string,required:true,enum:[ssd,hdd],description:"Hard disk type"

[0192] -...

[0193] ---API:disk:attach---

[0194] Summary: Mounting a cloud disk to a virtual machine

[0195] Parameters:

[0196] -name:disk_id,type:string,required:true,description:"The disk ID to be mounted"

[0197] -name:vm_id,type:string,required:true,description:"The virtual machine ID to be mounted".

[0198] In summary, by employing the dual-channel compression strategy described above, the retrieved target subgraph is structurally encapsulated to adapt to the input constraints of generative models. Without losing key semantic and constraint information, the length of the input context of generative models is reduced by 30%–50%, effectively avoiding issues such as context overrun, high inference latency, high token costs, and model illusion calls, and significantly improving the accuracy and efficiency of API planning.

[0199] According to some preferred embodiments of this application, step S103 can be implemented as follows: obtaining the count value of the input tokens of the generative model in a single inference request; comparing the count value with a preset resource overhead threshold, and determining the context length deviation rate based on the comparison result; generating a gain adjustment signal for the feature compression operator when the deviation rate reaches a preset trigger condition; and performing compression processing on the target subgraph based on the pruning frequency indicated by the gain adjustment signal.

[0200] Furthermore, the step S106 of encapsulating the target feature representation, the first type field, the summary information, and the graph embedding vector into the prompt information can be achieved as follows: the target feature representation, the first type field, the summary information, and the graph embedding vector are encapsulated into the prompt information according to the improved pruning frequency, wherein the character length of the encapsulation result is less than the character length threshold corresponding to the resource overhead threshold.

[0201] In this embodiment, step S103 obtains the token count value input by the generative model in a single inference request, compares it with a preset resource overhead threshold, and calculates the context length deviation rate. When the deviation rate exceeds a preset trigger condition, a gain adjustment signal for the feature compression operator is generated. The gain adjustment signal is used to indicate an increase in the pruning frequency of the compression process, thereby enhancing the compression strength of non-core text information in the target subgraph, such as shortening the summary length and reducing the level of detail of the retained text, in order to reduce the overall context volume.

[0202] In step S106, based on the enhanced pruning frequency, the target feature representation, the first type of fields, the summary information, and the graph embedding vector are encapsulated to form the final prompt information. The target feature representation includes quantized node and edge embeddings, index mappings, and graph version identifiers. The first type of fields retains the original structural information such as parameter names, types, required fields, and enumeration values. The summary information, after enhanced compression, retains only the semantic core, and the graph embedding vector remains unchanged. All content is combined to ensure that the total character length of the prompt information is strictly less than the upper limit of character length corresponding to the resource overhead threshold.

[0203] The above steps achieve intelligent compression of API subgraph features: when the context is close to the resource threshold, a gain-driven pruning mechanism is automatically triggered. Without sacrificing key structured information (such as parameter names and enumeration values) and semantic guidance (such as embedding vectors), redundant expressions are precisely reduced to ensure that the final encapsulated prompt information is always lower than the resource overhead threshold. This ensures the accuracy of planning while steadily reducing token consumption and inference latency, achieving a dynamic balance between economy and efficiency.

[0204] According to some optional embodiments of this application, step S105 can be implemented as follows: using the semantic vector of the API node in the target subgraph as the initial node feature, and using the relationship type and weight between API nodes as edge features; using a graph neural network to extract the node features of the neighboring nodes of the API node; performing weighted calculation on the node features of the neighboring nodes of the API node based on the edge features, and aggregating the calculation result with the current embedding representation of the API node to obtain the updated embedding representation; wherein, the initial value of the current embedding representation is the initial node feature; performing neighborhood feature extraction and weighted aggregation processing through multiple rounds of iteration to cyclically update the embedding representation of the API node; performing a pooling operation on the embedding representation of the API node after multiple rounds of iteration to obtain the graph embedding vector.

[0205] In this embodiment, firstly, the semantic vector of each API node in the target subgraph is used as the initial node feature, and the relationship type between nodes (such as dependency and collaboration) and its strength weight are used as edge features.

[0206] Then, the graph neural network propagates information layer by layer in an iterative manner: in each layer, each API node collects the current embedding representation of its direct neighbor nodes, aggregates the neighbor information in a weighted manner based on edge features (i.e., relation weights), and merges the weighted result with its own current embedding representation to output the updated node embedding.

[0207] The above process starts with the initial node features and goes through multiple rounds (such as 2–4 rounds) of iteration, so that the embedding of each node gradually integrates the structural and semantic information of its second-order, third-order and even more distant neighbors.

[0208] Finally, a global pooling operation is performed on the final embedded representation of all API nodes after multiple iterations to obtain a graph embedding vector of fixed dimension. This graph embedding vector encodes the dependencies, cooperation patterns and task structure semantics between nodes in the API subgraph in a high-dimensional continuous space. It serves as a strong constraint signal input to the generative model to guide it in generating an execution plan that conforms to the graph topology constraints.

[0209] It's worth explaining that graph embedding vectors can serve as additional, powerful contextual information, inputting into the generative model along with target feature representations, first-class fields, and summary information. Because graph embedding vectors are generated by a graph neural network encoding the structural and semantic relationships of the target subgraph, their numerical representations can explicitly carry the dependencies, collaborations, and execution order constraints between API nodes. Therefore, when the API set is added to, deleted from, or changed, only the lightweight graph neural network encoder needs to be retrained based on the updated graph to output graph embedding vectors that match the new topology. The generative model does not need to be retrained or fine-tuned; it only needs to generate an execution plan based on the structural constraints encoded by the graph embedding vectors to adapt to dynamic API changes, thus achieving low-overhead, high-efficiency system evolution.

[0210] The following example illustrates how graph neural networks generate graph embedding vectors.

[0211] Taking the user request "create a virtual machine with a new hard drive mounted" as an example, the target subgraph related to this task is identified in the knowledge graph, which includes three API nodes: vm:create, disk:create, and disk:attach, and there are two directed dependency edges: vm:create→disk:attach and disk:create→disk:attach. The edge type is "DEPENDS_ON", and the weight is determined by inference from the historical call log.

[0212] The graph neural network takes the target subgraph as input, where the node features of the target subgraph are the semantic vectors of each API, and the edge features are the relation type and weight. The graph neural network iteratively updates the node representations through a multi-round message passing mechanism.

[0213] In the first round of message passing, each node aggregates information from its direct neighbors. For example, the disk:attach node receives node features from vm:create and disk:create, and performs weighted aggregation based on the weight of the "DEPENDS_ON" edge to update its own representation, implicitly conveying the structural semantics that "this operation depends on two preceding resources"; the vm:create and disk:create nodes update their own representation as "basic resource generation nodes" based on their topological positions.

[0214] In the second and subsequent rounds of message passing, nodes continue to receive updated representations from their neighbors, gradually incorporating structural information from further distances. After several rounds of iteration, the embedding vector of each node not only contains its own functional semantics but also incorporates its local topological role in the subgraph (such as "source node", "sink node", "dependent relay node").

[0215] After multiple rounds of message passing, a global pooling operation (such as average pooling or max pooling) is performed on the final embedded representations of all nodes to generate a fixed-dimensional graph embedding vector. This graph embedding vector encodes the overall structural pattern of the subgraph in a high-dimensional continuous space, namely the creation operation of two independent basic resources, followed by a join operation that depends on the results of the two.

[0216] Furthermore, the response mechanism of the generative model to the graph embedding vector is as follows.

[0217] During the training phase, the generative model and the graph neural network are trained collaboratively. The training samples consist of three parts: user natural language queries; structured descriptions of relevant APIs (including parameters, protocols, etc.); and graph embedding vectors generated by the graph neural network.

[0218] The output target of the generative model is a structured execution plan (e.g., disk:create→vm:create→disk:attach), which represents the task sequence and dependencies in the form of a directed acyclic graph.

[0219] Through supervised training with massive amounts of samples, the generative model learns the mapping relationship between graph embedding vectors and execution plan structures: when the input includes graph embedding vectors with specific structural patterns (such as dual-resource construction + single-connection operation), the probability of the generative model generating API call sequences that conform to the structure is significantly improved.

[0220] In other words, the graph embedding vector, as a structured constraint, guides the generative model to prioritize the selection of legal paths that conform to the graph topological constraints in the output space, rather than performing unconstrained sampling in all possible API permutations and combinations.

[0221] Therefore, when the API set changes, if the graph structure does not change its abstraction pattern (such as resource creation → connection), even if the API name or parameters are updated, the graph embedding vectors generated by the graph neural network will still maintain a similar semantic distribution. Generative models can output valid plans stably based on this without retraining or fine-tuning their own parameters.

[0222] Understandably, the above mechanism uses a graph neural network to structurally encode the API subgraph, solidifying semantic and topological constraints into continuous vectors that serve as input constraints for the generative model. This effectively suppresses model illusions, and as the API dynamically evolves, only a lightweight graph neural network needs to be updated to maintain the generalization ability of the generative model, significantly improving adaptation efficiency.

[0223] According to some alternative embodiments of this application, the method for invoking the application programming interface further includes the following steps: in response to changes in API nodes or dependencies between API nodes in the knowledge graph, updating the corresponding node attributes and edge weights in the knowledge graph; extracting the changed target subgraph from the updated knowledge graph; incrementally training the graph neural network using the changed target subgraph, wherein the incremental training maps different topologies before and after the change to the same task mode vector space by adjusting the weight parameters of the graph neural network, so that each vector point in the task mode vector space represents a business logic model; the business logic model is used to represent the topological dependencies across API nodes and the parameter passing path; during the incremental training process, calculating the similarity index between the graph embedding vector generated by the changed target subgraph for the same business logic model and the graph embedding vector generated by the target subgraph before the change; determining whether the similarity index meets a preset similarity threshold, and if it does, determining that the graph neural network has completed incremental training, so that the generative model can identify the business logic model without changing its own parameters.

[0224] In this embodiment, in response to changes in API nodes or dependencies between nodes in the knowledge graph, the attribute information of the corresponding nodes and the weight parameters of the edges in the graph database are first updated to ensure version consistency and structural accuracy of the knowledge graph. Then, a target subgraph corresponding to the original business intent is extracted based on the updated graph, wherein the target subgraph is used to reflect the changed API topology.

[0225] Furthermore, the graph neural network is incrementally trained using the target subgraphs before and after the change. During the training process, the network weight parameters are adjusted so that subgraphs with different topologies but consistent semantics converge to similar vector representations in the embedding space, thereby achieving stable encoding of the same business logic model.

[0226] It's important to note that the business logic model is used to represent the topological dependencies and parameter passing paths across multiple API nodes, such as "first creating basic resources, then executing connection operations that depend on their outputs." During training, the similarity between the graph embedding vectors generated by the modified subgraph and those generated by the original subgraph is calculated. When this similarity reaches a preset threshold, it's determined that the graph neural network has completed incremental adaptation, and its output vector space has stably carried the semantic invariance of the business logic model. At this point, the generative model does not need to be retrained or its parameters adjusted; it can generate a legal execution plan that conforms to the current API topology simply based on the structural constraints encoded by the graph embedding vectors, thus achieving low-overhead, highly robust adaptation to the dynamic evolution of the API.

[0227] In some optional embodiments of this application, after determining the target subgraph in the knowledge graph that matches the query intent of the query content, the following steps can be performed: dividing the target subgraph into multiple task modules, wherein each task module is a set of API nodes with logical aggregation in the target subgraph; determining a first complexity index characterizing the modularity of the tasks and a second complexity index characterizing the coupling strength between each task module; if both the first and second complexity indices satisfy the corresponding preset logical thresholds, splitting the target subgraph into multiple local subgraphs corresponding to the task modules, wherein the preset logical thresholds are used to define whether the target subgraph has divisibility and independence after splitting; distributing the multiple local subgraphs to multiple parallel-running proxy models, wherein the proxy models are used to generate sub-execution graphs within the corresponding local graph scope; and performing topological splicing of each sub-execution graph according to the global dependencies in the target subgraph to obtain the updated target subgraph.

[0228] In this embodiment, the target subgraph is first divided into multiple task modules based on the strong connectivity and functional cohesion between API nodes. Each task module is a set of API nodes that are highly semantically related, internally dependent, but weakly coupled externally, such as a network configuration module, a storage creation module, or a compute instance deployment module. The specific division is based on automatic partitioning of the graph structure using spectral clustering or community detection algorithms, ensuring that each module has relative independence in business logic.

[0229] Secondly, two structural complexity metrics are calculated. The first complexity metric characterizes the degree of modularity within the target subgraph, reflecting the number of independent functional modules it is divided into and their internal connection density. A higher value for the first complexity metric indicates that the target subgraph is more easily decomposed into multiple self-contained units. The second complexity metric quantifies the coupling strength between task modules. It can be obtained by calculating the proportion of cross-module edges connecting different modules to the total number of edges. A lower value for the second complexity metric indicates weaker dependencies between modules, and a higher probability that they can be executed independently after decomposition.

[0230] Furthermore, when the first complexity index exceeds the preset modularity threshold and the second complexity index is lower than the preset coupling threshold, the target subgraph is determined to have the ability to be decomposed and the conditions for independent execution. This will trigger the subgraph partitioning process and generate multiple local subgraphs corresponding to each task module.

[0231] Furthermore, each local subgraph is independently distributed to a lightweight proxy model that runs in parallel. Each proxy model only processes the local structure it is assigned to, and generates an independent sub-execution graph based on local API constraints and user intent, thereby reducing the computational load and inference complexity of global planning.

[0232] Finally, after all proxy models have completed their sub-planning, the sub-execution graphs are topologically merged based on the global dependency edges retained in the original target sub-graph. By identifying the input and output parameter matching relationships between the interfaces between modules (such as "disk_id" output by module A being used as "volume_id" input by module B), a cross-module parameter binding mapping is constructed. All sub-execution graphs are then integrated into a complete and globally dependent updated target sub-graph, which serves as the input to the final execution plan.

[0233] The above steps automatically decompose the complex API planning problem into multiple independent subtasks for parallel processing, and then integrate them into a unified execution graph through global topology stitching. This significantly improves the planning efficiency and parallelism of complex tasks, reduces the load and latency of single models, and greatly enhances the responsiveness and scalability for high-complexity cloud operations.

[0234] On the other hand, the updated target subgraph can also be obtained in the following way.

[0235] The complexity of the target subgraph (task) is assessed using the following two structured metrics to determine whether to initiate a multi-agent parallel decomposition mechanism:

[0236] 1. Number of Communities (C): The target subgraph is divided into communities using a spectral clustering algorithm to identify functionally cohesive independent modules. If the division results show that the number of communities C ≥ 2, that is, there are two or more functional communities with strong internal connections and weak external dependencies, it indicates that the task has a natural modular structure and is decomposable.

[0237] 2. CutRatio (Cross-Community Edge Ratio): To accurately characterize the coupling strength between task modules, this embodiment defines the cut ratio as the ratio of the number of edges connecting different communities to the total number of edges in the target subgraph. When this ratio is lower than a preset threshold θ (e.g., θ=0.15), it indicates that the dependencies between functional communities are sparse, the coupling is low, and they have independent execution capabilities; conversely, if the ratio is high, it indicates that there are strong dependencies between communities, and the task should be planned as a whole.

[0238] Furthermore, if and only if the number of communities C≥2 and the cross-community edge ratio CutRatio<θ, the current task structure is determined to have high cohesion and low coupling characteristics, satisfying the triggering condition for multi-agent decomposition, and then the parallel planning process is started.

[0239] In the parallel planning process, the main planner decomposes the original target subgraph into several independent community subgraphs based on the community partitioning results. Each community subgraph corresponds to a functional domain (such as network configuration, storage creation, and compute instance deployment). Then, a lightweight sub-planning agent is initialized for each community subgraph. Each agent only receives and processes its own local subgraph, independently generating the corresponding sub-execution graph based on local API nodes and dependencies. These steps can significantly reduce the computational complexity of a single planning iteration and the inference load of the generative model, thereby improving response efficiency.

[0240] Understandably, the master planner, acting as the global coordinator, is responsible for scheduling the execution order and concurrency of each sub-agent. For example, it determines that subtask 1 (network configuration) and subtask 2 (storage creation) can be executed in parallel, while subtask 3 (mounting storage to a virtual machine) must wait for the former two to complete, thus achieving task-level parallel optimization.

[0241] After all sub-agents have completed the generation of the sub-execution graph, the main planner performs the following two integration operations to restore the integrity and consistency of the task: (1) Topology merging: Based on the global dependency edges retained in the original target sub-graph, each sub-execution graph is sequentially spliced ​​according to its topological constraints to construct a unified, acyclic, directed complete execution graph, ensuring that the execution order across sub-tasks conforms to the business logic. (2) Cross-community parameter binding: Semantic alignment is performed on the input / output parameters located at the community boundary in each sub-execution graph. For example, the disk_id field output by community A needs to be used as the volume_id input parameter of attach_diskAPI in community B. Such parameter dependencies are automatically identified and bound through the pre-set output / consumption interface alignment table to ensure that the data flow across modules is continuous, transitive, and unambiguous at the semantic and data levels.

[0242] Finally, the complete execution graph generated by the above steps serves as the final scheduling basis for the reliable execution of the API call sequence.

[0243] As some optional embodiments of this application, after executing the API call sequence, the following steps may also be performed: maintaining the execution state of each API node in the directed graph and recording the execution state of each API node in the execution context; in response to a first message used to characterize a call conflict or state abnormality, comparing the entity resource state in the target environment entity associated with the first message with the execution context, and performing state synchronization for the execution context or entity resource based on the comparison result; in response to a second message used to characterize a call failure, starting from the failed node, executing a preset compensation node along the reverse topology direction of the directed graph to roll back the entity resource and execution context to a preset stable mode.

[0244] In this embodiment, during the execution of the API call sequence, the execution state of each API node in the directed graph is maintained in real time, and these states (such as PENDING, RUNNING, SUCCEEDED, FAILED, COMPENSATED) are dynamically recorded in a unified execution context to form a complete tracking view of the entire call process.

[0245] When a first-type message indicating a call conflict or abnormal state is received (e.g., API returns 409 Conflict, resource is occupied, concurrent write conflict, etc.), the actual current resource state of the target environment entity (such as virtual machine, cloud disk, network interface, etc.) associated with the message is automatically extracted and compared with the expected state recorded in the execution context. Based on the comparison result, it is determined whether there is a deviation in the execution context or whether the environment entity has been asynchronously modified by external operations. If the context is lagging, it is updated to reflect the true state; if the environment is abnormal, a compensation instruction is triggered or the user is notified for confirmation to avoid subsequent operational errors due to state drift.

[0246] When a second type of message indicating a call failure is received (such as 500 InternalServerError, timeout, authentication failure, etc.), based on the topology of the execution graph, starting from the failed node, the dependency path is traversed in reverse to identify all predecessor nodes that have been successfully executed but need to be rolled back. The corresponding compensation API is automatically called according to the preset compensation strategy (such as "create" corresponding to "delete", "mount" corresponding to "unmount", and "assign" corresponding to "release"). Rollback operations are performed in sequence to undo the changes that have taken effect, until all related entity resources and execution context are restored to the preset stable mode before the start of this task, that is, the consistent snapshot state known before the failure occurred.

[0247] The above steps, through status monitoring, difference comparison, and reverse compensation, ensure that the API call process has transactional guarantee capabilities. Even under partial failures or concurrent interference, it can maintain overall status consistency and data integrity, thereby avoiding resource leaks, status inconsistencies, or business logic breaks.

[0248] In some optional embodiments of this application, the method for invoking the application programming interface further includes the following steps: extracting raw response data of multiple API nodes from the execution context, and summarizing the related business indicators across API nodes according to the query intent; generating structured intermediate calculation results corresponding to the summarized raw response data; encapsulating the query content, intermediate calculation results, and raw response data into a preset response prompt template to obtain a natural language answer for the query intent; and sending the natural language answer to the client.

[0249] In this embodiment, the raw response data returned by all API nodes is extracted from the execution context. The raw response data can be in a structured format (such as JSON) and includes the execution results of each API, such as resource ID, status code, performance parameters, billing information, etc.

[0250] Secondly, based on the user's original query intent, semantic-level aggregation and calculation are performed on related business metrics distributed across multiple API responses. For example, scattered fields such as virtual machine specifications, cloud disk capacity, and network bandwidth are unified into high-performance computing environment configurations, or cost differences are calculated by comparing prices in East China and North China, forming a logically integrated, structured intermediate calculation result that directly corresponds to the user's intent. It is worth noting that this intermediate result is a high-level semantic product after processing such as business rule mapping and condition judgment.

[0251] Next, the original query content, intermediate calculation results, and necessary original response data are encapsulated together in a preset response prompt template. This template instructs the generative model: "You are a cloud platform assistant. Based on the following API call results and user requests, generate clear, complete, and human-friendly natural language responses." This ensures that the model is only responsible for semantic refinement and expression generation, not for re-inference or calculation. The generative model then generates a natural language answer, including the final answer to the user's needs, such as "Your AI training environment has been successfully deployed: Virtual machine (8 cores, 32GB) is started, mounted with a 500GB high-performance SSD, and the total monthly cost is ¥1,280."

[0252] Finally, the natural language response is sent to the client (such as a web interface, mobile app, or chat window) through a standard communication channel, completing the closed-loop delivery from machine instructions to an understandable conclusion, and realizing natural, efficient, and optimized human-computer interaction.

[0253] Figure 4 This application provides a structural diagram of an application programming interface retrieval and planning system, as shown in the embodiments below. Figure 4 As shown, the system includes: API knowledge graph construction layer 41, query embedding and retrieval layer 42, adaptive planning layer 43, execution and feedback layer 44, and optimization and monitoring layer 45.

[0254] The API knowledge graph construction layer 41 is used to automatically integrate API documentation and real call logs from the cloud platform, building a structured, semantic, and evolvable dynamic knowledge network. During the initialization phase, it automatically scans standardized API definition files (such as OpenAPI / Swagger format) in the configuration center or code repository, parses all API paths and HTTP method combinations in batches, and extracts core metadata such as the unique identifier, functional summary, input / output parameter structure, and security permission scope required for each API call. For natural language description fields (such as API description and parameter description), a selective compression strategy is adopted: for structured fields such as parameter names, data types, whether they are required, and enumeration values, the original text is forcibly retained to ensure semantic accuracy; for lengthy explanatory text, a lightweight pre-trained summarization model is used to compress it into a fixed-length semantic vector, forming a composite ApiNode node containing structured information and a semantically compressed body, which is stored in the graph database to ensure that all nodes have consistent and queryable attributes.

[0255] In the dependency mining phase, the system accesses the audit logs of the API gateway and preprocesses the original call records: First, sessions are reconstructed according to user sessions or task contexts, aggregating scattered API call events into complete business chains; then, log cleaning is performed, removing non-business calls such as heartbeat probes, health checks, and debugging requests, retaining legitimate call sequences with clear business intent. Based on this, a Transformer-based self-supervised sequence prediction model is trained, using historical call sequences as input samples, with the goal of predicting the next most likely API to be called in the sequence. This model learns the temporal dependency patterns between APIs through an attention mechanism and automatically infers high-confidence DEPENDS_ON relationship edges based on prediction probabilities or attention weights (e.g., "creating a virtual machine" is usually followed by "mounting a hard drive"). Simultaneously, the system also identifies non-strictly temporally ordered but semantically collaborative CO_OCCURS_WITH edges by calculating the co-occurrence frequency of APIs in the same session and the number of adjacent calls within a time window (e.g., "querying monitoring data" and "viewing logs" are often called consecutively by the same administrator for troubleshooting).

[0256] Furthermore, to ensure the reliability and traceability of dependencies, a two-stage verification mechanism is introduced: For candidate dependency edges inferred by the model, they are only included in the candidate edge pool if their confidence is not lower than τ1=0.8 and they are successfully executed 3 times consecutively in offline historical session replay (without triggering any errors); if the dependency edge is observed to have M≥10 successful call paths in the online real environment, it is automatically promoted to a valid dependency edge and a source label source=LLM+replay+online(M) and a default TTL=7 days are attached. After the expiration, the system triggers a review process. If there is no new evidence to support it, it is downgraded or removed; conversely, if the error rate of a dependency edge is consistently higher than 30% in actual execution, the system automatically reduces its weight (α←α×0.5) or deletes it directly, forming a dynamic correction mechanism.

[0257] More importantly, all nodes and edges are bound to two timestamp attributes, `valid_from` and `valid_to`, to achieve fine-grained version control of the API lifecycle. When the API documentation changes (such as adding parameters, modifying the return structure, or deprecating the interface), the `valid_to` of the original node / edge is set to the time of the change, and a new version of the node / edge is created, with its `valid_from` set to the current time. Through version control, it can be ensured that the API semantics obtained by the planning layer when calling the graph at any point in time completely match the actual state of the system at that time.

[0258] Finally, the knowledge graph is stored in a high-performance graph database (such as Neo4j or JanusGraph) in the form of an attribute graph, supporting millisecond-level subgraph retrieval, multi-hop path queries, and weight propagation. This provides an authoritative, consistent, traceable, and real-time evolving knowledge foundation for upper-layer query embedding and retrieval layers. All graph construction and update operations are written to audit logs to ensure that the entire process is traceable, auditable, and rollbackable, meeting the stringent requirements of enterprise-level systems for data reliability and compliance.

[0259] After receiving a user's natural language request, the query embedding and retrieval layer 42 first maps the query statement into a query vector using a contrastive learning model with a dual encoder architecture. During the training phase, this model employs a multi-task joint optimization strategy: First, it performs a query-API matching task, minimizing the distance between semantically similar natural language queries and API node vectors in the embedding space through contrastive learning. Second, it performs a tool-based discrimination task, using a binary classification head to determine whether the current query belongs to a genuine API call intent, thus filtering out casual requests and reducing invalid retrieval overhead. Third, it performs a domain semantic alignment task, injecting cloud platform terminology and its standard definitions into the training corpus. Through contrastive loss, it guides the model to accurately align user colloquial expressions (such as "bind a public IP address") to standard API terms (such as "allocate_eip"), significantly improving the accuracy of semantic mapping in private cloud scenarios.

[0260] After generating the query vector, the system initiates a multi-level graph traversal retrieval process in the API knowledge graph: First, an approximate nearest neighbor index (such as FAISS or HNSW) is used to quickly screen the semantic vectors of the query vector and all API nodes, recalling the initial set of nodes with the best top-K semantic matches. Then, using the initial nodes as seeds, a weighted neighborhood propagation mechanism based on a graph attention network is initiated to carry out multiple rounds of information diffusion in the knowledge graph: In each round of propagation, each node aggregates the embedded representations of its neighboring nodes according to the weights of its edges with its neighbors and updates its own relevance score. This process continues for 2-3 rounds, enabling the relevance to be effectively transmitted from the semantically matching seed node to its dependent upstream, collaborating neighbors, and even second-order / third-order related nodes, thereby accurately recalling implicit but critical complete call chains such as "creating a virtual machine → selecting an image → binding a security group → allocating an elastic IP".

[0261] Furthermore, to address the issue of dispersed functional modules in complex tasks, the system introduces a scenario-aware modeling mechanism: several typical business scenarios of cloud platforms are predefined (such as deploying development environments, building monitoring systems, and performing disaster recovery switching). Each scenario corresponds to a set of semantic tags and associated API sets, constructing a query-scenario-API three-part graph. After the query vector is encoded, a lightweight scenario classifier is first used to predict the business scenario to which it most likely belongs, activating the corresponding scenario node. Then, the scenario node triggers all associated API nodes in reverse, forming a semantic + scenario recall path. This ensures that fuzzy requests such as "preparing an environment for a new project" can still fully cover all necessary APIs, avoiding tool omissions due to semantic sparsity.

[0262] After the retrieval is completed, nodes that meet the threshold and their connecting edges are selected from the set of highly relevant nodes to form the final API subgraph (target subgraph). A dual-channel context compression strategy is then executed to adapt to the input constraints of the large language model: the structure vectorization channel uniformly performs 8-bit scalar quantization on the embedding vectors of all API nodes and edges in the subgraph, compresses them into a compact binary format, and encapsulates them into a structured representation. <gpkt>The current graph version number and global index mapping table are also appended. The block-level text channel differentiates the unstructured text of each API in the subgraph: for fields directly affecting parameter filling and call validity, such as parameter names, data types, whether they are required, enumeration value ranges, and constraints, the original document text is forcibly preserved with zero compression and zero summarization; for unstructured text such as function descriptions and usage examples, a lightweight summarization model compresses it into a semantic condenser of no more than 128 tokens, ensuring that the generative model achieves a 30%–50% compression rate in context length while acquiring key interface contracts.

[0263] It should be noted that the dual-channel design ensures that the generative model understands the task topology and dependency constraints with extremely low token overhead, and ensures that it has a complete and unambiguous interface specification when generating call parameters, thus completely resolving the core contradiction of too much information leading to exceeding limits and too little information leading to illusion.

[0264] The compressed context is finally concatenated with the original query to form a unified input prompt to the adaptive planning layer 43. All compression and mapping operations are completed within milliseconds, meeting the low latency requirements of online services. The API subgraph and its compressed representation output by the query embedding and retrieval layer 42 are the most critical semantic bridge connecting user intent and machine execution.

[0265] The adaptive planning layer 43 receives the structured API subgraph output from the query embedding and retrieval layer 42, and then transforms the semantic intent and structural constraints in the API subgraph into a logically rigorous, parameter-accurate, and parallelizable directed acyclic execution graph. This process achieves functional decoupling, dynamic collaboration, and secure, controllable closed-loop cooperation through a meta-tool-driven retrieval invocation architecture.

[0266] Before the adaptive planning layer 43 is started, the system has already completed the dynamic orchestration of the toolchain through the top-level generative model: first, the api_search meta-tool is called to obtain the API subgraph, and then the plan_executor meta-tool takes over the subgraph and starts the deep planning process. In other words, the adaptive planning layer 43 is essentially an internal implementation unit of the plan_executor meta-tool. Its input is the output of api_search, and its output is the input of the next stage api_execute. All interactions are completed through standardized interfaces, and the generative model does not directly access the underlying data or execute APIs.

[0267] After the planning process is initiated, the input API subgraph is first structured and encoded by a graph neural network encoder. This encoder takes the semantic embedding vectors of nodes (high-density semantic representations retained after dual-channel compression in the retrieval layer) and the type weights of edges as input, and performs multiple rounds of message passing through a 3-4 layer graph attention network. In each round, nodes not only aggregate the semantic features of their neighboring nodes but also determine their role in the current task context. For example, after propagation, the embedding vector of a virtual machine creation node represents instance creation and also the topological semantic meaning that "this operation is a prerequisite for mounting a hard drive." Finally, the system generates graph embedding vectors through a global pooling operation; these graph embedding vectors are mathematical codes representing the current task execution mode.

[0268] Graph embedding vectors, serving as strongly constrained prior inputs, together with the user's original query and the dual-channel compressed API text (original parameters + summary), constitute the complete hints for the generative model. When generating API call sequences, the generative model's attention mechanism is deeply anchored by this vector: any attempt to violate the call order of existing dependency edges in the graph (such as mounting the hard drive before creating the virtual machine) or to reference APIs not appearing in the subgraph has its generation probability suppressed. This forces the output to converge to legitimate dependency paths at the semantic space level, completely eradicating the illusionary parameter bindings or fictitious API call chains produced by traditional generative models due to a lack of domain knowledge.

[0269] Furthermore, before generating the execution plan, a structural complexity assessment based on spectral clustering is required for the API subgraph. Specifically, the subgraph is spectrally embedded by calculating the minimum eigenvector of the normalized Laplacian matrix, and the K-means algorithm is used to divide functional communities. When the number of communities C≥2 and the proportion of cross-community edges is lower than a preset threshold θ (θ∈[0.1,0.2]), the task is determined to have high cohesion and low coupling topological characteristics. That is, the modules are closely dependent on each other, and the interactions between modules are sparse, possessing natural parallel processing potential. At this time, the system triggers a multi-agent collaborative planning mechanism.

[0270] The main planner initiates the task decomposition and distributed planning process: the original API subgraph is divided into C functional community subgraphs based on the spectral clustering results, each representing an independent business domain; a lightweight sub-planning agent is assigned to each subgraph, which can be a small generative model, rule engine, or template inference module, receiving only the subgraph of its own community and the corresponding compressed text, and is unaware of the global topology; each sub-agent runs independently, generating only a local execution graph based on the local graph structure, and the output only includes the API call order, parameter source, and dependency relationship within its own domain, prohibiting cross-domain references or global parameter passing; all sub-agents execute in parallel, significantly reducing the inference load and token consumption of a single generative model (approximately 40% reduction in actual tests).

[0271] After all sub-plans are completed, the main planner starts the topology merging engine. Based on the in-degree / out-degree relationships of nodes within each Sub-ExecDAG and the cross-community dependency edges retained in the original API subgraph, it constructs a global dependency priority to ensure that the global topology, where nodes are created first and then bound later, is not disrupted. On the other hand, the system automatically matches parameter dependencies between different subgraphs based on a pre-defined output / consumer interface alignment table. This alignment table is built based on historical call logs and semantic similarity modeling, supporting field-level semantic mapping.

[0272] Finally, the adaptive planning layer 43 outputs a globally unified directed acyclic execution graph, whose nodes are atomic API call tasks and whose edges are strict dependencies and parameter flow relationships, supporting parallel scheduling, error isolation and state backtracking.

[0273] The execution and feedback layer 44 is used to transform the directed acyclic execution graph generated by the adaptive planning layer 43 into a sequence of calls to the underlying APIs of the cloud platform. After the execution is completed, the structured response results are transformed into user-friendly replies that conform to natural language expression. At the same time, a complete execution trajectory log is built to provide closed-loop feedback for continuous system optimization.

[0274] Specifically, the execution chain scheduler initiates calls in parallel or serial order according to the topological sequence of the directed acyclic execution graph; it executes the priority chain of execution parameters for each node (user → previous output → default query → clarification), and performs schema verification before each call. The execution chain scheduler has a built-in, explicit task state machine, defined as follows:

[0275] `PENDING`→`RUNNING`→`SUCCEEDED` / `FAILED` / COMPENSATED`; all state transitions are event-driven and recorded in the execution log `ExecLog`, ensuring process traceability.

[0276] Failure events are handled according to a predefined error classification and strategy table: 4xx (Client Errors): Determined as parameter errors, execution terminates, and error information is propagated upwards. 5xx (Server Errors): Determined as transient service anomalies, retrying a maximum of `R` times (`R` is a configurable value, such as 3). Timeout: Triggers a predefined Fallback API or executes a compensation node. Idempotency Conflict: Calls the `Reconcile()` coordination function to maintain system state consistency. If rollback is required, executes a compensation node along the reverse topology from the point of failure and refreshes the execution context. End-to-end events and results are written to the feedback channel for incremental updates to the knowledge graph and weights.

[0277] Once all APIs in the plan have been successfully executed, the execution context includes all the final execution results. However, these raw, JSON-formatted results are often not suitable for direct display to users. For queries that require combining results from multiple APIs to provide an answer, the result fusion module first aggregates and organizes the information scattered across the multiple API responses.

[0278] The merged and processed results, along with the initial user query, are sent back to the generative model. At this point, the model's task is no longer planning, but generating a response. A prompt instructs the model: "You are a cloud platform assistant. Based on the following API call results, please generate a clear, user-friendly, and complete answer for the user's query about '...'." For example, if the API call returns `{price:500,currency:'CNY'}` and `{stock_price:100,currency:'USD'}`, and the user's original question is "How many shares would it cost to buy this product at today's stock price?", the result fusion module first performs the necessary calculations (e.g., currency conversion and division), and then passes the final result `{shares:X}` to the generative model, which generates a natural language response such as "Based on today's stock price, you would need approximately X shares to purchase this product." This process ensures that the user is ultimately presented with an answer, not just data.

[0279] Furthermore, to achieve continuous system evolution, this embodiment establishes a feedback-driven closed-loop learning mechanism, specifically including the following: A detailed record of each complete "query-planning-execution-result" process is maintained, primarily collecting the following types of information: Successful execution paths: A successfully executed API call sequence provides strong evidence for verifying and reinforcing dependencies in the knowledge graph; Failures and corrections: If an automatically generated plan fails to execute but subsequently succeeds in another way through manual intervention or user clarification, this "failure-correction" pair exposes defects or omissions in the original graph; Parameter filling patterns: Parameters provided by users in clarifying questions reveal typical values ​​or sources of parameters in specific scenarios; User satisfaction: A simple feedback mechanism (such as "like / dislike") can be introduced to allow users to directly evaluate the quality of the answer.

[0280] The aforementioned feedback data is periodically sent back to the API knowledge graph construction layer. Based on this data, the graph update module dynamically adjusts the graph's structure and attributes. For example, if a new execution path `api_X->api_Y` is frequently executed successfully, the weight of the `DEPENDS_ON` edge between `api_X` and `api_Y` is created or strengthened. If a dependency inferred by the LLM is proven incorrect during actual execution, the weight of that edge is reduced or even removed. By analyzing the parameter population data, the system can learn the default values ​​or common inference rules for specific API parameters and store them as node attributes.

[0281] Through the aforementioned feedback loop, the API knowledge graph can reflect real-world usage patterns, thereby ensuring the long-term accuracy and robustness of the system.

[0282] The optimization and monitoring layer 45 is used for end-to-end continuous measurement and monitoring of key system performance indicators. Key monitoring metrics include: Relationship Accuracy: Periodically extracting real call sequences from logs and comparing them with dependencies built in the graph to measure the accuracy of automatically constructed dependencies. Retrieval Recall and Completeness: Evaluating whether the API subgraph returned by the retrieval layer includes all necessary APIs through pre-set, representative test queries (especially complex task queries). Single Query Token Consumption: Statistically calculating the average number of tokens in the context (including queries, API descriptions, etc.) during each interaction with the large language model. Single query token consumption is a core indicator for measuring system economy; the goal is to control it at a low percentage of the upper limit of the model context window (e.g., a measured reduction of approximately 30%-50% in token consumption). End-to-End Latency: The total time from receiving a user query to returning the final answer. Execution Success Rate: The probability that the API call plan is successfully executed.

[0283] When any metric falls below a preset threshold (e.g., retrieval recall drops to 80% in the past hour), an alert is automatically triggered to notify operations personnel. Furthermore, the system can automatically adjust; for example, if token consumption is detected to be nearing its limit, it can automatically switch to a more aggressive block compression strategy.

[0284] Furthermore, to reduce the overhead of repetitive computation caused by high-frequency requests, the system implements a multi-level caching mechanism, specifically including the following: Query Embedding Cache: For identical user query text, the query embedding vector is fixed and can be cached to avoid redundant computation. Retrieval Result Cache: The API subgraph returned by the retrieval layer is cached using the query embedding vector or its approximation as the key. This is very effective for queries with the same intent but slightly different expressions. Execution Plan Cache: The final execution plan generated by the planning layer is cached using the combination of the API subgraph and the user query as the key.

[0285] It's important to note that all the cached entries mentioned above have configurable lifecycles to ensure that older, potentially expired caches are promptly evicted if the API itself changes. In multi-tenant or multi-user private cloud environments, a strategy combining local caching and global shared caching can be employed to maximize cache hit rates.

[0286] Furthermore, a permission-based candidate node pruning mechanism is introduced in the retrieval and planning stages: for each candidate API node v, if its required scopes(v) are not fully contained within the current user's permission set user_scopes, then during the graph traversal and relevance propagation phase, the node's relevance score is set to zero, and its outward edge propagation is blocked, ensuring that the node cannot be included in the subsequent planning scope. During the execution plan generation phase, the node is strictly prohibited from appearing in the final directed acyclic execution graph. It is worth noting that the above mechanism treats security permission constraints as core constraints of equal importance to functional semantics, permeating the entire retrieval, planning, and execution process, achieving proactive interception and intrinsic protection of security policies, rather than relying on post-call verification or permission rollback.

[0287] Furthermore, in multi-tenant application scenarios, to effectively prevent cross-tenant data unauthorized access and information leakage risks, this system uses the tenant identifier tenant_id as a mandatory component of the cache key in the API knowledge graph retrieval process and various levels of caching mechanisms (including query embedding cache, retrieval result cache and execution plan cache), ensuring that the query requests, retrieval results and planning contexts of different tenants are physically isolated within the system, thus protecting data sovereignty and privacy security from the architectural level.

[0288] In summary, this system constructs an API knowledge graph to make explicit and structured the implicit and real dependencies between APIs. During the planning phase, this structural constraint is injected into the LLM through a GNN encoder, effectively avoiding the "illusion" that the LLM might generate when lacking domain knowledge. This ensures that the generated API call plan is logically correct and topologically reasonable, thereby significantly improving the end-to-end execution success rate.

[0289] In this system, changes to the API only require updating the knowledge graph (database operations) and retraining the lightweight GNN encoder, without needing to fine-tune the massive and expensive LLM model itself. This allows the system to quickly keep up with the evolution of the API ecosystem in a low-cost and high-efficiency manner.

[0290] Meanwhile, through an innovative dual-channel context compression strategy, this system significantly reduces the number of tokens in the input context while providing the necessary information to the LLM (actual tests show a reduction of 30%-50%). <gpkt>Structured vector packages efficiently transmit the skeleton information of the graph, while block-level text channels ensure the fidelity of key parameters. This not only significantly reduces the economic cost of calling LLM, but also reduces latency in data transmission and model inference, improving the real-time performance of user interaction.

[0291] Furthermore, through a multi-agent decomposition mechanism based on graph clustering, parallelizable subtasks in user requests can be automatically identified. By decomposing complex problems into multiple simple sub-problems handled by lightweight agents, the system can generate more efficient parallel execution plans, effectively shortening the total time of complex tasks and improving the modularity and manageability of the planning.

[0292] Furthermore, through the execution and feedback layer, it is possible to learn from each successful or failed real-world call. Successful paths strengthen the relation weights in the knowledge graph, while failed amendments can expose and correct the graph's flaws.

[0293] Crucially, the meta-tool's architecture encapsulates core capabilities (such as search and planning) into standard tools. When integrating a completely new API set (e.g., expanding from a private cloud API to a SaaS application API), seamless integration is achieved simply by providing the relevant documentation and registering with the `api_indexer` meta-tool, without requiring any changes to the system's core logic. This gives the aforementioned technical solution high scalability and cross-domain versatility.

[0294] To make the technical solution and advantages of this application clearer, the application programming interface retrieval and planning system proposed in this application will be described in detail below with reference to a typical application scenario. This embodiment takes a natural language command initiated by an operations engineer in a private cloud environment as an example to fully present the end-to-end execution process of the system from user request to intelligent response and then to knowledge evolution.

[0295] Scenario Description: An operations engineer enters a natural language command into the cloud management platform's interactive interface: "Please create a high-performance computing environment for my AI training project. It requires a GPU virtual machine configured with an 8-core CPU, 32GB of memory, and a 500GB high-performance SSD data disk." After receiving the command, the system sequentially triggers the collaborative work of modules such as API knowledge graph construction, query embedding and retrieval, adaptive planning, execution scheduling and feedback optimization, ultimately returning the execution result in natural language form and driving the continuous evolution of the knowledge graph.

[0296] Step 1: Pre-construction and dynamic maintenance of the API knowledge graph (offline / near real-time). During the initial system deployment and subsequent API version iterations, the API knowledge graph construction layer automatically completes the initialization and dynamic updating of the graph, forming a structured knowledge foundation that supports intelligent services.

[0297] 1. Document Parsing and Node Generation. The system periodically scans the API documentation center configured on the cloud platform (such as the OpenAPI / Swagger files in the Git repository), automatically identifying and parsing all API definitions related to resources such as virtual machines, cloud disks, GPUs, and networks. For example, interfaces such as POST / servers (creating virtual machines), POST / volumes (creating cloud disks), and POST / volume-attachments (mounting cloud disks) are all identified as independent API nodes.

[0298] For each API, the system extracts its unique identifier (e.g., servers:create), functional summary, request path, HTTP method, input parameters (including parameter name, data type, required status, enumeration values, and constraints), response structure, and security permission requirements. For lengthy natural language descriptions (e.g., detailed parameter descriptions), a lightweight text summarization model is used for semantic compression, generating a fixed-length semantic vector as the node's compressed_description attribute; key structured fields (e.g., parameter name, type, required status, and enumeration values) are fully preserved. All structured API nodes are uniformly stored in a graph database (e.g., Neo4j), forming an initial set of ApiNodes.

[0299] 2. Call Log Analysis and Relationship Inference. Audit logs from the API gateway are accessed, and historical call sequences are reconstructed and cleaned to extract the API call trajectories of real users or system services. A dependency identification model based on the Transformer architecture is trained to predict the next API call in the sequence, identifying high-frequency dependencies through attention weights and state transition probabilities. For example, analysis reveals that POST / volume-attachments always follows the successful execution of POST / servers and POST / volumes. Based on this, the system establishes two directed edges of type DEPENDS_ON in the graph: servers:create→volume-attachments:create; volumes:create→volume-attachments:create. The edge weights are dynamically calculated based on the frequency of the dependency in the logs and the execution success rate. Simultaneously, co-occurrence analysis reveals that the APIs "Query GPU driver version" and "Query virtual machine monitoring" are frequently called in the same session. Therefore, a cooperative relationship edge of type CO_OCCURS_WITH is established between them to enhance intent recommendation capabilities.

[0300] 3. Graph Storage and Version Management. To cope with frequent API evolution (such as new parameters and deprecated interfaces), timestamp attributes `valid_from` and `valid_to` are introduced for each `ApiNode` and `ApiEdge` to achieve versioned management of the graph. For example, when the POST / servers interface is upgraded and a `gpu_type` parameter is added, the original node is marked with `valid_to=T`, and a new version node is created with `valid_from=T`, containing the new parameter definition. This mechanism supports time travel queries, ensuring that the system can accurately match historical tasks with the current environment even in environments where different API versions coexist.

[0301] Step 2: Query Understanding and Related API Subgraph Retrieval (Online). After the user enters a command, the query embedding and retrieval layer initiates an online processing flow to accurately locate the smallest functional subgraph related to the intent from a massive amount of APIs.

[0302] 1. User Query Embedding. User natural language requests are processed by a query encoder with a dual-encoder architecture. This encoder is trained through multiple tasks and possesses domain terminology alignment (e.g., "Elastic IP" → "EIP"), tool usage discrimination (distinguishing between "restart server" and "what's the weather like today"), and intent recognition capabilities. The final output is a query vector that represents the semantic spatial location of the user's intent.

[0303] 2. Graph Traversal Retrieval. Initial Node Location: Input the query vector into a vector index (such as FAISS) to quickly recall the top-N initial nodes with the most semantic similarity in the API knowledge graph, such as servers:create, volumes:create, gpus:list, and flavors:list. Neighborhood Information Propagation: Using these initial nodes as roots, initiate a weighted graph traversal. Based on the graph attention network mechanism, the relevance score propagates to neighboring nodes along the DEPENDS_ON and CO_OCCURS_WITH edges. For example, although volume-attachments:create has a low semantic match with the original query, its relevance score significantly improves after propagation because it is directly depended on by servers:create and volumes:create. After two rounds of propagation, a set of strongly related APIs, including flavors:list, volumes:create, servers:create, volume-attachments:create, and images:list, is identified.

[0304] 3. Subgraph Extraction and Context Compression. Nodes and edges are extracted from the above set to construct a structured ApiSubgraph. To adapt to the context window limitations of large language models, a dual-channel compression strategy is adopted: The structured vectorization channel quantizes the subgraph's topology, node and edge embedding vectors with 8 bits, encapsulating them into a compact structured object. <gpkt>The graph version number (e.g., v2.1.0) and index mapping table are also provided.

[0305] {0:"flavors:list",1:"volumes:create",2:"servers:create",3:"volume-attachments:create"}, are provided for LLM to decode and backfill in subsequent planning. Block-level text channel: Selective processing of the text description of each API: long summaries retain semantics, while key parameters (parameter name, type, whether required, enumeration value) are passed directly in the original text to ensure semantic fidelity.

[0306] Ultimately, the user's original query, <gpkt>The structure package and block-level text are merged into a compact context with a total length compression of 30%–50%, which is then delivered to the adaptive planning layer.

[0307] Step 3: Adaptive Planning and Execution DAG Generation (Online). After receiving the compressed context, the adaptive planning layer starts the deep planning process to generate an executable API call sequence.

[0308] 1. Graph Neural Network Encoder. The ApiSubgraph is fed into the graph neural network encoder. Through multiple layers of message passing, the representation of each node incorporates its role information in the current task. For example, the embedding vector of the `servers:create` node internalizes the structural semantics of "waiting for flavor_id and image_id input." Graph pooling operations generate graph embedding vectors representing the creation of resources first, followed by the establishment of binding patterns. These graph embedding vectors serve as strong structural constraint navigation instructions, inputting into the large language model to guide it in avoiding generation behaviors that violate dependencies.

[0309] 2. Dynamic decision-making and multi-agent decomposition. LLM receives user queries, <gpkt>Complete hints for block-level text and graph embedding vectors. Based on graph embedding navigation signals, LLM prioritizes the dependency structure defined in the graph. Combining the user commands "8-core CPU, 32GB RAM" and "500GB SSD", LLM parses the following: flavors:list requires parameters cpu=8, ram=32, gpu_present=true; volumes:create requires size=500, type='ssd_high_perf'; servers:create requires references to flavor_id and image_id; volume-attachments:create requires references to the output IDs of the first two.

[0310] Based on this, LLM generates the following structured execution plan:

[0311] Taskt1:flavors:list(cpu=8,ram=32,gpu_present=true);

[0312] Taskt2:volumes:create(size=500,type='ssd_high_perf');

[0313] Taskt3:servers:create(flavor_id=t1.output.id,image_id=...);

[0314] Taskt4:volume-ttachments:create(server_id=t3.output.id,volume_id=t2.output.id);

[0315] Edges:t1→t3,t2→t4,t3→t4.

[0316] 3. Meta-tool-driven retrieval invocation (optional extension). If the subgraph is confirmed by spectral clustering analysis to have ≥2 functional communities and the proportion of cross-community edges is below the threshold θ, multi-agent parallel planning is automatically triggered. In this example, due to the tight task structure, decomposition was not triggered, and the task was completed by a single planner.

[0317] Step 4: Execution, Feedback, and Response (Online). The execution and feedback layer transforms the abstract plan into actual calls and completes result generation and knowledge feedback.

[0318] 1. Execution chain scheduling. The scheduler executes tasks according to the topological order of ExecDAG: t1 and t2 have no dependency and start in parallel; t3 waits for t1 to complete and extracts flavor_id from its output; t4 waits for both t2 and t3 to succeed, extracts volume_id and server_id, and then executes.

[0319] Schema parameter validation is performed before all task calls. If t2 returns a 4xx error due to "insufficient SSD quota", the link is terminated and the error is reported; if t3 returns a 5xx error due to a momentary service failure, exponential backoff retries are triggered, with a maximum of 3 retries. In timeout or idempotency conflict scenarios, the preset FallbackAPI or Reconcile coordination function is called respectively.

[0320] 2. Result Fusion and Response Generation. After all tasks are successfully executed, API responses are collected, including: virtual machine ID, IP address, disk ID, creation status, etc. The result fusion module aggregates this structured data, converts units, and normalizes semantics to form a unified result set. This result set, along with the original user request, is input into the LLM again with the instruction: "You are a cloud platform assistant. Based on the following API call results, generate a clear, friendly, and complete natural language response for the user's request to 'create a high-performance AI training environment'." The LLM output: "Hello! Your high-performance computing environment has been successfully created. The virtual machine (ID: vm-xxx) has started, configured with an 8-core CPU / 32GB memory, and has successfully mounted a 500GB high-performance SSD data disk (ID: vol-yyy)."

[0321] 3. Feedback-driven graph update. The complete execution path (flavors:list→servers:create→volume-attachments:create and volumes:create→volume-attachments:create) is recorded as positive feedback and sent to the knowledge graph update module. The weights of the two DEPENDS_ON edges are automatically increased, and the parameters "8-core CPU / 32GB memory" and "ssd_high_perf" are incorporated into the node attribute library as parameter patterns for typical scenarios. Furthermore, the system continuously collects user "likes / dislikes" feedback, clarification interactions, and failed amendment examples, forming a closed-loop learning mechanism that transforms the API knowledge graph from a static document library into a dynamically evolving "living knowledge network."

[0322] Step 5: Optimization and Monitoring (Online / Backend). To ensure the system operates efficiently, stably, and securely in a large-scale production environment, the optimization and monitoring layer continuously measures, caches, accelerates, and restricts permissions throughout the entire process.

[0323] 1. Performance monitoring.

[0324] By tracing the link end-to-end, key performance indicators are collected and analyzed in real time to quantify system performance and trigger automated tuning.

[0325] Periodically extract actual successful call sequences from the execution logs and compare them with the dependency edges constructed in the graph to calculate the matching degree. If the success rate of a dependency edge (such as servers:create→volume-attachments:create) in actual execution is lower than a preset threshold (such as 95%), an alert will be triggered, and the weight of the edge will be automatically reduced or marked for review to prevent incorrect dependencies from causing subsequent planning failures.

[0326] Using a pre-defined test case set (including single-step operations and multi-step complex tasks), regression tests are performed periodically to evaluate whether the API subgraph returned by the retrieval layer covers all APIs required by the task. If a decrease in recall is found for a certain type of complex task (such as creating a virtual machine with disk), the radius of the graph traversal is automatically expanded or the relevance propagation threshold is adjusted to supplement any missing relevant APIs.

[0327] Real-time monitoring of the number of context tokens used in each interaction with the large language model. Setting a token budget cap, when the token consumption of a certain type of high-frequency query approaches the cap, automatically triggering a more aggressive block-level text compression strategy, such as further shortening the summary length or introducing a more refined authorization list filter, thereby controlling the token consumption of a single request to below 70% of the baseline while ensuring planning quality, significantly reducing inference costs.

[0328] The system tracks the total time taken from receiving a user query to returning a final natural language response. Each module within the system (embedding, retrieval, GNN encoding, LLM inference, and execution) has its own independent timer. If an abnormally high latency is detected during the GNN encoding or graph traversal phase, the system can automatically switch to a lightweight approximate retrieval mode or enable pre-computation caching to ensure a good user experience.

[0329] 2. Caching and reuse.

[0330] For the same natural language query text, the generated query vector is deterministic. The system caches the corresponding query vector using the hash value of the query text as the key, avoiding repeated calls to the embedding model for frequently repeated queries (such as "view cloud host list").

[0331] The API subgraph structure returned by the retrieval layer is cached using the query vector or its quantized approximation as the key. Since the same intent often corresponds to the same set of APIs, this caching can significantly reduce the overhead of graph traversal and vector similarity calculation.

[0332] Using "API subgraph + user query key parameters" as the composite key, the final execution DAG generated by the planning layer is cached. This is the most valuable cache because it directly reuses the most time-consuming LLM planning process. For example, when different users request to create virtual machines with the same configuration, the system can directly reuse the cached execution plan, only needing to replace the specific user ID or resource ID in the parameter filling stage, thereby reducing the planning latency from seconds to milliseconds.

[0333] 3. Security and access control.

[0334] In the graph traversal and retrieval phase, role-based access control is introduced. For each candidate API node, the current user's permission set (user_scopes) is checked in real time against the API's required security scope (required_scopes). If required_scopes... If `user_scopes` is set, the relevance score of that node is set to zero during graph propagation, and its outgoing edges are blocked from propagating. This means that users cannot see APIs they are not authorized to call in the search results, fundamentally eliminating the possibility of LLM generating invalid or non-compliant plans.

[0335] When generating the ExecDAG, the planner performs a permission consistency check again. If any task node in the plan lacks the necessary permissions, the system will refuse to generate the plan and return an explicit permission deficiency message to the user, rather than waiting until execution to report an error.

[0336] In private cloud or SaaS multi-tenant scenarios, the system strictly isolates data from different tenants. Graph retrieval, cached key-value pairs, and execution contexts are all forcibly bound to tenant_id. For example, the cache key is {tenant_id:A, query_hash:xyz}, ensuring that tenant A's query results, execution plans, and API call logs will never be leaked or mixed into tenant B's data, meeting enterprise-level data security compliance requirements.

[0337] Through the complete implementation process described above, this application achieves fully automated, high-accuracy, low-latency, and adaptive end-to-end closed-loop execution from natural language instructions to complex API tasks. Without relying on LLM fine-tuning, the system significantly improves task execution success rate (up to 93% in actual tests) and reduces LLM call costs by 30%–50% through graph structure guidance and meta-tool collaboration. It also possesses millisecond-level API change response capabilities, providing a new intelligent and reliable API orchestration paradigm for large-scale, dynamically evolving cloud management platforms.

[0338] Figure 5 This application provides a structural diagram of an application programming interface (API) invocation device, as shown in the embodiments below. Figure 5 As shown, the device includes:

[0339] The receiving module 51 is used to receive query content.

[0340] The determination module 52 is used to determine the target subgraph in the knowledge graph that matches the query intent of the query content, wherein the nodes in the knowledge graph include: application programming interface nodes for representing application programming interfaces.

[0341] The first processing module 53 is used to compress the target sub-image to obtain the target feature representation.

[0342] The second processing module 54 is used to retain the first type of fields in the target subgraph and to compress the second type of fields in the target subgraph to obtain summary information; wherein, the first type of fields are used to represent at least the parameter metadata when the application programming interface node is called, and the second type of fields are used to represent at least the descriptive information of the parameter metadata.

[0343] Encoding module 55 is used to encode the target subgraph into a graph embedding vector.

[0344] The encapsulation module 56 is used to encapsulate the target feature representation, the first type of field, the summary information, and the graph embedding vector into the prompt information, and to analyze the encapsulation result using a generative model to obtain a directed graph.

[0345] Execution module 57 is used to convert a directed graph into an application programming interface (API) call sequence and execute the API call sequence.

[0346] Optionally, the application programming interface (API) invocation device further includes: an API knowledge graph construction module, configured to: obtain an API definition file; extract a first type of field and a second type of field from the API definition file; compress fields in the second type of field that do not belong to a preset field set to obtain non-key semantic representations; generate API nodes based on key structured information and non-key semantic representations, wherein the key structured information includes the first type of field and fields in the second type of field that belong to the preset field set; determine the relationships between API nodes; and generate a knowledge graph based on the relationships between API nodes.

[0347] Optionally, the application programming interface (API) invocation device further includes: a text compression model training module, used to: compress fields in the second type of fields that do not belong to the preset field set using the text compression model to obtain non-key semantic representations; wherein, the text compression model is trained through the following steps: obtaining the API function description text; performing text cleaning and word segmentation on the API function description text to obtain an initial training sample set; using the encoding network to be trained to extract the initial semantic distribution features of the function description text in the latent space of the initial training sample set, wherein the latent space is used to represent the semantic mapping relationship of the API function description text; constructing positive and negative sample pairs based on the initial training sample set; in the latent space, using a contrastive loss function to minimize the semantic bias loss between the initial semantic distribution features and the positive samples, while maximizing the semantic distance between the initial semantic distribution features and the negative samples, so that the encoding network learns the core semantic information in the API function description text; limiting the dimension of the output features in the output layer of the encoding network, and obtaining the text compression model when the contrastive loss function satisfies the preset convergence condition.

[0348] Optionally, the application programming interface (API) invocation device further includes: a global API invocation sequence processing module, used for: acquiring invocation logs; reconstructing the invocation logs based on session identifiers to obtain a global API invocation sequence; processing the global API invocation sequence using a sequence processing model to obtain the association relationship between API nodes; wherein, the sequence processing model is trained through the following steps: extracting multiple historical API invocation sequences from historical invocation logs, dividing each historical API invocation sequence into an input subsequence and a corresponding target API node using a sliding window; mapping the input subsequence to a latent feature vector at a time step using a neural network model, and predicting the probability distribution of the API node appearing at the next time step based on the latent feature vector; calculating the prediction deviation between the probability distribution and the target API node using a loss function, and adjusting the parameters of the neural network model based on the prediction deviation until the loss function meets a preset convergence condition, thereby obtaining the sequence processing model.

[0349] Optionally, the application programming interface (API) invocation device further includes: a candidate edge verification and promotion module, used to: extract the association strength quantification parameters between adjacent API nodes, and determine the association strength quantification parameters as the initial weights of the directed edges between the corresponding API nodes; if the initial weights are not lower than a preset weight threshold, write the corresponding directed edges as valid dependency edges into the knowledge graph; if the initial weights are lower than the preset weight threshold, determine the corresponding directed edges as candidate edges, and perform the following steps: obtain the non-key semantic representations of the source API node and the destination API node corresponding to the candidate edge, and combine the non-key semantic representations with preset verified dependency pairs to generate a sample for use in the knowledge graph. The system generates prompts representing the logical connections between business applications. These prompts are then input into a generative model, which analyzes the sequential dependencies between the source and destination application programming interface (API) nodes in terms of functional semantics to obtain a logical confidence score. If the logical confidence score exceeds a first threshold, historical call contexts, including those of the source API node, are extracted from historical session data. The destination API node is then injected into the historical call context for simulated execution, and the parameter passing status and response status code are detected during the simulation. If the parameter passing status conforms to the preset input specification of the destination API node and the response status code is a preset success code, the candidate edge is written into the knowledge graph as a valid dependency edge.

[0350] Optionally, the application programming interface (API) invocation device further includes: a candidate edge observation and promotion module, used to: determine that a candidate edge has passed the verification of simulated execution and generate corresponding identification information when the parameter transmission status conforms to the preset input specification of the target API node and the response status code is a preset success code; write the candidate edge into the candidate edge pool and configure an initial observation counter for the candidate edge; obtain the execution flow of the production environment and extract the actual call path of the candidate edge in the execution flow; perform an accumulation operation on the initial observation counter when the actual call path is successfully executed; and remove the candidate edge from the candidate edge pool and write it into the knowledge graph as a valid dependency edge in response to the initial observation counter reaching a preset promotion threshold.

[0351] Optionally, the application programming interface calling device further includes: a weight correction module, used to: configure a corresponding weight correction coefficient for the effective dependency edge based on the identification information during the process of writing the candidate edge as an effective dependency edge into the knowledge graph, so as to correct the initial weight; the corrected weight of the effective dependency edge carrying the identification information is greater than the initial weight.

[0352] Optionally, the application programming interface (API) invocation device further includes: a query vector generation module, used to: vectorize the query content using a dual encoder model to obtain a query vector; wherein the dual encoder model is trained through the following steps: obtaining historical API call logs and corresponding historical work order description information; extracting the association pairs between historical query content and API nodes from the historical API call logs and corresponding historical work order description information, and using the association pairs as initial training samples; generating pseudo-query text based on the description information of API nodes to construct enhanced training samples; inputting the initial training samples and enhanced training samples into the dual encoder model respectively to obtain the corresponding query vector and API vector, wherein the dual encoder model... The encoder model includes a first encoder for encoding query content and a second encoder for encoding application programming interfaces (APIs). A contrastive learning task is used to calculate the distance between the query vector and the API vector in the same semantic space, and the representations in the semantic space are aligned based on this distance. Simultaneously with the contrastive learning task, joint training is performed using a tool usage detection task and a domain vocabulary alignment task. The tool usage detection task determines whether the query content has the intent to call an API, while the domain vocabulary alignment task establishes a mapping relationship between different terminology databases. The parameters of the dual encoder model are adjusted based on the weighted loss function of the contrastive learning task, the tool usage detection task, and the domain vocabulary alignment task until a preset training objective is met, resulting in the dual encoder model.

[0353] Optionally, the application programming interface calling device further includes: a graph traversal and scene enhancement module, used to: assign initial relevance scores to each initial seed node based on the semantic similarity between the query vector and the initial seed nodes; based on the initial relevance scores, propagate the relevance scores of the current node to its neighboring nodes along directed edges in the knowledge graph in multiple rounds until a preset propagation depth is reached; wherein, in each round of propagation, the score of the current node is weighted based on the initial weight of the directed edges to calculate the new relevance scores of the neighboring nodes; the new relevance scores obtained by each neighboring node in the multiple rounds of propagation are accumulated to obtain the cumulative relevance scores of each neighboring node; and the nodes with the largest cumulative relevance scores are selected from all neighboring nodes. The process involves: initially associating application programming interface (API) nodes with a preset score threshold; matching business scenario nodes corresponding to the query content in the association model, where the association model includes the association relationship between query intent, business scenario, and API nodes, and is used to represent the logical aggregation relationship between API nodes that do not have a direct dependency relationship in a specific business scenario; determining a first set of API nodes that have a mapping relationship with business scenario nodes in the association model; filtering API nodes related to the query intent from the first set of API nodes; and supplementing the filtered API nodes into the initial associated API nodes to obtain associated API nodes.

[0354] Optionally, the application programming interface (API) invocation device further includes: a graphics compressed data packet generation module, configured to: obtain pre-trained embedding vectors corresponding to API nodes in the target subgraph; perform bit-width compression-based quantization processing on the pre-trained embedding vectors to obtain quantized feature vectors; assign logical indices to API nodes in the target subgraph and generate an index lookup table to record the mapping relationship between logical indices and API node identifiers; and encapsulate the quantized feature vectors, the index lookup table, and the version identifier information of the target subgraph into a graphics compressed data packet in a preset format to obtain a target feature representation.

[0355] Optionally, the application programming interface calling device further includes: an adaptive compression control module, used to: obtain the count value of the input tokens in a single inference request of the generative model; compare the count value with a preset resource overhead threshold, and determine the context length deviation rate based on the comparison result; generate a gain adjustment signal for the feature compression operator when the deviation rate reaches a preset trigger condition; and perform compression processing on the target subgraph based on the pruning frequency indicated by the gain adjustment signal.

[0356] Optionally, the application programming interface calling device further includes: a dynamic encapsulation module, used to: encapsulate the target feature representation, the first type field, the summary information, and the graph embedding vector into the prompt information according to the improved pruning frequency, wherein the character length of the encapsulation result is less than the character length threshold corresponding to the resource overhead threshold.

[0357] Optionally, the application programming interface (API) invocation device further includes: a graph embedding vector generation module, configured to: use the semantic vector of the API node in the target subgraph as initial node features, and use the relationship type and weight between API nodes as edge features; use a graph neural network to extract the node features of the neighboring nodes of the API node; perform weighted calculation on the node features of the neighboring nodes of the API node based on the edge features, and aggregate the calculation result with the current embedding representation of the API node to obtain an updated embedding representation; wherein the initial value of the current embedding representation is the initial node features; perform neighborhood feature extraction and weighted aggregation processing through multiple iterations to cyclically update the embedding representation of the API node; and perform pooling operation on the embedding representation of the API node after multiple iterations to obtain a graph embedding vector.

[0358] Optionally, the application programming interface (API) invocation device further includes: a graph neural network incremental training module, used to: update the corresponding node attributes and edge weights in the knowledge graph in response to changes in API nodes or dependencies between API nodes in the knowledge graph; extract the changed target subgraph from the updated knowledge graph; perform incremental training on the graph neural network using the changed target subgraph, wherein the incremental training maps different topologies before and after the change to the same task mode vector space by adjusting the weight parameters of the graph neural network, so that each vector point in the task mode vector space represents a business logic model; the business logic model is used to represent the topological dependencies and parameter passing paths across API nodes; during the incremental training process, calculate the similarity index between the graph embedding vector generated by the changed target subgraph for the same business logic model and the graph embedding vector generated by the target subgraph before the change; determine whether the similarity index meets a preset similarity threshold, and if it does, determine that the graph neural network has completed incremental training, so that the generative model can identify the business logic model without changing its own parameters.

[0359] Optionally, the application programming interface (API) invocation device further includes a task decomposition and multi-agent collaboration module, used to: after determining the target subgraph in the knowledge graph that matches the query intent of the query content, perform the following steps: divide the target subgraph into multiple task modules, wherein each task module is a set of application programming interface nodes with logical aggregation in the target subgraph; determine a first complexity index characterizing the modularity of the tasks, and a second complexity index characterizing the coupling strength between each task module; if both the first and second complexity indices satisfy the corresponding preset logical thresholds, split the target subgraph into multiple local subgraphs corresponding to the task modules, wherein the preset logical thresholds are used to define whether the target subgraph has divisibility and independence after splitting; distribute the multiple local subgraphs to multiple parallel-running agent models, wherein the agent models are used to generate sub-execution graphs within the corresponding local graph scope; and perform topological splicing of each sub-execution graph according to the global dependencies in the target subgraph to obtain the updated target subgraph.

[0360] Optionally, the application programming interface (API) invocation device further includes an execution state management and compensation module, configured to: after executing the API invocation sequence, perform the following steps: maintain the execution state of each API node in the directed graph and record the execution state of each API node in the execution context; in response to a first message indicating an invocation conflict or state anomaly, compare the entity resource state in the target environment entity associated with the first message with the execution context, and perform state synchronization for the execution context or entity resource based on the comparison result; in response to a second message indicating an invocation failure, execute a preset compensation node along the reverse topology direction of the directed graph starting from the failed node, so as to roll back the entity resource and execution context to a preset stable mode.

[0361] Optionally, the application programming interface (API) invocation device further includes: a natural language response generation module, used to: extract raw response data from multiple API nodes from the execution context, and summarize the related business indicators across API nodes according to the query intent; generate structured intermediate calculation results corresponding to the summarized raw response data; encapsulate the query content, intermediate calculation results, and raw response data into a preset response prompt template to obtain a natural language answer for the query intent; and send the natural language answer to the client.

[0362] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0363] For a description of the features of the embodiment corresponding to the application programming interface (API) invocation device, please refer to the relevant description of the embodiment corresponding to the API invocation method, which will not be repeated here.

[0364] Figure 6 This application provides a hardware structure block diagram of a computer terminal for a method of calling an application programming interface, as shown in the embodiments below. Figure 6 As shown, the computer terminal 60 may include one or more processors (processors may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 604 for storing data, and a transmission module 606 for communication functions. Figure 6 The illustration uses multiple processors, including a first processor 602a, a second processor 602b, ..., an nth processor 602n. In addition, it may include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 6 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the computer terminal 60 may also include... Figure 6 The more or fewer components shown, or having the same Figure 6 The different configurations shown.

[0365] It should be noted that the aforementioned one or more processors and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be implemented wholly or partially as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be wholly or partially integrated into any other element in the computer terminal 60. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0366] The memory 604 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the application programming interface (API) calling method in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 604, thereby implementing the aforementioned API calling method. The memory 604 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 604 may further include memory remotely located relative to the processor, which can be connected to the computer terminal 60 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof.

[0367] The transmission module 606 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 60. In one example, the transmission module 606 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission module 606 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0368] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 60.

[0369] It should be noted here that, in some optional embodiments, the above... Figure 6 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 6 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0370] It should be noted that, Figure 6 For a description of the features in the corresponding embodiments, please refer to the relevant description of the embodiments corresponding to the application programming interface calling methods, which will not be repeated here.

[0371] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described application programming interface invocation method embodiments.

[0372] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described application programming interface invocation method embodiments at runtime.

[0373] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0374] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the above-described application programming interface invocation method embodiments.

[0375] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the calling method embodiments of any of the above application programming interfaces.

[0376] 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 implementation should not be considered beyond the scope of this application.

[0377] The foregoing has provided a detailed description of the method, apparatus, and electronic device for invoking an application programming interface (API) provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.< / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt> < / gpkt>

Claims

1. A method of invoking an application programming interface, characterized by, include: Receive query content; In the knowledge graph, a target subgraph matching the query intent of the query content is determined, wherein the nodes in the knowledge graph include: application programming interface nodes for representing application programming interfaces; The target sub-graph is compressed to obtain a target feature representation; The first type of fields in the target subgraph are retained, and the second type of fields in the target subgraph are compressed to obtain summary information; wherein, the first type of fields are used at least to represent the parameter meta-information when the application programming interface node is called, and the second type of fields are used at least to represent the descriptive information of the parameter meta-information; The target subgraph is encoded into a graph embedding vector; The target feature representation, the first type of field, the summary information, and the graph embedding vector are encapsulated into the prompt information, and the encapsulation result is analyzed using a generative model to obtain a directed graph; The directed graph is transformed into an application programming interface (API) call sequence, and the API call sequence is executed.

2. The method of claim 1, wherein, The knowledge graph was generated through the following steps: Obtain the application programming interface definition file; Extract the first type of fields and the second type of fields from the application programming interface definition file; Fields in the second category that do not belong to the preset field set are compressed to obtain non-critical semantic representations; Based on the key structured information and the non-key semantic representation, the application programming interface node is generated, wherein the key structured information includes the first type of fields and the fields in the second type of fields that belong to the preset field set; Determine the relationships between the application programming interface nodes; The knowledge graph is generated based on the application programming interface (API) nodes and the relationships between them.

3. The method of invoking an application programming interface according to claim 2, wherein, Fields in the second category that do not belong to the preset field set are compressed to obtain non-critical semantic representations, including: The non-key semantic representation is obtained by compressing the fields in the second type of fields that do not belong to the preset field set using a text compression model. The text compression model is trained through the following steps: Get the application programming interface (API) function description text; The application programming interface (API) function description text is cleaned and segmented to obtain an initial training sample set. The initial semantic distribution features of the functional description text in the latent space of the initial training sample set are extracted using the encoding network to be trained, wherein the latent space is used to characterize the semantic mapping relationship of the application programming interface functional description text; Construct positive and negative sample pairs based on the initial training sample set; In the latent space, the contrastive loss function is used to minimize the semantic bias loss between the initial semantic distribution features and positive samples, while maximizing the semantic distance between the initial semantic distribution features and negative samples, so that the encoding network can learn the core semantic information in the application programming interface function description text; The dimension of the output features is defined in the output layer of the encoding network, and the text compression model is obtained when the contrastive loss function satisfies the preset convergence condition.

4. The method of claim 2, wherein the application programming interface is invoked by a user. Determining the relationships between the application programming interface nodes includes: Get the call log; The call log is reconstructed based on the session identifier to obtain the global application programming interface call sequence; The global application programming interface (API) call sequence is processed using a sequence processing model to obtain the association relationships between the API nodes; The sequence processing model is trained through the following steps: Extract multiple historical application programming interface (API) call sequences from the historical call log, and use a sliding window to divide each historical API call sequence into an input subsequence and a corresponding target API node; The input subsequence is mapped to a latent feature vector at a time step using a neural network model, and the probability distribution of the application programming interface node appearing at the next time step is predicted based on the latent feature vector. The prediction deviation between the probability distribution and the target application programming interface node is calculated using a loss function, and the parameters of the neural network model are adjusted based on the prediction deviation until the loss function meets a preset convergence condition, thus obtaining the sequence processing model.

5. The method of claim 2, wherein the application programming interface is invoked by a user. Based on the application programming interface (API) nodes and the relationships between them, a knowledge graph is generated, including: Extract the association strength quantization parameter between adjacent application programming interface nodes, and determine the association strength quantization parameter as the initial weight of the directed edge between the corresponding application programming interface nodes; If the initial weight is not lower than the preset weight threshold, the corresponding directed edge is written into the knowledge graph as a valid dependency edge. If the initial weight is lower than the preset weight threshold, the corresponding directed edge is determined as a candidate edge, and the following steps are performed: Obtain the non-critical semantic representations of the source application programming interface node and the destination application programming interface node corresponding to the candidate edge, and combine the non-critical semantic representations with the preset verified dependency pair sample to generate prompt information for representing the business logic correlation. The prompt information is input into the generative model, and the generative model is used to analyze the sequential dependency relationship between the source application programming interface node and the destination application programming interface node in terms of functional semantics, so as to obtain the logical confidence. If the logical confidence level is greater than the first threshold, extract the historical call context, including the source application programming interface node, from the historical session data; The target application programming interface node is injected into the historical call context for simulated execution, and the parameter passing status and response status code during the simulated execution process are detected. If the parameter transmission status conforms to the preset input specification of the target application programming interface node and the response status code is a preset success code, the candidate edge is written into the knowledge graph as a valid dependency edge.

6. The method for calling the application programming interface according to claim 5, characterized in that, When the parameter transmission status conforms to the preset input specification of the target application programming interface node and the response status code is a preset success code, the candidate edge is written as a valid dependency edge into the knowledge graph, including: If the parameter transmission status conforms to the preset input specification of the target application programming interface node and the response status code is a preset success code, the candidate edge is determined to have passed the verification of the simulated execution, and corresponding identification information is generated, wherein the identification information is used to characterize the verification source; Write the candidate edges into the candidate edge pool and configure an initial observation counter for the candidate edges; Obtain the execution flow of the production environment and extract the actual call path of the candidate edge in the execution flow; If the actual call path is executed successfully, the initial observation counter is incremented. In response to the initial observation counter reaching a preset advancement threshold, the candidate edge is removed from the candidate edge pool and written into the knowledge graph as the effective dependency edge.

7. The method for calling the application programming interface according to claim 6, characterized in that, The method further includes: during the process of writing the candidate edge as the effective dependency edge into the knowledge graph, configuring a corresponding weight correction coefficient for the effective dependency edge based on the identification information to correct the initial weight; the corrected weight of the effective dependency edge carrying the identification information is greater than the initial weight.

8. The method for calling the application programming interface according to claim 1, characterized in that, Determining a target subgraph in the knowledge graph that matches the query intent of the query content includes: The query content is vectorized to obtain a query vector; Calculate the semantic similarity between the query vector and the application programming interface (API) vector of the API node in the knowledge graph, and select one or more candidate API nodes with a semantic similarity greater than a preset similarity threshold as initial seed nodes in the knowledge graph; Starting from the initial seed node, iteratively traverse along the directed edges in the knowledge graph to identify associated application programming interface nodes that have a direct or indirect relationship with the initial seed node. Obtain the target directed edge between the initial seed node and the associated application programming interface node; The importance of the application programming interface nodes is ranked based on the semantic similarity and the initial weights corresponding to the target directed edges, and the target subgraph is constructed according to the ranking results.

9. The method for calling the application programming interface according to claim 8, characterized in that, The query content is vectorized to obtain a query vector, including: The query content is vectorized using a dual encoder model to obtain a query vector. The dual encoder model is trained through the following steps: Obtain historical application programming interface (API) call logs and corresponding historical work order descriptions; extract the association pairs between historical query content and API nodes from the historical API call logs and corresponding historical work order descriptions; and use the association pairs as initial training samples. Pseudo-query text is generated based on the description information of the application programming interface node to construct enhanced training samples; The initial training samples and the enhanced training samples are respectively input into the dual encoder model to obtain the corresponding query vector and application programming interface vector. The dual encoder model includes a first encoder for encoding the query content and a second encoder for encoding the application programming interface. The distance between the query vector and the application programming interface vector in the same semantic space is calculated using a contrastive learning task, and the representations of the semantic space are aligned based on the distance. While performing the comparative learning task, joint training is performed through a tool usage detection task and a domain vocabulary alignment task. The tool usage detection task is used to determine whether the query content has the intent to call an application programming interface, and the domain vocabulary alignment task is used to establish the mapping relationship between different terminology databases. The parameters of the dual encoder model are adjusted based on the weighted loss functions of the contrastive learning task, the tool use detection task, and the domain vocabulary alignment task until the preset training objective is met, thus obtaining the dual encoder model.

10. The method for invoking the application programming interface according to claim 8, characterized in that, Starting from the initial seed node, an iterative traversal is performed along the directed edges in the knowledge graph to identify associated application programming interface (API) nodes that have a direct or indirect relationship with the initial seed node, including: Based on the semantic similarity between the query vector and the initial seed node, an initial relevance score is assigned to each of the initial seed nodes; Based on the initial relevance score, the relevance score of the current node is propagated to the neighboring nodes of the current node in multiple rounds along the directed edges in the knowledge graph until a preset propagation depth is reached; wherein, in each round of propagation, the score of the current node is weighted and allocated based on the initial weight of the directed edges to calculate the new relevance score of the neighboring nodes. The newly added relevance scores obtained by each neighbor node during multiple rounds of propagation are summed to obtain the cumulative relevance score of each neighbor node. Filter out the initial associated application programming interface nodes whose cumulative correlation scores are greater than a preset score threshold from all the neighbor nodes; In the association model, the business scenario node corresponding to the query content is matched. The association model includes the association relationship between query intent, business scenario and application programming interface node. The association model is used to represent the logical aggregation relationship between application programming interface nodes that do not have a direct dependency relationship in a specific business scenario. In the association model, a first set of application programming interface (API) nodes that have a mapping relationship with the business scenario node is determined. From the first set of API nodes, API nodes related to the query intent are filtered out, and the filtered API nodes are added to the initial associated API nodes to obtain the associated API nodes.

11. The method for calling the application programming interface according to claim 1, characterized in that, The target sub-graph is compressed to obtain a target feature representation, including: Obtain the pre-trained embedding vectors corresponding to the application programming interface nodes in the target subgraph; The pre-trained embedding vector is subjected to bit-width compression-based quantization to obtain a quantized feature vector; Assign logical indexes to the application programming interface nodes in the target subgraph, and generate an index lookup table to record the mapping relationship between the logical indexes and the application programming interface node identifiers; The quantized feature vector, the index lookup table, and the version identification information of the target subgraph are encapsulated into a pre-formatted graphic compressed data packet to obtain the target feature representation.

12. The method for calling the application programming interface according to claim 1, characterized in that, The target sub-graph is compressed to obtain a target feature representation, including: Obtain the count value of the input tokens in a single inference request for the generative model; The count value is compared with a preset resource overhead threshold, and the context length deviation rate is determined based on the comparison result. When the deviation rate reaches a preset trigger condition, a gain adjustment signal for the feature compression operator is generated; Based on the pruning frequency indicated by the gain adjustment signal, the target subgraph is compressed. The target feature representation, the first type of field, the summary information, and the graph embedding vector are encapsulated into the prompt information, including: The target feature representation, the first type of field, the summary information, and the graph embedding vector are encapsulated into the prompt information according to the improved pruning frequency, wherein the character length of the encapsulation result is less than the character length threshold corresponding to the resource overhead threshold.

13. The method for calling the application programming interface according to claim 1, characterized in that, Encoding the target subgraph into a graph embedding vector includes: The semantic vectors of the application programming interface nodes in the target subgraph are used as initial node features, and the relationship types and weights between the application programming interface nodes are used as edge features. Using a graph neural network, the node features of the neighboring nodes of the application programming interface node are extracted; The node features of the neighboring nodes of the application programming interface node are weighted based on the edge features, and the calculation result is aggregated with the current embedding representation of the application programming interface node to obtain the updated embedding representation; wherein, the initial value of the current embedding representation is the initial node features; The embedded representation of the application programming interface node is updated cyclically by performing neighborhood feature extraction and weighted aggregation processing through multiple rounds of iteration. The embedded representations of the application programming interface nodes after multiple iterations are pooled to obtain the graph embedding vector.

14. The method for invoking the application programming interface according to claim 13, characterized in that, The method further includes: In response to changes in the application programming interface (API) nodes or dependencies between API nodes in the knowledge graph, update the corresponding node attributes and edge weights in the knowledge graph. Extract the modified target subgraph from the updated knowledge graph; The graph neural network is incrementally trained using the modified target subgraph. The incremental training maps different topologies before and after the modification to the same task mode vector space by adjusting the weight parameters of the graph neural network, so that each vector point in the task mode vector space represents a business logic model. The business logic model is used to represent the topological dependencies and parameter passing paths of cross-application programming interface nodes. During the incremental training process, the similarity index between the graph embedding vector generated by the modified target subgraph for the same business logic model and the graph embedding vector generated by the target subgraph before the modification is calculated. Determine whether the similarity index meets the preset similarity threshold. If it does, determine that the graph neural network has completed the incremental training so that the generative model can identify the business logic model without changing its own parameters.

15. The method for invoking the application programming interface according to claim 1, characterized in that, After determining the target subgraph in the knowledge graph that matches the query intent of the query content, the method further includes: The target subgraph is divided into multiple task modules, wherein the task module is a set of application programming interface nodes with logical aggregation in the target subgraph; A first complexity index is determined to characterize the degree of task modularity, and a second complexity index is determined to characterize the coupling strength between the task modules. When both the first complexity index and the second complexity index meet the corresponding preset logical thresholds, the target subgraph is split into multiple local subgraphs corresponding to the task module. The preset logical thresholds are used to define whether the target subgraph is divisible and independent after splitting. The multiple local subgraphs are distributed to multiple parallel-running proxy models, wherein the proxy models are used to generate sub-execution graphs within the scope of the corresponding local graphs; Based on the global dependencies in the target subgraph, the sub-execution graphs are topologically concatenated to obtain the updated target subgraph.

16. The method for calling the application programming interface according to claim 1, characterized in that, After executing the application programming interface call sequence, the method further includes: Maintain the execution state of each application programming interface node in the directed graph, and record the execution state of each application programming interface node in the execution context; In response to a first message used to characterize a call conflict or state anomaly, the state of entity resources in the target environment entity associated with the first message is compared with the execution context, and state synchronization is performed for the execution context or the entity resources based on the comparison result. In response to a second message indicating a failed call, a preset compensation node is executed from the failed node along the reverse topology of the directed graph to roll back the entity resources and the execution context to a preset stable mode.

17. The method for invoking an application programming interface according to claim 16, characterized in that, The method further includes: Extract raw response data from multiple application programming interface nodes from the execution context, and summarize the associated business metrics across the application programming interface nodes according to the query intent; Generate structured intermediate calculation results corresponding to the summarized raw response data; The query content, the intermediate calculation results, and the original response data are encapsulated into a preset response prompt template to obtain a natural language answer to the query intent; The natural language response is sent to the client.

18. A device for invoking an application programming interface (API), characterized in that, include: The receiving module is used to receive query content; The determination module is used to determine a target subgraph in the knowledge graph that matches the query intent of the query content, wherein the nodes in the knowledge graph include: application programming interface nodes for representing application programming interfaces; The first processing module is used to compress the target sub-graph to obtain a target feature representation; The second processing module is used to retain the first type of fields in the target subgraph and to compress the second type of fields in the target subgraph to obtain summary information; wherein, the first type of fields are used to represent at least the parameter metadata when the application programming interface node is called, and the second type of fields are used to represent at least the descriptive information of the parameter metadata. The encoding module is used to encode the target subgraph into a graph embedding vector; The encapsulation module is used to encapsulate the target feature representation, the first type of field, the summary information, and the graph embedding vector into the prompt information, and to analyze the encapsulation result using a generative model to obtain a directed graph; An execution module is used to convert the directed graph into an application programming interface (API) call sequence and execute the API call sequence.

19. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the method of invoking the application programming interface as described in any one of claims 1 to 17 when executing the computer program.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method of invoking the application programming interface as described in any one of claims 1 to 17.

21. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of calling the application programming interface as described in any one of claims 1 to 17.

Images