Query processing method and device, computer device and storage medium

Abstract

This application relates to a query processing method, apparatus, computer device, storage medium, and computer program product. The method includes: retrieving query content and skill documents matching the query content; determining an adapter matching the skill document based on the protocol specifications followed by the skill document; extracting skill metadata such as server endpoints and call parameters from the skill document by parsing it; and calling the skill tools provided by the server endpoint through the adapter according to the underlying call logic and call parameters to obtain the query results corresponding to the query content. Using the above method can improve the flexibility of query processing.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a query processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of computer technology, intelligent dialogue systems based on artificial intelligence agents (AI agents) have gradually become a research and application hotspot. These systems are built upon large language models (LLMs) and are capable of autonomous understanding, perception, planning, memorization, and tool usage. In terms of technical architecture, AI agents have shifted from a process-oriented architecture to a goal-oriented architecture, aiming to complete complex tasks through a close integration of perception, thinking, and action.

[0003] In traditional technologies, to support agents in calling external skills or tools, tool invocation logic is typically integrated into the backend of a large language model through hard coding. In this model, the tool invocation logic of the large language model is often highly coupled with the adopted protocol specifications, making it difficult for the system's tool invocation architecture to flexibly adapt to protocol changes and tool expansions, thus reducing the flexibility of the query processing. Summary of the Invention

[0004] Therefore, it is necessary to provide a query processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve system flexibility in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a query processing method. The method includes:

[0006] Retrieve the query content and the skill documents that match the query content;

[0007] Based on the protocol specifications followed by the skill document, an adapter matching the skill document is determined; the adapter encapsulates the underlying calling logic specific to the protocol specifications.

[0008] By parsing the skill document, skill metadata is extracted from the skill document; the skill metadata includes the service endpoint for providing the skill declared in the skill document, and the calling parameters for the service endpoint;

[0009] The adapter invokes the skill tools provided by the server endpoint according to the underlying invocation logic and the invocation parameters to obtain the query results corresponding to the query content.

[0010] Secondly, this application also provides a query processing apparatus. The apparatus includes:

[0011] The acquisition module is used to acquire the query content and the skill documents that match the query content;

[0012] An adapter module is used to determine an adapter that matches the skill document based on the protocol specifications followed by the skill document; the adapter encapsulates the underlying calling logic specific to the protocol specifications.

[0013] The metadata extraction module is used to extract skill metadata from the skill document by parsing the skill document; the skill metadata includes the service endpoint for providing the skill declared in the skill document, and the calling parameters for the service endpoint;

[0014] The skill invocation module is used to invoke the skill tools provided by the server endpoint through the adapter according to the underlying invocation logic and the invocation parameters, and obtain the query results corresponding to the query content.

[0015] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the above-described query processing method.

[0016] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, implements the steps of the above-described query processing method.

[0017] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, implements the steps of the above-described query processing method.

[0018] The aforementioned query processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product acquire query content and skill documents matching the query content, and determine the adapter matching the skill document based on the protocol specifications followed by the skill document. Since the adapter encapsulates the underlying calling logic specific to the protocol specifications, the underlying calling logic of different protocol specifications can be encapsulated into different adapters, so that the declaration of the tool itself is no longer bound to a specific protocol, achieving decoupling between the tool and the protocol, which is beneficial to improving flexibility. Next, by parsing the skill document, skill metadata such as the server endpoint and calling parameters are extracted from the skill document, and the adapter calls the skill tools provided by the server endpoint according to the underlying calling logic and calling parameters to obtain the query results corresponding to the query content. Thus, the adapter can dynamically determine and call the corresponding skill tools according to the protocol followed by the skill information, enabling the system to simultaneously support mixed calls of tools under multiple protocol specifications without requiring the user to perceive underlying differences, which further improves the flexibility of query processing. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying 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.

[0020] Figure 1 This is a diagram illustrating the application environment of the query processing method in some embodiments;

[0021] Figure 2 This is a schematic diagram of the query processing method in some embodiments;

[0022] Figure 3 This is a flowchart illustrating the query processing method in some embodiments;

[0023] Figure 4 This is a schematic diagram illustrating the content structure of a skills document in some embodiments;

[0024] Figure 5 This is a schematic diagram of the structure of a standardized protocol descriptor in some embodiments;

[0025] Figure 6 This is a schematic diagram illustrating the configuration information of skill documents in some embodiments;

[0026] Figure 7 This is a schematic diagram of the adapter matching process in some embodiments;

[0027] Figure 8This is a schematic diagram illustrating the contents of the adapter structure in some embodiments;

[0028] Figure 9 This is a schematic diagram illustrating the expansion process of newly added protocols in some embodiments;

[0029] Figure 10 This is a schematic diagram illustrating the compatibility process of existing historical documents in some embodiments;

[0030] Figure 11 This is a flowchart illustrating the query processing method in some other embodiments;

[0031] Figure 12 This is a schematic diagram of the layered architecture of the query processing system in some embodiments;

[0032] Figure 13 This is a schematic diagram of the unified multi-protocol invocation process in some embodiments;

[0033] Figure 14 This is a structural block diagram of the query processing device in some embodiments;

[0034] Figure 15 These are internal structural diagrams of the computer device in some embodiments;

[0035] Figure 16 This is an internal structural diagram of a computer device in some other embodiments. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0037] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0038] The information processing method provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, the environment may include an application terminal 101, a service terminal 102, and a server terminal 103. Communication between the application terminal 101 and the server terminal 103, as well as between the service terminal 102 and the server terminal 103, can be achieved through a communication network. This communication network can be a wired network or a wireless network. Therefore, the application terminal 101 and the server terminal 103, and the service terminal 102 and the server terminal 103, can be directly or indirectly connected via wired or wireless communication. For example, the application terminal 101 can be indirectly connected to the server terminal 103 via a wireless access point, or the application terminal 101 can be directly connected to the server terminal 103 via the Internet; this application does not impose any limitations on this.

[0039] Among them, the application terminal 101 and the business terminal 102 can be terminals; the server terminal 103 can be a terminal or a server.

[0040] The terminal can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle systems. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. For example, a user can provide queries to a smart speaker via voice. Similarly, a user can input queries into a smart in-vehicle system to request navigation route planning based on real-time traffic conditions.

[0041] Optionally, the application 101 may have a client related to content query installed, which can be an application, webpage, mini-program, etc. The server 103 is the backend server corresponding to the client, or a server specifically designed to provide content query services. For example, a user can open an application installed on their smartphone, enter query content, and then the application's backend server can obtain the query content and perform query processing on it.

[0042] Optionally, server 103 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The data storage system can store the data that server 103 needs to process. The data storage system can be configured independently, integrated into server 103, or located in the cloud or on other computer devices.

[0043] In the embodiments of this application, such as Figure 1As shown, business personnel can interact with the business terminal 102 to write skill documents and upload them to the server 103. These skill documents are obtained by encapsulating natural language text; therefore, business personnel do not need programming knowledge but can write their business experience into natural language text, which the business terminal 102 can then encapsulate to obtain the skill document. Optionally, the business terminal 102 can also upload natural language text to the server 103, which will then encapsulate the natural language text to obtain the skill document.

[0044] During the application process, users can interact with the application client 101 to input query content. This query content can be further sent to the server 103 to request the corresponding query results. The server 103 can obtain the query content and the skill document matching the query content, and determine the adapter matching the skill document based on the protocol specifications followed by the skill document. The skill document can be specified by the user or obtained by the server 103 based on the query content. Next, the server 103 can parse the skill document, extract skill metadata such as the server endpoint and call parameters, and then, through the adapter, call the skill tool provided by the server endpoint according to the underlying call logic and call parameters to obtain the query results corresponding to the query content. Figure 1 The query result can be fed back to the application terminal 101.

[0045] For example, such as Figure 2As shown, the query content 201 could be, for example, "Compare model A and model B, how much do they cost recently, and is it worth buying?" The skill document 202 matches the query content 201. The protocol specification followed by the skill document 202 could be, for example, the HTTP protocol (Hypertext Transfer Protocol). Furthermore, the server 103 can determine the adapter 203 that matches the skill document 202. This adapter 203 encapsulates the underlying calling logic specific to the HTTP protocol. Next, the server 103 can extract skill metadata 204 from the skill document 202 by parsing it. The skill metadata 204 includes the server endpoint used to provide the skill declared in the skill document 202, and the calling parameters for that server endpoint. Taking the HTTP protocol as an example, the server endpoint can be represented by a URL (Uniform Resource Locator), and the calling parameters can be represented by an HTTP request method and its corresponding input parameters. The HTTP request method could include, for example, the GET method for requesting resources, the POST method for submitting data, etc. Finally, server 103 can use adapter 203 to call the skill tools provided by the server endpoint according to the underlying calling logic and calling parameters, and obtain the query result 205 corresponding to the query content 201.

[0046] Optionally, if the data processing capabilities of the application terminal 101 meet the query processing requirements, the application terminal 101 can also execute the query processing method provided in this application. Specifically, the application terminal 101 can obtain the query content, match skill documents based on the query content, and then obtain the corresponding query results through adapter matching and skill tool invocation.

[0047] Optionally, the query processing method provided in this application can also be implemented through interaction between the application terminal 101 and the server terminal 103. For example, the application terminal 101 can obtain the query content and perform skill document matching and parsing based on the query content. Optionally, the application terminal 101 can filter skill documents that match the query content from locally deployed candidate documents; the application terminal 101 can also filter skill documents that match the query content from candidate documents provided by the server. Then, the server terminal 103 performs adapter matching and skill tool invocation based on the parsing results to obtain the query results and feed them back to the application terminal 101.

[0048] Optionally, the query processing method provided in this application can also be applied to the development and testing phase of skill documents. Specifically, business personnel can provide query content that allows them to apply the skills declared in their own developed skill documents. They can then use this query content to test the skill document and determine whether it can be used correctly based on the final query results.

[0049] In summary, this application does not limit the entity that performs each step in the query processing.

[0050] In some embodiments, a query processing method is provided, which is performed by a computer device, the computer device being... Figure 1 The application terminal 101, business terminal 102, or server terminal 103 can also be a system that includes the aforementioned terminals. In the embodiments of this application, such as Figure 3 As shown, the method includes the following steps:

[0051] Step S302: Obtain the query content and the skill documents that match the query content.

[0052] The query content refers to the combination of information used to query and retrieve specific content. Optionally, the query content may include one or more elements from the following: explicit instructions, question statements, contextual background, and output format requirements, to provide sufficient and structured semantic constraints and task guidance, aiming to obtain accurate, relevant, and user-expected query results. Instructions or question statements can be used to describe the purpose of the content query. For example, the query content may include "I need to buy a tent, any purchasing advice?" or "Compare product A and product B, how much do they cost recently, and are they worth buying?", describing the query purpose in the form of a question. Similarly, the query content may include "Compare the horsepower, safety, and smart cockpit configuration of car models A, B, and C," describing the query purpose in the form of an instruction. Contextual background describes the current situation and needs. For example, the query content "I like hiking and now want to go out and live in the mountains, I need to buy a tent, any purchasing advice?" includes the contextual background "I like hiking and now want to go out and live in the mountains." Output format requirements specify the output requirements of the query results, such as "Please provide the results in list form."

[0053] Optionally, the search terms may not be limited to a single field and may include at least one of the following: healthcare, education, office work, and shopping.

[0054] Optionally, the query content can be entered in various ways, such as text or voice. In an exemplary embodiment, the application can display a query content input page, which includes a query content input box, allowing the user to enter their query content. Optionally, the application can also obtain the query content by collecting the user's voice.

[0055] In one optional embodiment, the query content may include a file and natural language requirements for that file. Taking a document analysis scenario as an example, the file may be an industry survey report uploaded by a user, and the natural language requirements for that file may be, for example, "Extract the core conclusions and key data of this report and generate a 300-word summary."

[0056] Skills documentation is a systematic record of business knowledge in written form, serving as a core asset for solidifying and passing on that knowledge. Optionally, skills documentation can cover expert experience in the business domain, task execution processes, tool usage rules, constraints, and other content, transforming this tacit knowledge into a shareable and learnable explicit medium.

[0057] Optionally, skills documentation can be obtained by encapsulating natural language text. This natural language text can be provided by business personnel. For example, business personnel can record the judgment, problem-solving intuition, and tricks for handling complex situations developed by business domain experts through long-term practice in a text file using natural language, and then encapsulate it into machine-readable skills documentation using computer equipment.

[0058] Optionally, skill documents can be obtained by using a markup language to structurally encapsulate natural language text, thereby enhancing their organization and parsability. This markup language could be, for example, Markdown, AsciiDoc, reStructuredText, or Djot.

[0059] In one exemplary embodiment, skill documents can be written based on a semi-structured natural language protocol. These skill documents can serve as a core carrier encapsulating expert experience in the business domain, task execution processes, tool usage rules, and constraints, and are central to achieving "documentation as code."

[0060] In one optional embodiment, business personnel can input a skill document and query content designed for that skill document. A computer device can then perform a query based on the skill document to obtain the corresponding query results. Business personnel can then determine the validity of the skill document based on the discrepancy between the query results and the expected results, and make corresponding corrections.

[0061] In an optional embodiment, a user can input a query, which a computer device can then retrieve and determine skill documents that match the query. Optionally, the skill document matching process can be implemented using an intelligent agent. An intelligent agent can be an autonomous software entity capable of perceiving its environment, planning, invoking tools (or its own capabilities), and performing actions to achieve a goal. An intelligent agent typically encapsulates complex logic for solving a specific type of problem and possesses the ability to autonomously understand, perceive, plan, remember, and use tools.

[0062] In one exemplary embodiment, the agent can employ a "thinking + action" reasoning pattern when determining the query content. Thinking refers to the agent analyzing the current situation and considering what to do next, while action refers to the action performed by the agent, typically by invoking tools. Optionally, an agent can be implemented using a single process, or it can be implemented through multiple processes working together. For example, an agent can correspond to two processes: one responsible for decision-making and another responsible for controlling the hardware. The deployment method of the agent on the physical machine is not unique. Optionally, the server can adopt a single-machine multi-agent mode, a multi-machine multi-agent mode, or a hybrid deployment mode.

[0063] Optionally, a document matching agent can be created by encapsulating the matching logic of skill documents. The server can then assign the skill document matching task to this agent, which will match the query content with candidate documents and filter out the skill documents that match the query content from these candidate documents.

[0064] In an optional embodiment, the computer device can acquire multiple candidate documents, then read the document description information contained in each candidate document, and then adapt the document description information of each candidate document to the query content, so as to filter skill documents that match the document description information with the query content from the candidate documents.

[0065] Optionally, the number of skill documents that match the query can be one or more.

[0066] Optionally, when the query content matches multiple skill documents, the server can determine a collaborative execution plan for each skill document based on the data flow relationship between them, and construct and execute task nodes according to the collaborative execution plan. For example, for the "product recommendation" business, the server can match the skill documents "information collection", "filtering and matching", and "result generation".

[0067] In an optional embodiment, if the query content contains a specified skill identifier, the computer device can determine a target identifier matching the specified skill identifier from among various document identifiers, and identify the candidate document represented by the target identifier as a skill document matching the query content. The document identifier uniquely represents the candidate document. The document identifier may include at least one of the following: text, symbols, etc. Specifically, the user can provide query content containing a specified skill identifier to express their requirements for the skill document used in the query processing. Then, upon obtaining the query content, the computer device can parse the query content to determine whether the query content contains the specified skill identifier.

[0068] Optionally, matching a target identifier with a specified document identifier can mean that the target identifier and the specified document identifier are identical; it can mean that the target identifier and the specified document identifier are semantically similar; or it can mean that the edit distance between the target identifier and the specified document identifier is less than or equal to a set threshold. For example, "elevator selection recommendation" matches "lifting machine selection recommendation"; "product recommendation assistant" matches "mobile phone recommendation assistant".

[0069] Step S304: Based on the protocol specifications followed by the skill document, determine the adapter that matches the skill document.

[0070] In this context, a protocol specification refers to a pre-agreed set of rules, formats, semantics, and timing standards for enabling data exchange and collaborative work between two or more communicating entities. These communicating entities can include at least one of the following: computers, processes, and services. Protocol specifications can be public standards developed by standards organizations or proprietary conventions within a specific system. The specific type of protocol specification is not unique; for example, it can include secure computing protocol specifications (such as the MPC protocol), application layer communication protocol specifications (such as HTTP, HTTPS, etc.), remote procedure call protocol specifications (such as RPC, gRPC, etc.), and custom internal protocols.

[0071] The adapter that matches the skill documentation encapsulates the underlying call logic specific to the protocol specifications followed by the skill documentation. This underlying call logic refers to the specific implementation mechanism of data packet encapsulation, transmission, reception, and parsing during communication under a particular protocol specification. In other words, the underlying call logic specifies how to organize data, how to initiate calls, and how to respond to errors under that protocol specification.

[0072] Specifically, computer devices can establish a mapping relationship between protocol specifications and adapters, and then determine the adapter matching the skill document based on the protocol specifications followed by the mapping relationship. In an optional embodiment, a "protocol-adapter" mapping table can be constructed to record the binding relationship between available candidate adapters and protocol specifications, and based on this binding relationship, determine the adapter matching the current protocol specification from among the candidate adapters. Optionally, the binding relationship between protocol specifications and candidate adapters can be stored in the form of key-value pairs, where the name of the protocol specification can be used as the key and the name of the candidate adapter can be used as the value.

[0073] Step S306: Extract skill metadata from the skill document by parsing the skill document.

[0074] The skill metadata includes the service endpoints used to provide the skills declared in the skill documentation, as well as the call parameters for those service endpoints. A service endpoint is an accessible address or interface exposed within a communication architecture to provide a specific skill. It represents the logical location of the service and can be represented by a network address or interface name.

[0075] Optionally, multiple service endpoints can correspond to the same protocol specification, each used to provide different skill tools. For example, in the HTTP protocol, a service endpoint is usually represented by a URL path, such as " / files / 123" or " / users", which uniquely identifies the location of the resource to be operated on; in the RPC protocol, a service endpoint is usually represented by a combination of service name and method name, such as "FileService.CreateFile" or "UserService.GetUser".

[0076] Invocation parameters refer to the input data or configuration items that need to be passed to the service when invoking a service endpoint. These parameters describe the specific requirements of this request, and the service endpoint can execute corresponding logic and return results based on these parameters. Optionally, invocation parameters may include invocation methods (Method), input parameters (InputSchema), output parameters (OutputSchema), authentication configuration information (AuthConfig), and control rules (ControlRules). Among them, the invocation method is used to identify the type of operation expected to be performed on the resource; input parameters are used to define the name, content, and filtering conditions of business data; output parameters are used to define the data structure and content returned after a successful invocation; and control rules are used to specify non-functional rules such as timeout and retry policies for invocation behavior. By decoupling the service endpoint from invocation parameters, different invocation behaviors under the same endpoint can be flexibly combined, and unified control can be implemented.

[0077] In an alternative embodiment, the computer device can perform semantic parsing of the skill document using a large language model to extract skill metadata from the skill document.

[0078] In an optional embodiment, the extraction of skill metadata can be implemented using an intelligent agent. Optionally, the processing logic for parsing skill documents to obtain skill metadata can be encapsulated to create a metadata extraction agent for extracting skill metadata from skill documents. During application, the server can transmit a skill document that matches the query content to the metadata extraction agent, which can then extract skill metadata from the skill document by executing the pre-encapsulated processing logic.

[0079] In one optional embodiment, the skill document is a structured document. In this embodiment, the computer device can determine the metadata fields contained in the skill document based on its hierarchical structure and extract skill metadata from these fields. For example, in a YAML-formatted skill document, the number of indentation characters varies depending on the level of information. By parsing the indentation hierarchy, the computer device can automatically identify metadata fields such as server endpoints and call parameters, and then extract the corresponding skill metadata.

[0080] In one exemplary embodiment, such as Figure 4 As shown, the core data structure of a skill document may include configuration information 410 and document data 420. Optionally, such as... Figure 4 As shown, the configuration information 410 may include fields such as protocol type 411, server endpoint 412, and call parameters 413.

[0081] Optionally, the configuration information may also include protocol-specific extension fields to store protocol-unique configuration fields, ensuring both the uniformity of configuration formats across different protocols and support for protocol-specific features. These protocol-specific extension fields may include, for example, the certificate path for the RPC (Remote Procedure Calls) protocol or the request header for the HTTP protocol.

[0082] Optionally, document data 420 may include metadata (Summary SkillMeta) 421 and body data (RuleBody string) 422. Metadata 421 may include document identifier (Name string) and document description information (Desc string). Body data 422 is obtained by structurally encapsulating a natural language description of the business logic. Optionally, body data 422 may include sequentially arranged content modules such as role definitions, task flows, available tools, and constraint rules, forming a standardized knowledge organization framework.

[0083] The configuration information is used to declare the protocol specifications followed by the skill document and the skill metadata under the protocol specifications, so as to ensure that the tool call configuration format is consistent across different protocols and lower the threshold for application expansion.

[0084] Optionally, the computer device can extract skill metadata from the skill document by parsing the configuration information of the skill document.

[0085] Optionally, the computer device can also extract skill metadata from the skill document by parsing the document data of the skill document.

[0086] Step S308: Using the adapter, the skill tools provided by the server endpoint are invoked according to the underlying calling logic and calling parameters to obtain the query results corresponding to the query content.

[0087] Specifically, the adapter establishes or reuses a network connection with the server endpoint. Once the connection is established, the adapter can construct a request message conforming to the protocol specification based on the underlying call logic, the query content, and the call parameters. This request message is then sent to the corresponding server endpoint via the network connection to invoke the tools provided by the server endpoint and obtain the query results corresponding to the query content. During the sending process, the adapter adheres to the protocol specification's transmission control logic. This transmission control logic may include at least one of the following: handling request timeouts, automatic retries, and flow control.

[0088] Optionally, if an existing network connection is available, it can be reused to avoid repeated handshake overhead; otherwise, a new connection is established according to the specific requirements of the protocol specification. Available network connections can be, for example, HTTP persistent connections or gRPC channels.

[0089] Optionally, the adapter can serialize the query content and call parameters into the data format specified by the protocol, then fill in the necessary protocol headers, and assemble the request message according to the requirements of the protocol specification.

[0090] Optionally, after receiving a request, the server endpoint can invoke the corresponding skill tool to perform processing based on the message content, and encapsulate the execution result into a response message and return it.

[0091] Optionally, after receiving the response message, the adapter can also parse it according to the underlying call logic to obtain a structured query result, and then return the result to the upper-level caller.

[0092] The above query processing method obtains the query content and the skill documents matching the query content, and determines the adapter that matches the skill document based on the protocol specification followed by the skill document. Since the adapter encapsulates the underlying calling logic specific to the protocol specification, the underlying calling logic of different protocol specifications can be encapsulated into different adapters, so that the tool's declaration is no longer bound to a specific protocol, achieving decoupling between the tool and the protocol, which is beneficial for improving flexibility. Next, by parsing the skill document, skill metadata such as the server endpoint and calling parameters are extracted from the skill document. Then, the adapter calls the skill tool provided by the server endpoint according to the underlying calling logic and calling parameters to obtain the query results corresponding to the query content. Thus, the adapter can dynamically determine and call the corresponding skill tool according to the protocol followed by the skill information, allowing the system to simultaneously support mixed calls of tools under multiple protocol specifications without requiring the user to perceive the underlying differences, further improving the flexibility of query processing.

[0093] In some embodiments, determining an adapter that matches the skill document based on the protocol specification followed by the skill document includes: determining the protocol specification followed by the skill document by identifying the protocol type field in the skill document; and if there is a candidate adapter bound to the protocol specification, determining the candidate adapter as the adapter that matches the skill document.

[0094] The skills document may include a protocol type field. The content of this protocol type field can be used to indicate the protocol specifications followed by the skills document.

[0095] In an optional embodiment, skill documents conforming to different protocol specifications can have configuration information in the same format. In this case, the protocol type field can be included in the configuration information of the skill document. Optionally, the uniformly formatted configuration information can be called a standardized protocol descriptor. This standardized protocol descriptor defines the protocol type, server endpoint, parameter rules, authentication method, and control policy according to a unified specification, ensuring that the tool call configuration format is consistent across different protocols, thus reducing the barrier to use and expansion.

[0096] In one exemplary embodiment, such as Figure 5As shown, the standardized protocol descriptor struct 500 may include general fields 510 and extended fields 520. General fields 510 are configuration fields that must be included across multiple protocol types; extended fields 521 refer to configuration fields specific to the current protocol type. Optionally, general fields 510 may include protocol type 511, endpoint 512, method 513, input parameters 514, output parameters 515, authentication configuration 516, control rules 517, etc.; extended fields 520 may include protocol-specific extended fields 521.

[0097] Optionally, the protocol type can be, for example, HTTP, gRPC, MCP, Shell, etc.; the server endpoint can be, for example, a URL path under the HTTP protocol, a service name under the gRPC protocol, or a script path under the Shell protocol; the calling method is used to identify the type of operation expected to be performed on the resource; input parameters are used to define the name, content, and filtering conditions of the business data; output parameters are used to define the data structure and content returned after a successful call; control rules are used to specify non-functional rules such as timeout and retry policies for the call behavior. Authentication configuration is used to describe authentication type, protocol-specific parameters, etc., and control rules are used to describe the control logic for handling exceptions such as timeouts and retries. Protocol-specific extended fields are used to store protocol-unique configuration fields, such as the certificate path for the RPC protocol and the request header for the HTTP protocol.

[0098] In one exemplary embodiment, such as Figure 6 As shown, the standardized protocol descriptor for skill documents may also include a name field (name) 601, used to represent the name of the skill tool. Optionally, the authentication configuration field 602 may specifically include authentication type, authentication parameters, etc. Optionally, the control rules field may include timeout, maximum number of retries, exponential backoff retries, etc. Optionally, the protocol-specific extension field 604 may include whether encryption is enabled, version number, etc.

[0099] Specifically, a computer device can determine the protocol specification followed by a skill document by identifying the protocol type field. Then, the computer device can determine if there are candidate adapters bound to that protocol specification. If a candidate adapter exists, the computer device can identify that candidate adapter as the one matching the skill document.

[0100] In the above embodiments, the computer device identifies the protocol specification followed by the skill document by recognizing the protocol type field in the skill document, and performs adapter matching based on this. This can unify the recognition process of different protocol specifications through the protocol type field, which is beneficial to improving work efficiency.

[0101] In one embodiment, the query processing method further includes: if there is no candidate adapter bound to the protocol specification, creating an adapter instance that encapsulates the underlying calling logic specific to the protocol specification; and obtaining the candidate adapter corresponding to the protocol specification by calling the registration interface to bind the adapter instance and the protocol specification.

[0102] In this context, an instance typically refers to a concrete object created based on a class, struct, or type. An instance occupies memory, possesses the attributes and methods defined for that type, and can be manipulated during program execution. An adapter instance, on the other hand, refers to a concrete object of an adapter type. An adapter is a role in the Adapter Pattern, whose function is to convert the interface of a class into another interface expected by clients, enabling classes that would otherwise be unable to work together due to interface incompatibility to collaborate. In the various embodiments of this application, the adapter instance is a concrete object created based on an adapter struct.

[0103] A registration interface is a public function or method that receives extensible components such as adapter instances and saves them to the system's internal registry for later use. Optionally, this registry can be, for example, a mapping file, slice, or dictionary. Alternatively, registered adapters can be found and used by name, type, or identifier.

[0104] In an optional embodiment, the query processing method further includes: obtaining a mapping file; and if the mapping file records a protocol specification, determining that there is a candidate adapter bound to the protocol specification.

[0105] The mapping file records the binding relationship between candidate adapters and protocol specifications. When the mapping file contains the protocol specifications followed by the currently matched skill document, the computer device can use the candidate adapter bound to that protocol specification in the mapping file as the adapter to match the skill document. Using a unified mapping file to record the binding relationship between protocol specifications and candidate adapters simplifies the adapter matching process and improves work efficiency.

[0106] In an optional embodiment, such as Figure 7As shown, the computer device can determine whether a candidate adapter bound to a protocol specification exists based on the information recorded in the registry (step S701). If a candidate adapter bound to a protocol specification exists, the computer device can identify the candidate adapter as the adapter matching the skill document (step S702). If no candidate adapter bound to a protocol specification exists, the computer device can create a corresponding adapter instance based on the underlying calling logic specific to that protocol specification (step S703). Then, by calling the registration interface, the adapter instance and its corresponding protocol specification are bound to obtain the candidate adapter corresponding to that protocol specification (step S704).

[0107] Optionally, the computer device can create an adapter instance by passing in protocol-specific underlying call logic and specific configuration information. This specific configuration information may include, for example, a certificate path.

[0108] Optionally, the computer device can bind the developed adapter instance to the protocol specification and register it in the system's registry through the system-provided registration interface. Optionally, this registration interface could be, for example, "RegisterAdapter(protocolType string, adapter ProtocolAdapter)", where the function "RegisterAdapter" (register adapter) includes two parameters: a protocol type field (protocolType string) and a protocol adapter field (adapter ProtocolAdapter). The protocol type field must match the content of this field in the skill documentation. By using the above function, the registration interface can be called, thereby binding the adapter instance of the ProtocolAdapter interface to a specific protocol type and storing it in the registry, so that the corresponding adapter can be dynamically retrieved based on the protocol type later. Optionally, this registry could be, for example, ProtocolRegistry.

[0109] In the above embodiments, an adapter instance encapsulates the underlying calling logic specific to the protocol specification. By calling the registration interface, the adapter instance and the protocol specification are bound together to obtain the candidate adapter corresponding to the protocol specification. This enables hot registration of the adapter, which takes effect immediately after registration without restarting the agent or modifying the core framework code. This can shorten the extension cycle of the protocol type and improve the maintainability of the system while decoupling the tools from the protocol.

[0110] In an optional embodiment, the adapter instance includes verification processing logic and execution logic; the execution logic encapsulates protocol-specific underlying call logic. In this embodiment, creating an adapter instance encapsulated with protocol-specific underlying call logic includes: creating an adapter structure; determining verification processing logic matching the protocol specification based on general verification rules adapting to multiple protocol specifications and protocol-specific verification rules; determining execution logic matching the protocol specification based on the protocol-specific underlying call logic; and encapsulating the verification processing logic and execution logic into the adapter structure to obtain a protocol-specific adapter instance.

[0111] The validation logic, also known as the validate method, refers to the process of checking the validity of input data, request parameters, or the current context. The purpose of validation is to detect and prevent invalid or unqualified calls before formal execution, avoiding errors or side effects in subsequent execution. Optionally, the validation content includes, but is not limited to, data format, business rules, or dependency conditions. Optionally, the validation content may involve at least one of the following: required fields, type, length, regular expressions, etc. Business rules may include at least one of the following: scope, status, or permissions, etc. Dependency conditions may include whether prior resources are ready, etc.

[0112] The execution logic, also known as the `execute` method, refers to the process of executing the adapter's core functions after successful validation. The execution logic is responsible for fulfilling the adapter's main duties, such as converting input from one protocol format to another, or data processing such as parsing, mapping, computation, or storage. The execution logic may also include operations such as calling external services or low-level interfaces.

[0113] An adapter struct is a data structure defined using a struct type to implement specific adapter logic. In programming, it serves as a template for adapters, and concrete adapter instances can be created through instantiation. An adapter struct can be understood as a custom composite data type that encapsulates the data fields required for the adapter to run, typically providing complete adapter functionality by implementing one or more interface methods. The required data fields may include, for example, the adapted object, configuration parameters, and connection information. The interface methods may include, for example, the validate method and the execute method.

[0114] Specifically, a computer device can create an adapter structure. Then, based on general verification rules adapting to multiple protocol specifications, as well as protocol-specific verification rules, it determines the verification processing logic that matches the protocol specification. Furthermore, based on the protocol-specific underlying calling logic, it determines the execution logic that matches the protocol specification. Finally, the computer device can encapsulate the verification processing logic and execution logic into the adapter structure, obtaining a protocol-specific adapter instance.

[0115] In one exemplary embodiment, such as Figure 8 As shown, the adapter structure 800 may include modules such as protocol-specific attributes 801, initialization information 802, verification processing logic 803, and execution logic 804. Protocol-specific attributes 801 may include, for example, a protocol-specific connection pool and a protocol-specific certificate path. Initialization information 802 may include initializing a protocol-specific connection pool and passing in protocol-specific configurations. Verification processing logic 803 may include, for example, general verification rules adapting to multiple protocol specifications and specific verification rules. Execution logic 804 may include call time recording, parameter processing logic, call execution logic, result processing logic, and result return logic.

[0116] Optionally, general validation rules that adapt to multiple protocol specifications may include, for example, whether required fields are missing, and whether the configuration information matches the protocol specification. Required fields may include, for example, the protocol type, server endpoint, and invocation method.

[0117] Optionally, the specific verification rules can refer to whether the endpoint format conforms to the corresponding protocol specification, whether the authentication type conforms to the requirements of the protocol specification, and whether the configuration content of the protocol-specific fields is valid.

[0118] Optionally, both the parameter processing logic and the result processing logic can include protocol-specific utility methods. For example, the parameter processing logic can be used to convert input parameters into a protocol-specific format; the result processing logic can be used to convert the protocol's returned results into a unified format.

[0119] Optionally, the result return logic can be used to supplement the call metadata for easier monitoring and troubleshooting. This supplementary call metadata may include protocol type, call endpoint, call duration, and protocol-specific metadata.

[0120] Using the above method, when adding any new protocol (such as a custom internal protocol or a third-party protocol), only a protocol-specific adapter needs to be developed and registered with the framework. There is no need to modify the core of the Skill protocol or refactor the framework logic, which enables low-cost and rapid expansion of the protocol.

[0121] In an optional embodiment, such as Figure 9As shown, the process of extending the new protocol includes the following steps:

[0122] Step S901: Determine the technical specifications of the new protocol.

[0123] Specifically, computer equipment can clearly define the core technical details of the protocol, including server endpoint format, calling method definition, parameter serialization method, authentication method, transmission method, exception error code specification, etc., to ensure that adapter development has a clear basis.

[0124] Step S902: Define the protocol descriptor configuration rules.

[0125] Specifically, computer devices can determine the general field assignment rules and exclusive extension fields for new protocols according to the structural specifications of standardized protocol descriptors. For example, what special provisions are there for the configuration content of general fields such as Endpoint (service endpoint) and Method (call method) under the new protocol? Or, does the new protocol have any unique configuration content? If so, this content is stored in the Extension field to ensure that the configuration format is consistent with the existing protocols.

[0126] Step S903: Develop an adapter specific to the new protocol.

[0127] Specifically, computer devices can strictly implement the framework's ProtocolAdapter standardized interface, requiring only two core methods to be written, with no additional development cost.

[0128] The `Validate` method is used to verify the validity of the newly added protocol configuration. This can include general validation (whether required fields are missing) and protocol-specific validation (such as whether the server endpoint format is correct and whether authentication parameters are valid). The `Execute` method implements the underlying call logic for the new protocol. This can include parameter processing logic, as well as protocol-specific processing logic such as serialization, transmission, authentication, call execution, and result deserialization. In other words, all the underlying call logic for the new protocol is encapsulated within this method, decoupled from the framework.

[0129] Step S904, adapter registration.

[0130] Specifically, computer devices can use the registration interface provided by the framework to bind the developed adapter to the protocol type of the newly added protocol and register it in the framework's ProtocolRegistry. Hot registration is achieved through the registration interface, requiring no Agent restart or modification of the framework's core code, and takes effect immediately after registration.

[0131] Step S905, protocol usage.

[0132] Specifically, business users can declare the standardized protocol descriptor for the protocol in the `protocols` field of the Skill document using a unified format. The framework can then automatically match the adapter and execute a unified call process, completely consistent with the usage of existing protocols. In other words, through the standardization of adapter interfaces and the plug-in registration mechanism, "plug-and-play" extensions of new protocols can be achieved. The framework is completely unaware of the new protocols, truly achieving openness to extensions and closedness to modifications, thus solving the core problem of high protocol extension costs in traditional technologies.

[0133] In the above embodiments, by separating the verification processing logic and the execution logic, the calling flow of the adapter is clear and easy to test. Furthermore, the verification rules can be extended without modifying the execution logic, which helps to further improve the flexibility of the system.

[0134] In some embodiments, the query processing method further includes: if the skill document does not contain a protocol type field, obtaining the correspondence between the protocol specification and the dedicated field; and determining the protocol specification followed by the skill document based on the dedicated field contained in the skill document and in accordance with the correspondence.

[0135] In this context, "specific fields" refer to unique data fields defined by a specific protocol specification and possessing clear semantics only within that protocol specification's context. Specific fields are typically used to carry control information, status information, or metadata unique to that protocol specification. They generally do not have direct counterparts in other protocols, or even if fields share the same name, their meanings may differ. In contrast to general fields common across protocols, specific fields highlight the specificity of the protocol specification. For example, fields such as length and version number are general fields; the `requires_mcp` field in the MCP protocol and the `shell_patch` field in the Shell protocol are specific fields. The `requires_mcp` field indicates which native MCP capability a given operation or resource requires for processing; the `shell_patch` field identifies the path of the script that the current shell session needs to load or execute.

[0136] During application, the matched skill document may be an older document that does not contain a protocol type field. These older documents do not contain standardized configuration information, so it is impossible to determine the protocol specification followed by the skill document by reading the content of the protocol type field. In this case, the computer device can obtain the correspondence between the protocol specification and the dedicated field, and determine the protocol specification followed by the skill document based on the dedicated field contained in the skill document and according to the correspondence.

[0137] For example, if a skill document does not contain a protocol type field (protocols) but does contain a requires_mcp field, since the requires_mcp field is a field specific to the MCP protocol, the skill document can be identified as an MCP historical document.

[0138] For example, if a skill document does not contain a protocol type field (protocols) but does contain a shell_path field, since the shell_path field is a field specific to the Shell protocol, the skill document can be identified as a Shell history document.

[0139] In the above embodiments, when the skill document does not contain a protocol type field, the accuracy of the judgment result can be improved by identifying the protocol specification followed by the skill document based on the correspondence between the protocol specification and the dedicated field.

[0140] In some embodiments, for old documents that do not contain standardized configuration information, the computer device can read the original records of the old document by performing semantic parsing based on the structural specifications of the configuration information. Then, the corresponding configuration information can be obtained from the original records, and the skill metadata of the skill document can be extracted from the configuration information for subsequent processing.

[0141] In some embodiments, for old documents that do not contain configuration information in a uniform format, a computer device can construct the configuration information of the skill document based on the original records of the old document to obtain an updated document that conforms to the new document specification, thereby realizing the conversion from old document to new document.

[0142] In an optional embodiment, the query processing method further includes: adding a protocol type field, a server endpoint field, and a call parameter field to the skill document; using the protocol specification as the field content of the protocol type field; completing the field content of the server endpoint field and the call parameter field based on the original record of the skill document and the protocol specification; and obtaining the updated skill document if the completed field content passes the validation.

[0143] Specifically, for skill documents that do not include a protocol type field, the computer device can add fields such as protocol type, server endpoint, and call parameters to the skill document, unifying the configuration format between the old and new documents. Then, the protocol specification determined based on matching specific fields is used as the content of the protocol type field. Based on the original record in the skill document and the aforementioned protocol specification, the content of the server endpoint and call parameter fields is completed. Finally, the computer device can validate the completed field content, and if the completed field content passes validation, an updated skill document is obtained to support subsequent standardized applications.

[0144] Optionally, computer devices can unify the configuration format of old and new documents by adding fields such as protocol type, server endpoint, and call parameters to corresponding locations in the skill document. These fields can be added at, for example, the beginning or end of the skill document.

[0145] Optionally, the computer device can generate configuration information for the skill document, including fields such as protocol type, server endpoint, and call parameters, to unify the configuration format of the old and new documents. That is, the updated skill document contains configuration information in a unified format, enabling unified declaration and invocation of various heterogeneous protocols.

[0146] Optionally, the computer device can validate the completed field content by calling an adapter that matches the protocol specification. Optionally, the adapter can validate the completed field content according to encapsulated validation processing logic. Optionally, if no adapter matches the protocol specification, the computer device can create a corresponding adapter instance and register it.

[0147] Optionally, if the completed field content passes validation, the computer device can invoke an adapter that matches the protocol specification. This adapter executes the underlying call logic specific to that protocol specification to retrieve the completed skill document. If the returned call result meets the requirements, the updated skill document is obtained. If the returned call result does not meet the requirements, the error reason can be reported to guide business personnel in making corrections. This process is equivalent to validating and testing the completed skill document, ensuring its usability.

[0148] In the above embodiments, for skill documents that do not contain a protocol type field, adding fields such as protocol type, server endpoint, and call parameters, along with their corresponding content, can unify the configuration format of the old and new documents, providing a data foundation for subsequent standardized skill calls.

[0149] In an optional embodiment, based on the original record in the skill document and the protocol specification, the field content of the server endpoint field and the call parameter field are completed, including: obtaining the exclusive field content of the exclusive field in the skill document and the original call parameters in the skill document; completing the field content of the server endpoint field according to the relationship between the exclusive field content and the server endpoint under the protocol specification; and converting the original call parameters into the field content of the call parameter field.

[0150] Specifically, "exclusive field content" refers to the content of exclusive fields within the skill document. "Original call parameters" refers to the call parameters recorded in the original skill document. In essence, the computer device can parse the skill document to read the exclusive field content and the original call parameters. Then, based on the relationship between the exclusive field content and the server endpoint under the protocol specification, it completes the content of the server endpoint fields and converts the original call parameters into the content of the call parameter fields, thus completing the content of the newly added fields.

[0151] For example, for MCP history documents, the service address of the MCP service can be determined based on the MCP service recorded in "requires_mcp", and this service address can be used as the field content of the service endpoint field. For Shell history documents, the script path recorded in "shell_path" can be completed to include the service endpoint.

[0152] In an optional embodiment, the framework-defined history protocol compatibility mapping structure (HistoryDocRule struct) supports the automatic identification and adaptation of existing historical documents. This structure can include a MatchField for recording specific fields and a MatchValue for recording the content of those specific fields. Optionally, the structure can also include the protocol mapped to the historical document and an automatically completed standardized protocol descriptor. For example, if the matching value for the specific field "requires_mcp" is "true", the mapped protocol is "MCP protocol"; if the matching value for the specific field "shell_path" is any path, the mapped protocol is "Shell protocol". By achieving automatic identification of historical documents through field matching, the framework can automatically generate standardized protocol descriptors based on the matching results, allowing historical documents to follow a unified calling process and achieving seamless compatibility.

[0153] In one exemplary embodiment, such as Figure 10 As shown, the compatibility process for older documents includes the following steps:

[0154] Step S1001: Upload existing skill documents.

[0155] Step S1002: If the existing skill document is determined to be an old document by parsing it, perform exclusive field rule matching.

[0156] Among them, old documents refer to those that do not contain a protocol type field and are not configured with a unified format.

[0157] Step S1003: Determine the protocol specifications followed by the old document based on the matched exclusive fields.

[0158] Optionally, if a document contains the "requires_mcp" field but not the protocols field, it is determined to be an MCP history document; if a document contains the shell_path field but not the protocols field, it is determined to be a Shell history document.

[0159] Step S1004: Automatically generate configuration information corresponding to the protocol specification.

[0160] Optionally, for historical MCP documents, the computer device can automatically generate a standardized protocol descriptor (configuration information) for the MCP protocol. Here, Endpoint is completed to specify the MCP service address of the configuration center, AuthConfig is completed to specify the system's default MCP authentication parameters, and ControlRules is completed to specify the historical default timeout or retry rules.

[0161] Optionally, for Shell history documents, the computer device can automatically generate standardized protocol descriptors for the Shell protocol, mapping Endpoint to shell_path values, Method to script execution commands, and ControlRules to historical default timeout rules.

[0162] Step S1005: Match the corresponding adapter by querying the mapping file.

[0163] Specifically, computer devices can query the adapter's registry to match the corresponding adapter for the currently identified protocol specification.

[0164] Step S1006: The adapter application uses its own encapsulated verification processing logic to verify the generated configuration information.

[0165] For example, the MCP adapter can verify whether the MCP service address is valid, and the Shell adapter can verify whether the script path exists.

[0166] Step S1007: The adapter application calls the corresponding skill tool using its own encapsulated execution logic.

[0167] Specifically, the adapter can fully reuse the calling logic of the protocol specification to complete the invocation of skill tools.

[0168] Step S1008: Standardize the call result into a unified format.

[0169] Optionally, the MCP adapter can fully reuse the calling logic of the traditional MCP protocol, ensuring that the calling results are consistent with the original framework. This calling logic may include, for example, the communication format and data transmission method of the MCP protocol.

[0170] Optionally, the Shell adapter executes the script in the original way, only converting stdout / stderr to a unified standardized result format during the result phase to ensure consistent parsing later.

[0171] Step S1009: Return the result.

[0172] Optionally, the result of the call can be returned to the large language model or the user terminal.

[0173] Optionally, the validity of the above compatibility conversion can be determined based on the returned results, so that existing skill documents without protocol type fields can be called under the framework of this application without manual modification, achieving zero-modification compatibility.

[0174] In the above embodiments, by matching exclusive fields and automatically completing configuration information, historical documents can be integrated into configuration information with a unified structure. This not only preserves the original calling logic but also unifies the results, achieving zero modification, seamless integration, and full compatibility, thereby improving the consistency and ease of use of system calls.

[0175] In some embodiments, the adapter further encapsulates verification processing logic for skill documents conforming to protocol specifications; the verification processing logic is used to verify the field content in the skill document. In this embodiment, extracting skill metadata from the skill document by parsing it includes: determining the metadata fields contained in the skill document based on the verification processing logic using the adapter; and extracting skill metadata from the field content of the metadata fields.

[0176] The validation logic encapsulated in the adapter is used to verify the validity of field content. Based on this, the adapter can determine which metadata fields are included in the skill document, and then extract the corresponding skill metadata from the content of these metadata fields. For example, if the adapter's validation logic includes validity rules for server ports and format validation rules for input parameters, it can determine that the skill document should contain "server port" and "input parameter" fields, and then extract the corresponding skill metadata from these fields.

[0177] In an optional embodiment, the verification processing logic includes general verification rules adaptable to multiple protocol specifications, as well as protocol-specific verification rules. In this embodiment, the adapter determines the metadata fields contained in the skill document based on the verification rules, including: determining general metadata fields contained in the skill document based on the general verification rules; determining extended metadata fields contained in the skill document based on the verification rules; and determining metadata fields that include both the general metadata fields and the extended metadata fields.

[0178] Specifically, the verification processing logic can include general verification rules adapting to multiple protocol specifications, as well as specific verification rules for a particular protocol specification. The adapter can then, on the one hand, determine the common metadata fields contained in the skill document based on the general verification rules, and extract general skill metadata from these common metadata fields. On the other hand, the adapter can determine the extended metadata fields contained in the skill document based on the specific metadata rules, and extract skill metadata specific to the particular protocol specification from these extended metadata fields. Verifying metadata fields according to both general and specific verification rules ensures that complete metadata fields can be extracted, providing a data foundation for subsequent processing.

[0179] In the above embodiments, using an adapter to parse skill metadata can further unify the invocation process of skills with different protocols, shield the underlying differences of protocols, and help to further improve the consistency and ease of use of system calls.

[0180] In some embodiments, the underlying invocation logic includes parameter processing logic, invocation execution logic, and result processing logic. In this embodiment, the adapter invokes the skills provided by the server endpoint according to the underlying invocation logic and invocation parameters to obtain the query results corresponding to the query content. This includes: converting the invocation parameters into request parameters adapted to the protocol specification according to the parameter processing logic; invoking the skills provided by the server endpoint according to the invocation execution logic and request parameters to obtain the invocation results corresponding to the query content; and performing structured adjustments on the invocation results according to the result processing logic to obtain the query results corresponding to the query content.

[0181] The parameter processing logic describes the preprocessing, transformation, formatting, or validation of input parameters. Its purpose is to convert the raw input into the standard parameter form required by the adapter's internal execution, or to prepare necessary context information for subsequent execution. Optionally, the parameter processing logic may include operations such as parameter extraction, type conversion, default value filling, and parameter mapping.

[0182] The execution logic describes the process of actually executing the adapter's core functions after parameter processing is complete. This logic is responsible for completing the adapter's main tasks, such as calling downstream services, performing protocol conversions, operating external systems, executing calculation methods, or triggering business processes. The execution logic typically depends on the output of the parameter processing logic and produces the raw execution result.

[0183] Result processing logic describes the process of post-processing, encapsulating, standardizing, or transforming the raw results generated by the invoked execution logic. Its purpose is to convert the internal execution results into the format, data structure, or response protocol expected by the caller. Result processing logic may include operations such as result mapping, error code transformation, exception encapsulation, logging, result caching, or performance metric collection.

[0184] Specifically, computer devices can use adapters to convert call parameters into request parameters that are compatible with the protocol specification, according to the parameter processing logic. For example, generic JSON parameters can be converted into the structure format required by the new protocol (e.g., serialized to Protobuf format); or, according to the HTTP protocol specification, InputSchema parameters can be automatically converted into URL parameters (GET) or request bodies (POST / PUT).

[0185] Then, the computer device can use the adapter to invoke the skills provided by the server endpoint according to the call execution logic and request parameters, and obtain the call results corresponding to the query content.

[0186] For example, for HTTP or HTTPS protocols, the computer device can automatically inject authentication parameters into the request header (e.g., Authorization: Bearer {token}, Ticket: {ticket}) based on the AuthConfig type (token / ticket / basic), automatically load the system root certificate, and start TLS (Transport Layer Security) encrypted transmission. Then, it initiates a request according to the HTTP or HTTPS protocol specification, receives the response, extracts the response body, filters redundant response headers and status codes, and retains only the business data. Optionally, for network timeouts and 5xx server errors, the adapter can implement exponential backoff retries according to the retry policy of ControlRules to avoid service overload caused by frequent requests.

[0187] For example, for custom internal protocols used in enterprise applications, computer devices can resolve service names to specific "service node IP:port," supporting round-robin load balancing without requiring users to configure specific service addresses. Based on the `internal_caller` type of `AuthConfig`, it automatically injects internal Caller identifiers (such as business line IDs and application IDs) to meet the permission verification requirements of the RPC protocol. Next, an RPC call is initiated through the native API, and after receiving the Protobuf-formatted return result, it is deserialized into JSON format for easy standardization processing. Optionally, for RPC protocol-specific error codes, the adapter can automatically map them to the framework's unified error codes, ensuring that the LLM can recognize and handle them.

[0188] For example, for the gRPC protocol, computer devices can enable gRPC persistent connections and implement connection pooling for reuse, avoiding frequent connection establishment or termination and improving call efficiency. If the third-party gRPC service enables TLS encryption, the user can configure the certificate path in the Extension field, and the adapter will automatically load the certificate and enable TLS encrypted transmission. Then, the adapter can initiate remote calls according to the gRPC standard specification, supporting unary calls and streaming calls (the call type is configured through the Extension field), and deserialize the received results into JSON format.

[0189] Finally, the computer device can use the adapter to structurally adjust the call results according to the result processing logic to obtain the query results corresponding to the query content. Optionally, the call results of skill tools under various protocol specifications are ultimately converted into the unified StandardResult format defined by the framework, which includes Success (whether the call was successful), Data (business data, JSON format), Metadata (call metadata, such as time consumption, service nodes), Error (error information, unified format), etc., to ensure that LLM and users can parse the results in a unified way without distinguishing between protocol types.

[0190] In the above embodiments, by sequentially executing parameter processing logic, call execution logic, and result processing logic through the adapter, a unified execution and call process for all protocols can be achieved. This can shield the differences in underlying protocols, while implementing protocol-specific underlying call logic within the adapter to ensure the accuracy of the call.

[0191] In one embodiment, such as Figure 11 As shown, a query processing method is provided, which can be executed by a computer device. In this embodiment, the method may include the following steps:

[0192] Step S1101: Obtain the query content and the skill documents that match the query content.

[0193] Step S1102: If the skill document contains a protocol type field, determine the protocol specification followed by the skill document by identifying the content of the protocol type field.

[0194] Step S1103: If the skill document does not contain a protocol type field, obtain the correspondence between the protocol specification and the dedicated field.

[0195] If a skill document does not contain a protocol type field, it indicates that the skill document is an existing historical document. This existing historical document does not have a unified declaration based on the extended skill protocol. The extended skill protocol is a semi-structured Markdown protocol upgraded based on the Anthropic agent capability specification. The core feature of the extended skill protocol is its extensible multi-protocol support capability, specifically achieved through the addition of protocol configuration fields and standardized protocol description specifications, enabling unified declaration and invocation of heterogeneous protocols such as HTTP, RPC, and gRPC.

[0196] Optionally, the newly added fields can be uniformly placed in the configuration information as standardized protocol descriptors. This configuration information, which defines protocol types, service endpoints, parameter rules, authentication methods, and control policies according to a unified standard, ensures consistent configuration formats for tool calls across different protocols, lowering the barrier to entry for use and expansion.

[0197] Step S1104: Based on the exclusive fields contained in the skill document, determine the protocol specifications followed by the skill document according to the corresponding relationship.

[0198] Step S1105: For the skill document, add the protocol type field, server endpoint field, and call parameter field.

[0199] Step S1106: Use the protocol specification as the field content of the protocol type field.

[0200] Step S1107: Obtain the content of the exclusive field in the skill document and the original calling parameters in the skill document.

[0201] Step S1108: Based on the relationship between the exclusive field content and the service endpoint under the protocol specification, complete the field content of the service endpoint field.

[0202] Step S1109: Convert the original call parameters into the field content of the call parameter fields.

[0203] Step S1110: If the completed field content passes the validation, the updated skill document is obtained.

[0204] Step S1111: Obtain the mapping file.

[0205] The mapping file is used to record the binding relationship between candidate adapters and protocol specifications.

[0206] Step S1112: If the mapping file contains a protocol specification, the candidate adapter bound to the protocol specification is determined as the adapter that matches the skill document.

[0207] Among them, the adapter that matches the skill document encapsulates the underlying calling logic specific to the protocol specification.

[0208] Step S1113: If the protocol specification is not recorded in the mapping file, create the adapter structure.

[0209] Step S1114: Based on the general verification rules that adapt to multiple protocol specifications and the specific verification rules of the protocol specifications, determine the verification processing logic that matches the protocol specifications.

[0210] Step S1115: Based on the underlying calling logic specific to the protocol specification, determine the execution logic that matches the protocol specification.

[0211] The underlying calling logic includes parameter processing logic, call execution logic, and result processing logic.

[0212] Step S1116: Encapsulate the verification processing logic and execution logic into the adapter structure to obtain an adapter instance specific to the protocol specification.

[0213] Step S1117: By calling the registration interface, bind the adapter instance and protocol specification, obtain the candidate adapter corresponding to the protocol specification, and update the mapping file.

[0214] Optionally, the mapping file can be updated by recording the binding relationship between newly registered candidate adapters and protocol specifications in the mapping file.

[0215] Step S1118: Extract skill metadata from the skill document by parsing the skill document.

[0216] The skill metadata includes the service endpoints used to provide the skills declared in the skill documents, as well as the call parameters for the service endpoints.

[0217] Optionally, the skill documents can be semantically parsed using a large language model to extract skill metadata; alternatively, an adapter can be used to determine the metadata fields contained in the skill documents based on the validation processing logic, and skill metadata can be extracted from the content of the metadata fields.

[0218] Optionally, metadata fields may include general metadata fields and extended metadata fields. General metadata fields can be determined based on general validation rules; extended metadata fields can be determined based on specific validation rules.

[0219] Step S1119: The call parameters are converted into request parameters that are compatible with the protocol specification by the adapter according to the parameter processing logic.

[0220] Step S1120: The adapter invokes the skills provided by the server endpoint according to the call execution logic and request parameters to obtain the call result corresponding to the query content.

[0221] Step S1121: The adapter performs a structured adjustment of the call result according to the result processing logic to obtain the query result corresponding to the query content.

[0222] In traditional technologies, mainstream skill tool invocation solutions mainly include the Anthropic MCP solution, LangChainTools (a chain-like toolset), traditional Skill protocols supporting MCP and Shell, and third-party tool integration solutions. Among these, the Anthropic MCP solution uses a fixed MCP protocol type with no extension framework; adding a new protocol requires modifying the protocol specification and Agent code, resulting in poor scalability. LangChain Tools supports multiple protocols but lacks a unified protocol configuration standard; tools and protocols are tightly coupled, requiring the development of dedicated tool classes for new protocols, leading to poor compatibility. Traditional Skill protocols only support MCP and Shell, have a closed protocol structure, lack extension mechanisms, and require refactoring the protocol itself for new protocols, resulting in extremely high extension costs. Third-party tool integration solutions require encapsulation into the MCP protocol through an intermediate layer to access the Skill ecosystem, cannot natively support new protocols, and suffer from low integration efficiency and a lengthy process.

[0223] Based on this, this application proposes a query processing method that supports multi-protocol expansion and unified invocation through a unified declaration of protocol configuration information for skill documents.

[0224] Specifically, in response to the deficiency of "fixed protocol support and inflexible expansion", this application realizes declarative expansion and plug-in integration of protocols through extended skill protocols and protocol expansion framework. Adding new protocols does not require modification of the protocol core or Agent code, and the expansion cycle is reduced from several weeks to one to two days.

[0225] To address the drawback of "severe coupling in protocol adaptation", this application uses an adapter decoupling tool to call the underlying protocol. The tool is only bound to a standardized protocol descriptor, and no modification to the tool configuration is required when replacing or adding a protocol, thus significantly improving compatibility.

[0226] To address the shortcomings of "heterogeneous configuration formats for multiple protocols", this application establishes a unified protocol descriptor specification, ensuring consistent configuration formats for tools across different protocols. This eliminates the need for users to learn multiple configuration logics, reducing the barrier to entry by 80%.

[0227] To address the drawback of "difficulty in integrating internal or third-party protocols," this application proposes a protocol plug-in integration and native adaptation solution, which allows internal services and third-party protocols to be directly integrated without the need for intermediate layer encapsulation, thereby improving integration efficiency.

[0228] To address the deficiency of "unreliable compatibility with historical protocols", this application designs automatic protocol identification and downgrade calling logic. Skill documents for existing historical protocols can be used normally without modification, with zero migration cost.

[0229] Among them, the extended skill protocol is a semi-structured Markdown protocol upgraded based on the Anthropic agent capability specification. The core feature of the extended skill protocol is its extensible multi-protocol support capability, specifically achieved through the addition of protocol configuration fields and standardized protocol description specifications, enabling unified declaration and invocation of heterogeneous protocols such as HTTP, RPC, and gRPC.

[0230] Optional, such as Figure 5 As shown, the newly added fields can be uniformly placed in the configuration information as standardized protocol descriptors. This configuration information, which defines protocol types, service endpoints, parameter rules, authentication methods, and control policies according to a unified standard, ensures consistent configuration formats for tool calls across different protocols, lowering the barrier to entry for use and expansion.

[0231] The Protocol Extension Framework includes protocol description specifications, pluggable adapter interfaces, and protocol registration mechanisms. It supports the rapid integration of new protocols by implementing standardized interfaces, without requiring modification to the core structure of the Skill protocol or the Agent execution logic. For example, a Protocol Registry map records the binding relationships between registered candidate adapters and protocol specifications; a History Doc Rule map records the specific fields corresponding to historical protocols—for example, the `requires_mcp` field is specific to the MCP protocol, and the `hell_path` field is specific to the Shell protocol; and a standardized Protocol Adapter interface unifies the entry point for calls without relying on protocol documents, shielding the underlying call differences between different protocols. This allows the large language model and user terminals to declare or initiate calls in a unified format without needing to be aware of the specific implementation details of the protocols, while also supporting pluggable extensions. The user terminal can include both business and application ends.

[0232] By using a protocol extension framework, the calling logic (serialization, authentication, and transmission) of different protocols is encapsulated into dedicated adapters. This decouples the tools declared in the Skill documentation from the underlying protocols, supporting flexible replacement and addition of protocols. Furthermore, when adding a new protocol, only the corresponding adapter needs to be developed and connected to the protocol extension framework through a registration mechanism. There is no need to modify the Skill protocol itself or the Agent core code, achieving "plug-and-play" protocol extension capabilities.

[0233] For custom internal protocols, a dedicated adaptation solution can be implemented based on the protocol extension framework. It has built-in features such as service discovery, parameter serialization, and internal authentication, and supports direct declaration of custom service calls in the Skill documentation without additional encapsulation.

[0234] In one exemplary embodiment, the query processing system adopts a four-layer decoupled architecture, with all modules designed around the core objectives of "multi-protocol expansion, unified invocation, and historical compatibility." For example... Figure 12 As shown, the system architecture includes a skill documentation layer 1201, a protocol management layer 1202, a core engine layer 1203, and a protocol implementation layer 1204.

[0235] The Skill Document Layer 1201 includes existing historical documents and extended new documents, serving as the declaration entry point for protocol calls and supporting the mixed use of old and new documents. Extended new documents refer to skill documents that conform to the extended skill protocol specification and declare standardized protocol descriptors; existing historical documents refer to skill documents that do not declare standardized protocol descriptors according to the extended skill protocol specification.

[0236] The protocol management layer 1202 includes a protocol descriptor parsing module, a protocol auto-identification module, and a compatibility handling module. Its core responsibility is the unified parsing and compatibility handling of protocol configurations, shielding the differences in document formats between new and old versions. Specifically, the protocol descriptor parsing module is used to uniformly parse configurations from both new and old documents; the protocol auto-identification module distinguishes between new and historical protocols; and the compatibility handling module adapts configurations for many historical protocols.

[0237] The core engine layer 1203 includes a protocol extension framework, a multi-protocol adapter cluster, and a unified call router, which is responsible for protocol adapter matching, unified multi-protocol call distribution, and plug-in protocol extension.

[0238] The protocol implementation layer 1204 encapsulates the underlying calling logic of each protocol. All logic is encapsulated in the corresponding adapter, decoupled from the core engine, to ensure that adding or modifying protocols does not affect the overall architecture.

[0239] The above architecture completely decouples the tool declaration, protocol adaptation, and underlying calls, ensuring system decoupling by allowing modifications to any layer without affecting others. Adding a new protocol only requires developing an adapter at the protocol implementation layer and registering it at the core engine layer, without modifying other layers, thus ensuring good system scalability. Automatic identification and adaptation by the protocol management layer achieves seamless compatibility between new and old documents and protocols, ensuring system compatibility.

[0240] In one exemplary embodiment, such as Figure 13 As shown, the unified multi-protocol invocation includes the following steps:

[0241] Step S1301: Write an extended skills document and declare a standardized protocol descriptor;

[0242] Step S1302: The protocol descriptor parsing module verifies the legality of the declaration content;

[0243] Step S1303: The protocol automatic identification module extracts the protocol type field and determines it to be an extended new document;

[0244] Step S1304: The protocol extension framework queries the protocol adapter mapping table and matches the corresponding adapter;

[0245] Step S1305: Execute the dedicated processing logic through the matched adapter and call the corresponding skill tool;

[0246] Step S1306: Standardize the tool call results;

[0247] Step S1307: Return the call result in a uniform format.

[0248] For example, for HTTP or HTTPS protocols, the adapter can parse skill metadata such as service port (URL), calling method (GET / POST / PUT, etc.), request parameters, and timeout retry rules (ControlRules) from the standardized protocol descriptor in the skill document. The adapter can then execute protocol-specific processing flows, which may include authentication adaptation, request parameter adaptation, and other operations. Finally, the adapter can initiate requests according to the HTTP or HTTPS protocol specifications, receive responses, extract the response body, filter redundant response headers and status codes, and retain only the business data.

[0249] Optionally, the adapter can automatically inject authentication parameters into the request header (e.g., Authorization:Bearer {token}, Ticket:{ticket}) based on the authentication configuration (AuthConfig) type (token / ticket / basic), automatically load the system root certificate, and enable TLS (Transport Layer Security) encrypted transmission. Optionally, for network timeouts and 5xx server errors, the adapter can perform exponential backoff retries according to the retry policy of ControlRules to avoid service overload caused by frequent requests.

[0250] For example, for custom internal protocols used in enterprise applications, the adapter can parse skill metadata such as service port (service name, e.g., trpc.user.UserService), calling method (interface name), request parameters, and authentication configuration from the standardized protocol descriptor in the skill documentation. Then, the adapter executes protocol-specific processing flows, which may include service discovery, serialization, and internal authentication. Next, the adapter can initiate RPC calls via native API calls, receive Protobuf-formatted return results, and deserialize them into JSON format for subsequent standardized processing.

[0251] Optionally, the adapter can resolve service names to specific "service node IP:port" values, supporting round-robin load balancing without requiring users to configure specific service addresses. It also automatically injects internal Caller identifiers (such as business line IDs and application IDs) based on the `internal_caller` type of `AuthConfig`, satisfying the permission verification requirements of the RPC protocol. Optionally, for RPC protocol-specific error codes, the adapter can automatically map them to the framework's unified error codes, ensuring that the LLM can recognize and handle them.

[0252] For example, for the gRPC protocol, the adapter can parse skill metadata such as the service port (gRPC service address: port), the calling method (gRPC service / method, such as DataService / Query), and request parameters from the standardized protocol descriptor in the skill document. The adapter then executes the protocol-specific processing flow, which may include establishing a connection, serialization, certificate adaptation, and other operations. The adapter can then initiate remote calls according to the gRPC standard specification, supporting unary calls and streaming calls (the call type is configured via the Extension field), and deserializes the received results into JSON format.

[0253] Optionally, the adapter can enable gRPC persistent connections and implement connection pooling to avoid frequent connection establishment or termination, thus improving call efficiency. If the third-party gRPC service enables TLS encryption, the user can configure the certificate path in the Extension field, and the adapter will automatically load the certificate and enable TLS encrypted transmission.

[0254] The query processing method provided in this application enables rapid extension of protocols through plug-in architecture, breaking the closed limitations of traditional protocols. Specifically, through standardized adapter interfaces and a plug-in registration mechanism, adding any new protocol only requires developing and registering a dedicated adapter, without modifying the protocol core or Agent logic. This shortens the extension cycle from several weeks to one to two days, while simultaneously decoupling the "tool-protocol-framework" relationship and improving system maintainability. Furthermore, it unifies the configuration and invocation standards for multiple protocols, lowering the barrier to entry. Specifically, through standardized protocol descriptors, it unifies the configuration format, invocation entry point, and result format of various protocols, shielding underlying protocol differences, significantly reducing user learning costs, and improving system call consistency and ease of use.

[0255] Building upon this foundation, through automatic protocol identification, rule matching, and descriptor auto-completion mechanisms, existing historical documents can be directly reused without manual modification, completely resolving the challenges of migrating existing documents, reducing enterprise upgrade costs, and achieving zero-modification compatibility with historical protocols, thus reusing existing assets. Furthermore, it supports native access to internally customized protocols and third-party protocols without the need for intermediate layer encapsulation, significantly improving access efficiency. Simultaneously, through adapter verification and unified management rules, it reduces system maintenance costs, decreases enterprise technical and human resource investment, and significantly improves access efficiency while lowering overall costs.

[0256] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0257] Based on the same inventive concept, this application also provides a query processing apparatus for implementing the query processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more query processing apparatus embodiments provided below can be found in the limitations of the query processing method described above, and will not be repeated here.

[0258] In some embodiments, such as Figure 14 As shown, a query processing apparatus is provided, comprising:

[0259] The acquisition module 1401 is used to acquire the query content and the skill documents that match the query content;

[0260] The adapter module 1402 is used to determine the adapter that matches the skill document based on the protocol specifications followed by the skill document; the adapter encapsulates the underlying calling logic specific to the protocol specifications.

[0261] The metadata extraction module 1403 is used to extract skill metadata from the skill document by parsing the skill document; the skill metadata includes the service endpoint for providing the skill declared in the skill document, and the calling parameters for the service endpoint;

[0262] The skill invocation module 1404 is used to invoke the skill tools provided by the server endpoint through the adapter according to the underlying invocation logic and invocation parameters, and obtain the query results corresponding to the query content.

[0263] In one embodiment, the adaptation module 1402 is specifically configured to: determine the protocol specification followed by the skill document by identifying the protocol type field in the skill document; and, if there is a candidate adapter bound to the protocol specification, determine the candidate adapter as the adapter that matches the skill document.

[0264] In one embodiment, the query processing device further includes: an adapter instance creation module, used to create an adapter instance encapsulating the underlying calling logic specific to the protocol specification when there is no candidate adapter bound to the protocol specification; and a registration module, used to bind the adapter instance and the protocol specification by calling the registration interface to obtain the candidate adapter corresponding to the protocol specification.

[0265] In one embodiment, the adapter instance includes verification processing logic and execution logic; the execution logic encapsulates the protocol specification-specific underlying calling logic. In this embodiment, the adapter instance creation module is specifically used to: create an adapter structure; determine the verification processing logic matching the protocol specification based on general verification rules adapting to multiple protocol specifications and protocol specification-specific verification rules; determine the execution logic matching the protocol specification based on the protocol specification-specific underlying calling logic; and encapsulate the verification processing logic and execution logic into the adapter structure to obtain a protocol specification-specific adapter instance.

[0266] In one embodiment, the query processing apparatus further includes a query module, configured to: obtain a mapping file; and, if the mapping file records a protocol specification, determine that a candidate adapter exists that is bound to the protocol specification. The mapping file is used to record the binding relationship between the candidate adapter and the protocol specification.

[0267] In one embodiment, the adaptation module 1402 is further configured to: obtain the correspondence between the protocol specification and the dedicated field when the skill document does not contain a protocol type field; and determine the protocol specification followed by the skill document according to the correspondence based on the dedicated field contained in the skill document.

[0268] In one embodiment, the query processing apparatus further includes: a field adding module for adding a protocol type field, a server endpoint field, and a call parameter field to the skill document; a content completion module for using the protocol specification as the field content of the protocol type field, and for completing the field content of the server endpoint field and the call parameter field based on the original record of the skill document and the protocol specification; and a document updating module for obtaining the updated skill document if the completed field content passes the verification.

[0269] In one embodiment, the content completion module is specifically used to: obtain the exclusive field content of the exclusive field in the skill document and the original calling parameters in the skill document; complete the field content of the server endpoint field according to the relationship between the exclusive field content and the server endpoint under the protocol specification; and convert the original calling parameters into the field content of the calling parameter field.

[0270] In one embodiment, the adapter further encapsulates verification processing logic for skill documents conforming to the protocol specification; the verification processing logic is used to verify the field content in the skill document. In this embodiment, the metadata extraction module 1403 includes: a metadata field determination unit, which determines the metadata fields contained in the skill document based on the verification processing logic through the adapter; and a metadata extraction unit, which extracts skill metadata from the field content of the metadata fields.

[0271] In one embodiment, the verification processing logic includes general verification rules adaptable to multiple protocol specifications, as well as protocol-specific verification rules. In this embodiment, the metadata field determination unit is specifically used to: determine the general metadata fields contained in the skill document based on the general verification rules using an adapter; determine the extended metadata fields contained in the skill document based on the specific verification rules using an adapter; and determine the metadata fields that include the general metadata fields and the extended metadata fields.

[0272] In one embodiment, the underlying invocation logic includes parameter processing logic, invocation execution logic, and result processing logic. In this embodiment, the skill invocation module 1404 is specifically used to: convert the invocation parameters into request parameters adapted to the protocol specification through the adapter according to the parameter processing logic; invoke the skill provided by the server endpoint through the adapter according to the invocation execution logic and the request parameters to obtain the invocation result corresponding to the query content; and perform structured adjustment of the invocation result through the adapter according to the result processing logic to obtain the query result corresponding to the query content.

[0273] Each module in the aforementioned query processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0274] In some embodiments, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 15 As shown, this computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores data involved in query processing, specifically including resource conversion request information, quota information for different objects, and the amount of resources held. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a query processing method.

[0275] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 16 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a polling processing method. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0276] Those skilled in the art will understand that Figure 15 or Figure 16 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0277] In some embodiments, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the query processing method described above.

[0278] In some embodiments, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the query processing method described above.

[0279] In some embodiments, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the query processing method described above.

[0280] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0281] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logic devices, etc., and are not limited to these.

[0282] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0283] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A query processing method, characterized in that, The method includes: Retrieve the query content and the skill documents that match the query content; Based on the protocol specifications followed by the skill document, an adapter matching the skill document is determined; the adapter encapsulates the underlying calling logic specific to the protocol specifications. By parsing the skill document, skill metadata is extracted from the skill document; the skill metadata includes the service endpoint for providing the skill declared in the skill document, and the calling parameters for the service endpoint; The adapter invokes the skill tools provided by the server endpoint according to the underlying invocation logic and the invocation parameters to obtain the query results corresponding to the query content.

2. The method according to claim 1, characterized in that, The step of determining an adapter that matches the skill document based on the protocol specifications followed by the skill document includes: By identifying the protocol type field in the skill document, the protocol specification followed by the skill document can be determined; If a candidate adapter exists that is bound to the protocol specification, the candidate adapter is identified as the adapter that matches the skill document.

3. The method according to claim 2, characterized in that, The method further includes: If no candidate adapter is available that is bound to the protocol specification, create an adapter instance that encapsulates the underlying calling logic specific to the protocol specification. By calling the registration interface, the adapter instance and the protocol specification are bound together, and the candidate adapter corresponding to the protocol specification is obtained.

4. The method according to claim 3, characterized in that, The adapter instance includes verification processing logic and execution logic; the execution logic encapsulates the underlying calling logic specific to the protocol specification. The creation of an adapter instance encapsulating the underlying calling logic specific to the protocol specification includes: Create an adapter struct; Based on general verification rules that adapt to multiple protocol specifications, and specific verification rules for the aforementioned protocol specifications, a verification processing logic that matches the aforementioned protocol specification is determined. Based on the underlying calling logic specific to the protocol specification, determine the execution logic that matches the protocol specification; The verification processing logic and the execution logic are encapsulated into the adapter structure to obtain an adapter instance specific to the protocol specification.

5. The method according to claim 2, characterized in that, The method further includes: Obtain the mapping file; the mapping file is used to record the binding relationship between candidate adapters and protocol specifications; If the protocol specification is recorded in the mapping file, it is determined that there are candidate adapters bound to the protocol specification.

6. The method according to claim 1, characterized in that, The method further includes: If the skill document does not contain a protocol type field, obtain the correspondence between the protocol specification and the specific field; Based on the specific fields contained in the skill document, the protocol specifications followed by the skill document are determined according to the corresponding relationship.

7. The method according to claim 6, characterized in that, The method further includes: For the aforementioned skill document, add a protocol type field, a server endpoint field, and a call parameter field; Use the protocol specification as the field content of the protocol type field; Based on the original records in the skill document and the protocol specifications, complete the field contents of the server endpoint field and the call parameter field respectively; If the completed field content passes validation, the updated skill document is obtained.

8. The method according to claim 7, characterized in that, Based on the original record in the skill document and the protocol specification, the content of the server endpoint field and the call parameter field is supplemented, including: Obtain the content of the exclusive field in the skill document, as well as the original calling parameters in the skill document; Based on the relationship between the content of the exclusive field and the service endpoint under the protocol specification, complete the field content of the service endpoint field; The original call parameters are converted into the field content of the call parameter field.

9. The method according to claim 1, characterized in that, The adapter also encapsulates the verification processing logic for skill documents that conform to the protocol specifications; The verification processing logic is used to verify the field content in the skill document; The step of extracting skill metadata from the skill document by parsing it includes: The adapter determines the metadata fields contained in the skill document based on the verification processing logic. Extract skill metadata from the field content of the metadata field.

10. The method according to claim 9, characterized in that, The verification processing logic includes general verification rules that adapt to multiple protocol specifications, as well as specific verification rules for the protocol specifications. The step of determining the metadata fields contained in the skill document through the adapter based on the verification processing logic includes: The adapter determines the common metadata fields contained in the skill document based on the common verification rules. The adapter determines the metadata extension fields contained in the skill document based on the exclusive verification rules. Determine the metadata fields that include the general metadata fields and the extended metadata fields.

11. The method according to any one of claims 1 to 10, characterized in that, The underlying calling logic includes parameter processing logic, call execution logic, and result processing logic; The step of invoking the skills provided by the server endpoint through the adapter according to the underlying invocation logic and the invocation parameters to obtain the query results corresponding to the query content includes: The adapter converts the calling parameters into request parameters that are compatible with the protocol specification according to the parameter processing logic. The adapter invokes the skills provided by the server endpoint according to the invocation execution logic and the request parameters to obtain the invocation result corresponding to the query content; The adapter performs a structured adjustment on the call result according to the result processing logic to obtain the query result corresponding to the query content.

12. A query processing device, characterized in that, The device includes: The acquisition module is used to acquire the query content and the skill documents that match the query content; An adapter module is used to determine an adapter that matches the skill document based on the protocol specifications followed by the skill document; the adapter encapsulates the underlying calling logic specific to the protocol specifications. The metadata extraction module is used to extract skill metadata from the skill document by parsing the skill document; the skill metadata includes the service endpoint for providing the skill declared in the skill document, and the calling parameters for the service endpoint; The skill invocation module is used to invoke the skill tools provided by the server endpoint through the adapter according to the underlying invocation logic and the invocation parameters, and obtain the query results corresponding to the query content.

13. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 11.

Images