Cloud-oriented service recommendation and execution method based on multi-agent and graph convolution

Abstract

The application discloses a cloud-oriented service recommendation and execution method based on multi-agent and graph convolution, belongs to the field of cloud service recommendation and execution, and has the advantages of high accuracy and high efficiency.

Description

Technical Field

[0001] This invention pertains to cloud service recommendation and execution scenarios, specifically relating to a cloud-based service recommendation and execution method based on multi-agent and graph convolution. Background Technology

[0002] With the development of the Internet, cloud computing, and microservice architecture, software functionality is gradually shifting from centralized implementation to service-oriented encapsulation. Service providers typically encapsulate functions such as information retrieval, data processing, map positioning, identity authentication, and business queries into application programming interfaces (APIs) accessible over the network. Among these, Web APIs, with their lightweight, easy-to-use, and cross-system reusability characteristics, have become an important technological carrier for connecting heterogeneous software resources.

[0003] In service computing scenarios, it is often necessary to combine data or functions from multiple Web APIs to form composite services. As the number and types of services continue to increase, developers need to select Web API services that meet their needs from a large number of candidate services with similar functions but different descriptions and constantly evolving. Service discovery and recommendation have therefore become important issues in the field of service computing.

[0004] Existing Web API recommendation methods mainly include content-based, collaborative filtering, matrix factorization, knowledge graph, and graph neural network methods. Content-based methods rely on the similarity between the request text and the service description. However, Web API descriptions are usually short, different providers may use different terminology and operational verbs for the same function, and the text contains non-functional information. Relying solely on keywords, tags, or static vectors can easily lead to missed detection of necessary services and confusion with similar services. Methods based on historical interactions can utilize the relationship between historical requests and Web API calls, but the call matrix is ​​sparse, which can easily lead to cold starts and popularity bias for newly released or low-frequency services.

[0005] Existing technologies are beginning to combine text, categories, and relationships to improve recommendation performance. For example, a Web API recommendation method based on multi-task deep neural networks (Cao Zhiying et al., Chinese Patent: CN119760231A, 2025-04-04.) extracts semantic features from Mashup requests and Web API descriptions, and combines them with tasks such as call matching and category prediction for Web API recommendations. A Web API recommendation method and system based on knowledge graphs (Liu Jiahui et al., Chinese Patent: CN115268995A, 2022-11-01.) constructs a knowledge graph connecting Mashups, Web APIs, and related attributes, and generates recommendation results by integrating functional and non-functional factors. These methods can utilize richer information than simple text matching, but they still struggle to fully uncover the potential dependencies between services.

[0006] Knowledge graphs, graph neural networks, or hypergraph methods can further represent multivariate relationships between services, categories, tags, and invocation behaviors, and can be used to mine service co-occurrence and higher-order dependencies. For example, the R2API method uses historical invocation and tag relationships between Mashups and Web APIs to construct a hypergraph, and learns service representations through a hypergraph neural network. Some studies have also used heterogeneous graphs to simultaneously model functional similarity and complementarity between services. However, the structure of correlation graphs is usually still constructed from historical records, tag relationships, or pre-defined rules, which may contain noise from accidental co-occurrences. For services that have dependencies or collaborations in actual processes but do not co-occur in historical data, implicit relationships remain difficult to discover directly.

[0007] Furthermore, functional similarity, complementarity, or historical co-occurrence do not equate to the ability to actually combine interfaces. Whether multiple Web APIs can form an executable service chain is also affected by factors such as input / output formats, parameter constraints, call order, interface versions, and real-time status. Therefore, recommendations based solely on semantic relationships or static graph relationships may still fail to complete the actual task due to parameter mismatches, incorrect call order, or changes in service status.

[0008] In recent years, Large Language Models (LLMs) have demonstrated strong capabilities in natural language understanding, task decomposition, and contextual reasoning. Combining them with retrieval enhancement generation, knowledge bases, and callable external tools allows for the parsing of unstructured requirements and the retrieval and invocation of services based on service documentation. For example, ToolLLM, through a large-scale real-world API set, API retrieval, and call path search, enables large language models to select and invoke external APIs based on natural language needs. API-Bank evaluates the tool-use capabilities of large language models in terms of task planning, API retrieval, and API invocation, providing a new technical path for connecting natural language needs with structured interfaces.

[0009] However, the output of large language models is probabilistic, and their parameterized knowledge may be inconsistent with continuously updated interface documentation and real-time status. This can easily lead to problems such as misunderstandings of requirements, generating non-existent interfaces and parameters, omitting necessary external services, and insufficient sensitivity to the accumulation of intermediate errors. While a single LLM agent can perform planning and tool invocation, it needs to simultaneously handle multiple functions, including requirement understanding, service selection, parameter generation, execution monitoring, and result verification. Under complex tasks, local errors may continue to propagate along the call chain.

[0010] LLM multi-agent systems assign different functions to agents with varying responsibilities, fostering collaboration through communication or mutual evaluation. MetaGPT, for example, assigns different roles to different agents and organizes task collaboration according to pre-defined processes. Some multi-agent tool invocation schemes further define different agents such as planners, tool providers, and reflectors to handle task decomposition, tool selection, execution results, and exceptions separately. However, they still have shortcomings in failure verification and the comprehensive organization of multi-agent output schemes. How to comprehensively utilize service text, historical call information, and inter-service structural relationships to integrate demand processing, service recommendation, service composition, actual execution, result verification, and failure correction into a unified closed loop remains a technical problem that needs to be solved in this field. Summary of the Invention

[0011] To overcome the shortcomings of existing cloud service recommendation and execution methods in service semantic representation, inter-service collaborative dependency discovery, and the connection between recommendation results and inference execution, as well as the frequent failures during the process from request parsing to service selection and execution, this invention proposes a cloud-based service recommendation and execution method based on multi-agent intelligence and graph convolution. First, the service description text is semantically enhanced, and a text feature extraction model is trained using contrastive learning. Then, a heterogeneous relationship graph is constructed based on the historical call relationships between requests and services, and the attribution relationships between services and tags. Service co-occurrence relationships and affinity relationships are fused to generate an implicit service dependency graph. Next, adjacent service features are aggregated through graph convolution to complete the preference calculation between requests and services and service recommendation. Then, a request processing agent is used to generate candidate actions and detect early failures, writing the structured information of the recommended services into the execution trajectory. The inference execution agent gradually generates service call results or text results. Finally, a systematic verification and correction mechanism is constructed through a multi-role metacognitive agent to improve the accuracy of cloud service recommendations.

[0012] The technical solution adopted by this invention to solve its technical problem is: A cloud-based service recommendation and execution method based on multi-agent and graph convolution is proposed. First, semantic enhancement is performed on the service description text, and a text feature extraction model is trained using contrastive learning. Then, a heterogeneous relationship graph is constructed based on the historical call relationships between demands and services, and the attribution relationships between services and tags. Service co-occurrence relationships and affinity relationships are fused to generate an implicit service dependency graph. Next, adjacent service features are aggregated through graph convolution to complete preference calculation between demands and services and service recommendation. Then, a demand processing agent is used to generate candidate actions and determine early failures, writing the structured information of the recommended services into the execution trajectory. The inference execution agent gradually generates service call results or text results. Finally, a systematic verification and correction mechanism is constructed through a multi-role metacognitive agent.

[0013] Furthermore, the method includes the following steps: Step 1: Parse user requirements and correct early failures: Generate candidate actions based on user requirement text, model internal knowledge, parameterized memory, and historical trajectories; perform early failure detection on the candidate actions; when a candidate action passes the early failure detection, it is determined as the action to be executed; when a candidate action fails the early failure detection, a new candidate action is generated; when the action to be executed belongs to the service call action set, extract the current service requirement text from the action to be executed. Step 2: Construct semantically enhanced samples and train the text feature extraction model: Perform verb replacement semantic enhancement on the service description text, construct comparative learning samples based on the service description text before and after enhancement, and use the comparative learning samples to train the text feature extraction model. Step 3: Construct the implicit service dependency graph: Based on the call relationship between historical requirements and registered services, as well as the attribution relationship between registered services and service tags, generate an implicit service dependency graph representing the strength of service collaboration; Step 4: Train the service recommendation model: Enhance the semantic features of services using the implicit dependency graph, calculate the preference scores of historical demands for registered services, and train the service recommendation model based on historical service call records. Step 5, Online Inference Stage: Determine the Recommended Service Set Based on the Current Service Request Text: Receive the current service request text output from Step 1, and determine the top recommended services corresponding to the current service request text from the registered service set. Individual registration service.

[0014] Furthermore, the method also includes the following steps: Step 6: Construct an enhanced execution trajectory and gradually generate inference execution results; associate the service information output in Step 5 with the service call actions in the basic historical trajectory, construct an enhanced execution trajectory based on the association results, and complete inference, service call or text output in sequence according to the enhanced execution trajectory; Step 7: Perform layered failure verification on the execution process; the qualified verification agent performs execution verification in service selection, parameter generation and output parsing respectively, and generates execution failure information when execution failure is detected; Step 8: Generate metacognitive correction schemes based on execution failure information: Input the reasoning and output processes that have resulted in execution failures into metacognitive regulatory agents with different decision roles and attribute vectors to generate multiple independent initial correction schemes. Step 9: Evaluate the metacognitive correction scheme and execute rerouting: Perform scheme evaluation, confidence update and scheme iteration among multiple metacognitive agents. When the consensus condition is met or the upper limit of the iteration round is reached, determine the target correction scheme and trigger the corresponding rerouting action according to the correction type of the target correction scheme.

[0015] The process of step one is as follows: Step (1.1) Obtain the input for demand processing and construct the current decision state. ; Step (1.2) Based on the current decision state Generate the current candidate action; Step (1.3) involves performing early failure detection on the current candidate action through an intent failure detection agent. Early failure detection is defined as: when executing the current candidate action... Previously, it was determined whether the current candidate action belonged to the categories of ignored requirements, overconfidence, or unproductive loops: ; in, This serves as a comprehensive early failure indicator. The intent failure detection agent determines whether an intent failure problem exists by using preset prompts; Step (1.4) Execute candidate actions based on the early failure discrimination results. Alternatively, rerouting can be performed.

[0016] The process of step two is as follows: Step (2.1) Obtain service semantic training data; Step (2.2) performs verb replacement on the service description text to obtain a new enhanced service description text; Step (2.3) identifies positive samples from the candidate enhanced description text; Step (2.4) Construct a complete contrastive learning sample and training text feature extraction model; The process of step three is as follows: Step (3.1) Obtain service relationship data and construct a heterogeneous relationship graph ; Step (3.2) determines service co-occurrence relationships and service affinity relationships; Step (3.3) generates co-occurrence relationship channel features and affinity relationship channel features respectively; Step (3.4) merges the two types of relationship channels and generates service relationship edge features; Step (3.5) uses the Sigmoid function to generate a service implicit dependency graph; Step (3.6) Calculate the structural constraint loss of the service implicit dependency graph.

[0017] The process of step four is as follows: Step (4.1) Strengthen service characteristics based on service implicit dependency graph; Step (4.2) Generate requirement features Service characteristics ; Step (4.3) for historical requirements and registration services Calculate the inner product of demand-enhancing features and service-enhancing features; ; The inner product can also be expressed as:

[0018] in, Indicating historical needs Registration service The predicted preference score, Indicate demand characteristics and The angle between them; Step (4.4) Training the building and service ranking loss calculate; Step (4.5) Calculate the implicit structure supervision loss. ; The process of step five is as follows: Step (5.1) When the action to be executed generated in step one belongs to the service invocation action set. At that time, extract the current service request text from the executed action. ; Step (5.2) Generate semantic features that enhance the current requirements ; Step (5.3) Determine the set of recommended services .

[0019] The process of step six is ​​as follows: Step (6.1) Obtain the basic historical trajectory and Recommendation Services and information ; Step (6.2) Constructing the Enhanced Execution Trajectory ; Step (6.3) Construct the current execution input ; Step (6.4) is based on the current execution input. Generate candidate execution results for the current step; Step (6.5) performs self-evaluation and internal correction on the candidate execution results to generate the current step's corrected execution result. ; Step (6.6) Execute the service or generate text based on the modified execution result.

[0020] The process of step seven is as follows: Step (7.1) Verify whether the current service selection is invalid; Step (7.2) verifies whether the current service parameters are invalid; Step (7.3) Verify whether the service output parsing is invalid; Step (7.4) generates comprehensive execution failure information.

[0021] The process of step eight is as follows: Step (8.1) Construct a set of metacognitive regulatory agents ; Step (8.2) Generate the first round of metacognitive correction scheme: respectively input metacognitive regulation into and attribute vector Input the corresponding metacognitive agent to generate the first round of metacognitive correction scheme;

[0022] in, Metacognitive agents The generated first round of revision scheme, , Indicates the currently executing input. Indicates the current reasoning trajectory. This indicates that the current step modifies the execution result. This indicates an execution failure message. Metacognitive agents Attribute vectors;

[0023] in, It is a set consisting of the first-round correction schemes of the four intelligent agents; The process of step nine is as follows: Step (9.1) Establish communication relationships between metacognitive agents and define the communication relationship matrix: ; in, ; Step (9.2) Generate evaluation information on metacognitive agent schemes among metacognitive agents; Step (9.3) Initialize and update the agent confidence matrix. ; Step (9.4) targets metacognitive agents. In the The correction scheme generated in each round is based on the confidence level of the current round. and communication relationship Calculate the overall credibility: ; in, This indicates a preset small positive number to prevent the denominator from being zero; Step (9.5) Based on evaluation feedback Update and fix ; Step (9.6) Perform consensus determination; Step (9.7) involves pairwise comparisons of schemes with similar credibility. Step (9.8) Calculate the long-term ability score based on the historical comparison results; Step (9.9) performs different types of result corrections and triggers the corresponding rerouting actions.

[0024] The main benefits of this invention are: improving the accuracy of cloud service recommendations. Attached Figure Description

[0025] Figure 1 It is a complete architecture for cloud-based service recommendation and execution methods based on multi-agent and graph convolution, from user input requirements to obtaining results.

[0026] Figure 2 This refers to the processing procedure of the service recommendation module. Detailed Implementation

[0027] The present invention will now be further described with reference to the accompanying drawings.

[0028] Reference Figure 1 and Figure 2 This paper presents a cloud-based service recommendation and execution method based on multi-agent and graph convolution. The overall architecture of this method includes a demand processing module, a service recommendation module, an inference and execution module, and a metacognitive regulation module. The demand processing module corresponds to step one, the service recommendation module to steps two through five, the inference and execution module to steps six and seven, and the metacognitive regulation module to steps eight and nine.

[0029] This embodiment of the cloud-based service recommendation and execution method based on multi-agent and graph convolution includes the following steps: Step 1: Analyze user requirements and correct for failures to generate requirement processing results; In this embodiment, demand processing serves as the first response function after the multi-agent system receives user input. The demand processing agent generates candidate actions based on the user's demand text and historical trajectory, performs early failure judgment before execution, and executes the candidate actions or regenerates the candidate actions based on the judgment results.

[0030] The process of step one in this example is as follows: Step (1.1) Obtain the input for demand processing and construct the current decision state. ,as follows: Step (1.1.1) Obtain user requirement text ; Step (1.1.2) at the current time step To obtain the historical trajectory formed previously: ; in, Indicates the first The actions performed in each time step This indicates the corresponding action output; the initial time step satisfies... ; Step (1.1.3) Embed the user requirement text according to the prompt word template. and historical trajectory Construct the current decision state The current decision state is used to generate candidate actions, and includes at least a requirement content field and an external service dependency determination instruction, as well as at least one of the following: callable service type, task constraints, or historical processing results.

[0031] Step (1.2) Based on the current decision state The current candidate action is generated as follows: Step (1.2.1) Obtain the candidate action space corresponding to the demand processing agent. .in, Represents a set of service call actions. Represents a set of reasoning actions. Represents a set of response actions; Step (1.2.2) sets the current decision state. Input demand processing intelligent agent Generate the current candidate action ,and The candidate actions include action types and their corresponding content: when At this time, the action content is a service requirement description extracted from the user's requirement text, which is used in step five to determine the service to be invoked. At that time, the action content is the intermediate inference result of this time step. At that time, the action content is the candidate answer text.

[0032] Step (1.3) involves executing the candidate action. Previously, the agent was judged based on intent failure. , and Determine if there is neglect of demand, overconfidence, or unproductive cycles, and generate comprehensive early failure indicators. , This indicates that at least one early failure has been detected. This indicates that no early failure was detected; the process is as follows: Step (1.3.1) Perform the requirement ignore failure judgment. When the internalized parameters of the requirement processing agent are insufficient to obtain an answer, the current candidate action is an answer action, and the necessary service that can satisfy the current requirement has not yet been executed in the historical trajectory, the requirement ignore failure flag is set. Set to 1 if necessary, otherwise set to 0. The necessary service set is denoted as... ; Step (1.3.2) performs overconfidence failure detection. This occurs when the current candidate action is a response action and its candidate response text... The correctness check failed, and the necessary service set does not exist in the historical trajectory. When an action has already been performed, an overconfidence failure flag will be displayed. Set to 1 otherwise set to 0; Step (1.3.3) performs non-productive cyclic failure detection. The number of consecutive inferences in the historical trajectory is counted. .when Reaching the preset maximum trajectory length If the continuous inference process neither calls a service nor meets the preset convergence condition, a non-productive loop failure will be marked. Set to 1 otherwise set to 0; Step (1.3.4) generates a comprehensive early failure identifier based on the three types of failure identifiers. .

[0033] Step (1.4) Execute candidate actions based on the early failure discrimination results. Alternatively, rerouting can be performed, as follows: Step (1.4.1) when At that time, execute the current candidate action. Get action output And update the historical trajectory in chronological order. ,in, This indicates a trajectory append operation; Step (1.4.2) when When the current candidate action is stopped, the inference context deemed invalid is removed from the current decision state, resulting in the reset historical trajectory. ; Step (1.4.3) involves processing the user requirement text. and the reset historical trajectory Input feedback corrected policy function Generate correction candidate actions Then return to step (1.3) to re-perform early failure detection.

[0034] Step (1.5) generates the requirement processing result based on the action type of the action being performed, as follows: Step (1.5.1) When the action being executed belongs to the service invocation action set At that time, extract the current service requirement text from it. And output it to step five; Step (1.5.2) When the action to be performed belongs to the set of inference actions At that time, the action and its intermediate reasoning results are combined into an action-output pair, written into the historical trajectory, and the updated... Used as input for the historical trajectory in the next time step; Step (1.5.3) When the action to be performed belongs to the set of response actions When the time comes, the candidate answer text carried by the request is obtained, and the candidate answer text is identified as the user answer text output by the request processing module.

[0035] Reference Figure 2 It should be noted that in the service recommendation module, steps two through four belong to the offline training phase. The verb substitution semantic enhancement module corresponds to step two, which trains the text feature extraction model separately. Steps three and four jointly optimize the implicit dependency graph and the service recommendation model; the implicit dependency strength graph construction module corresponds to step three, and the service recommendation module corresponds to step four. Steps five through nine belong to the online inference phase, completing service recommendation, inference execution, failure verification, and rerouting correction with fixed model parameters.

[0036] Step 2: Construct semantically enhanced samples and train a text feature extraction model: Perform verb replacement semantic enhancement on the service description text, construct comparative learning samples based on the service description text before and after enhancement, and use the comparative learning samples to train a text feature extraction model.

[0037] The process of step two in this embodiment is as follows: Step (2.1) Obtain service semantic training data, as follows: Step (2.1.1) Obtain the registration service set ,in, Indicates the number of registered services. Indicates the first Each registration service. It must have at least a corresponding service description text. .

[0038] Step (2.1.2) involves obtaining the service description text, as follows: Step (2.1.2.1) is for each registered service Get the corresponding service description text ; Step (2.1.2.2) will include the service description text. Divided into word sequences: ; in, Service description text The number of words contained; Step (2.1.3) Obtain historical requirements and service call records to construct a historical requirement set: ; Each historical requirement Text with historical needs And the corresponding collection of services that have been invoked: .

[0039] in, Indicates the execution of historical requirements The actual registration service invoked at that time. Specifically, the historical requests can come from a pre-built dataset, historical interaction logs, or other data sources that can obtain information about users' historical requests.

[0040] Step (2.2) performs verb replacement on the service description text to obtain the new enhanced service description text, as follows: Step (2.2.1) Perform part-of-speech tagging on the service description text: Tag the service description text... Input the part-of-speech tagging model to obtain the part-of-speech tagging results for each word; based on the part-of-speech tagging results, extract the part-of-speech tagging data from the service description text. Extract the noun set and verb set: ; ; in, Service description text The set of nouns in; Service description text The set of verbs in; Indicates the quantity of nouns; This indicates the number of verbs. Specifically, the part-of-speech tagging model is a natural language processing model used for part-of-speech analysis of text. The part-of-speech tagging model includes, but is not limited to, rule-based methods, statistical learning methods, and deep learning methods. In one specific implementation, the part-of-speech tagging component in Stanford CoreNLP is used to tag the input text with parts of speech.

[0041] Step (2.2.2) determines the candidate synonyms for each verb in the verb set: For the verb set... Each verb to be replaced in The process involves retrieving candidate synonyms for the verb to be replaced from a pre-defined synonym knowledge base and calculating the semantic similarity between each candidate synonym and the verb to be replaced. Specifically, the semantic distance between the word to be processed and the candidate synonyms is calculated based on the semantic hierarchy relationship between words in WordNet, and the semantic similarity is determined according to the semantic distance. The top synonyms are selected in descending order of semantic similarity. From the candidate synonyms, we get: ; in, Indicates the verb to be replaced The corresponding set of candidate synonyms.

[0042] Step (2.2.3) generates candidate enhanced description text. Replace the service description text with candidate synonyms respectively. The corresponding verbs to be replaced are selected, while keeping the nouns and other unselected words in the service description text unchanged, resulting in a set of candidate enhanced description texts: ; in, This refers to the service description text. Number of candidate enhanced description texts generated.

[0043] Step (2.3) identifies positive samples from the candidate enhanced description text, as follows: Step (2.3.1) generates the original descriptive semantic vector. Service description text Input the text encoding model to obtain the original description encoding vector; then input the original description encoding vector into a multilayer perceptron to obtain the original description semantic vector: ; in, Represents a text encoding model. This represents a multilayer perceptron. Service description text The corresponding original semantic vector. In this embodiment, the text encoding model is implemented using a pre-trained language model based on the BERT architecture. The multilayer perceptron includes an input layer, at least one hidden layer, and an output layer, used to perform non-linear mapping on the input features and output classification results; Step (2.3.2) involves processing the candidate enhanced description texts. Inputting a text encoding model and a multilayer perceptron (MLP), we obtain candidate enhanced description semantic vectors: ; Step (2.3.3) calculates the original descriptive semantic vectors respectively. With each candidate augmented description semantic vector Cosine similarity between : ; in, This represents the dot product of two vectors. Let L2 be the norm. The cosine similarity can be calculated as follows: .

[0044] Step (2.3.4) selects the preset top-ranked texts from the candidate enhanced description text set according to the cosine similarity from high to low. The candidate enhanced description texts form the positive sample description set: .

[0045] Step (2.4) constructs a complete contrastive learning sample and training text feature extraction model, as follows: Step (2.4.1) involves constructing the negative sample description set and the candidate sample set, as follows: Step (2.4.1.1) for the registration service By selecting samples from the service description text of other registered services, a set of negative sample descriptions is obtained: ; Step (2.4.1.2) Positive Sample Description Set and negative sample description set Together they constitute the candidate sample set: .

[0046] Step (2.4.2) Generate contrastive learning vectors , , . Use candidate sample set , Using positive sample set , Using negative sample set The specific generation method is as follows: ; ; ; Step (2.4.3) Calculate the semantic contrast loss based on the original description semantic vector, the positive sample description semantic vector, and the candidate sample semantic vector. : ; in, This represents the set of semantic vectors corresponding to the set of candidate samples. This represents a temperature parameter used to adjust the smoothness of the semantic similarity distribution during the loss calculation process. When the value is small, the model pays more attention to the differences between highly similar samples. A larger value results in a smoother model output distribution. The temperature parameter can be adjusted based on the size and distribution of the actual training data, as well as the model training performance.

[0047] Step (2.4.4) updates the model parameters of the text encoding model and the multilayer perceptron using semantic contrastive loss until the loss function no longer decreases within a preset number of consecutive rounds, thus obtaining the trained text feature extraction model. .

[0048] Step 3: Construct the implicit service dependency graph: Based on the calling relationship between historical requirements and registered services, as well as the attribution relationship between registered services and service tags, generate an implicit service dependency graph representing the strength of service collaboration.

[0049] The process of step three in this embodiment is as follows: Step (3.1) Obtain service relationship data and construct a heterogeneous relationship graph ,as follows: Step (3.1.1) involves obtaining the historical demand set and the registered service set, as follows: Step (3.1.1.1) Obtain the historical demand set: ; in, Indicates the first A historical need, Indicates historical demand quantity; Step (3.1.1.2) Obtain the collection of registered services: ; in, Indicates the first Individual registration service, This indicates the number of registered services.

[0050] Step (3.1.2) involves obtaining the service tag set and service tag attribution records, as follows: Step (3.1.2.1) Obtain the service tag set : ; in, Indicates the first Service tags, This indicates the number of service tags.

[0051] Step (3.1.2.2) for the registration service Obtain the registration service The associated subset of service tags is denoted as: ; Step (3.1.3) Construct a heterogeneous relationship graph The set of nodes: based on historical demand sets Registration service collection Service tag collection Constructing a heterogeneous relationship graph : ; Among them, the node set for: ; in, Represents the set of historical demands The corresponding set of historical demand nodes, Represents a collection of registered services The corresponding set of service nodes Represents a set of service tags The corresponding set of service tag nodes.

[0052] Step (3.1.4) Constructing the historical requirement-service call relationship edge: Obtaining historical service call records. For historical requirements... The historical requirements The registered services actually invoked constitute the set of invoked services: ; when At that time, at the historical demand node service nodes Establish a call relationship edge between them: ; in, This represents the set of historical demand-service call relationship edges.

[0053] Step (3.1.5) Construct service-label attribution relationship edges: when At the time, at the service node Service tag node Establish label attribution relationships between them: ; in, This represents the set of service-label attribution edges.

[0054] Step (3.1.6) Heterogeneous Relationship Diagram edge set Represented as: .

[0055] Step (3.2) determines the service co-occurrence relationship and service affinity relationship, as follows: Step (3.2.1) Determine the set of shared historical requirements: for registration services and registration services Determine the set of shared historical requests that simultaneously invoke the two registration services: ; Will share historical demand sets The number of historical demands included is determined as the service co-occurrence count: ; in, Indicates registration service and registration services It must be invoked at least once by the same historical requirement.

[0056] Step (3.2.2) generates normalized service co-occurrence strength. ,as follows: Step (3.2.2.1) determines the maximum number of service co-occurrences across all off-diagonal service pairs: ; Step (3.2.2.2) is based on the number of times the service co-occurs. Generate normalized service co-occurrence strength: ; in, This indicates a preset positive number to prevent the denominator from being zero. .

[0057] Step (3.2.3) for registration service and registration services The set of shared service tags is determined based on the corresponding subset of service tags: ; when At that time, the registration service will be available. and registration services The relationship between them is defined as a service affinity relationship.

[0058] Step (3.2.4) Based on the shared service tag set The service affinity strength is generated by the union of service tags: ; in, Service friendliness With registration service and registration services The proportion of shared service tags increases as the proportion of shared service tags increases.

[0059] Step (3.2.5) Based on the number of service co-occurrences Service affinity Generate a set of candidate service relationship pairs: ; Candidate service relationship set Each element in Indicates registration service and registration services There must be at least one of the following relationships between them: service co-occurrence relationship or service affinity relationship.

[0060] Step (3.3) generates co-occurrence relationship channel features and affinity relationship channel features respectively, as follows: Step (3.3.1) Obtain registration service initial semantic features of the service and the initial semantic features of the service Input the service-side multilayer perceptron to obtain the initial features of the service nodes: ; Step (3.3.2) Obtain historical requirements Historical demand initial semantic features and the initial semantic features of the historical requirements Input the demand-side multilayer perceptron to obtain the initial features of historical demand nodes: ; Step (3.3.3) will add service tags. The corresponding label identifier is input into the service label embedding layer to obtain the initial features of the service label node: ; in, This indicates a service tag embedding layer that maps service tag identifiers to preset dimension vectors.

[0061] Step (3.3.4) for candidate service relationship pairs When sharing historical demand sets When not empty, perform mean aggregation on the initial features of historical demand nodes in the shared historical demand set: ; When sharing historical demand sets When empty, the shared historical demand aggregation feature is set to a zero vector of a preset dimension: ; Step (3.3.5) Generate registration service and registration services Co-occurrence relationship channel characteristics : Set co-occurrence relationship type features The initial features of the two service nodes, the aggregated features of shared historical demands, the normalized service co-occurrence strength, and the co-occurrence relationship type features are input into the co-occurrence relationship multilayer perceptron: ; in, This indicates vector concatenation.

[0062] Step (3.3.6) Aggregate shared service tag features: For candidate service relationship pairs When sharing service tag set When the set is not empty, perform mean aggregation on the initial features of the service tag nodes in the shared service tag set: ; When sharing service tag sets When empty, the shared service label aggregation feature is set to a zero vector of a preset dimension: ; Step (3.3.7) Register Service and registration services Affinity channel characteristics between : Set affinity relationship type characteristics The initial features of the two service nodes, the aggregated features of shared service labels, the service affinity strength, and the affinity relationship type features are input into the affinity relationship multilayer perceptron: ; Step (3.4) merges the two types of relationship channels and generates service relationship edge features, as follows: Step (3.4.1) Concatenate co-occurrence relationship channel features Characteristics of Affinity Relationship Channels For candidate service relationship pairs The co-occurrence relationship channel characteristics Characteristics of Affinity Channels The initial features of the two service nodes are concatenated: ; In this method, the initial features of two service nodes are directly spliced ​​together to form a jump connection from the initial features of the service nodes to the service relationship edge features.

[0063] Step (3.4.2) will concatenate the relational features. Input relations are fused using a multilayer perceptron to obtain fused service relation edge features: ; Integration of service relationship edge features It also includes co-occurrence relationship information generated from historical service call records and affinity relationship information generated from service tag affiliation records.

[0064] Step (3.5) uses the Sigmoid function to generate the implicit service dependency graph, as follows: Step (3.5.1) Generate service dependency edge weights The process is as follows: Step (3.5.1.1) will integrate the service relationship edge features. Inputting a linear mapping layer yields unnormalized service dependency scores: ; Step (3.5.1.2) uses the Sigmoid function to normalize the unnormalized service dependency score. Mapping to interval : ; in, Indicates registration service Point to registration service The service depends on the right-hand side. .

[0065] Step (3.5.1.3) for each registered service Set self-loop weights: ; Step (3.5.2) sets up the service nodes. Candidate service relationship set Service Dependency Edge Weight Matrix Combining them into a service implicit dependency graph: ; During model training, the set of candidate service relationships is preserved. All services in the process depend on edge weights .

[0066] Step (3.6) calculates the structural constraint loss of the service implicit dependency graph, as follows: Step (3.6.1) involves the set of candidate service relationship pairs. The non-self-looping services in the process rely on edge weights to perform summation, and the quantities are normalized according to the candidate service relationships: ; Minimize sparse loss Reduce the weight of service-dependent edges that do not receive other loss support towards 0.

[0067] Step (3.6.2) Based on the number of times the service co-occurs Determine the set of positive relations in historical co-calling: ; Historical co-call positive relation set The service pairs in the context represent service pairs that have reached a preset number of common calls in the historical service call records. This is a threshold for the number of co-occurrences, specifically used to adjust the impact of co-occurrence intensity during service dependency processes.

[0068] Step (3.6.3) involves using the historical co-call positive relation set. Co-occurrence intensity of normalized services Calculate the loss for maintaining historical co-call relationships: ; Minimize the loss of preserving historical co-call relationships Services that have reached a preset threshold for the number of historical co-calls should maintain a large service dependency edge weight.

[0069] Step (3.6.4) generates structural constraint loss based on sparse loss and historical co-call relationships: ; in, Represents the sparse loss weights. This indicates that the historical co-call relationship maintains the loss weight, when As the graph size increases, the model focuses more on reducing redundant connections in the graph structure. As the number of calls increases, the model pays more attention to maintaining historical co-call relationships. Affinity channel features. Features of participating in integrated service relationships The generation of services does not involve setting affinity to maintain loss, thus allowing for better learning of co-occurrence relationships between services to identify implicit dependencies between them.

[0070] Step 4: Train the service recommendation model: Enhance the semantic features of services using the implicit dependency graph, calculate the preference scores of historical demands for registered services, and train the service recommendation model based on historical service call records.

[0071] The process of step four in this embodiment is as follows: Step (4.1) strengthens service characteristics based on the implicit dependency graph, as follows: Step (4.1.1) Calculate the service-dependent attention weights The process is as follows: Step (4.1.1.1) for service nodes and its adjacent service nodes Based on the initial semantic features of adjacent services and the dependency weights between them Calculate the unnormalized attention score: ; in, Represents the service feature transformation matrix. This represents the weight transformation matrix. This indicates the dimension of the transformed feature.

[0072] Step (4.1.1.2) involves normalization to obtain the service. For services Attention weights : ; Step (4.1.2) Aggregates features of neighboring services based on service dependency attention weights:

[0073] Get services Corresponding service dependency reinforcement features .

[0074] Step (4.2) Generate requirement features Service characteristics ,as follows: Step (4.2.1) Determine the registration service characteristics The process is as follows: Step (4.2.1.1) involves adaptively controlling the retention ratio of the service's own semantics and service dependency information by concatenating the original semantic mapping features of the service with the service dependency enhancement features, and generating a gating vector: ; Step (4.2.1.2) uses gated vectors to fuse the two types of service features to obtain the service... The final characteristic: ; in, This represents element-wise multiplication. and These are the learnable parameters of the gating network. The gating mechanism can preserve the semantic information of the service itself and reduce the impact of irrelevant service dependencies on feature representations.

[0075] Step (4.2.2) involves initializing the semantic vector of the requirements. Execute residual mapping to generate historical requirement features : ; in, and These represent the linear and nonlinear mapping branches on the demand side, respectively. This structure enhances the expressive power of demand features while preserving the original demand semantics, and enables new online demands to generate features solely based on textual semantics.

[0076] Step (4.3) for historical requirements and registration services Calculate the inner product of demand-enhancing features and service-enhancing features: ; in, Indicating historical needs Registration service The predicted preference score.

[0077] Step (4.4) Training the building and service ranking loss The calculation is as follows: Step (4.4.1) involves constructing the ranked training samples, as follows: Step (4.4.1.1) for historical requirements The registration service that it actually calls If it is identified as a positive service, register the services that it has not yet invoked. Determined as a negative service; Step (4.4.1.2) Construct a ranked training triplet based on historical demand, positive services, and negative services. .

[0078] Step (4.4.2) Calculate the ranking loss based on the positive and negative service preference scores: ; in, This represents the Sigmoid function. This represents the regularization constraint loss during the training process of the ranking model. In this embodiment, it is specifically implemented by performing L2 regularization through regularization weights.

[0079] Step (4.5) Calculate the implicit structure supervision loss. ,as follows: Step (4.5.1) for historical requirements and The degree of service call overlap is calculated based on the set of services already called by both parties: ; Step (4.5.2) Calculate the implicit structural supervision loss on the demand side. : ; in, Indicates the threshold of demand relationship. This represents a positive integer balancing parameter. This loss term applies a loss to historical demands with low service call overlap but high feature similarity.

[0080] Step (4.5.3) Calculate the implicit structure supervision loss on the service side. : ; in This indicates the threshold for service dependencies.

[0081] Step (4.5.4) generates the training loss for the recommendation module. And update the model parameters: generate the total training loss based on the ranking loss, the demand-side implicit structure supervision loss, and the service-side implicit structure supervision loss. ; in, The implicit structure supervision loss weights are used to update the parameters of the service recommendation model using the total training loss until the model training termination condition is met, thus obtaining the trained service recommendation model. .

[0082] Step 5, Online Reasoning Stage: Determine the Recommended Service Set Based on the Current Service Request Text: Receive the current service request text extracted in Step 1, and determine the top k registered services corresponding to the current service request text from the registered service set.

[0083] Step five of this embodiment is as follows: Step (5.1) When the action to be executed generated in step one belongs to the service invocation action set. At that time, extract the current service request text from the executed action. 。; Step (5.2) Generate semantic features that enhance the current requirements ,as follows: Step (5.2.1) involves processing the current service requirement text. Input the trained text feature extraction model to obtain the initial semantic features required for the current task: ; Step (5.2.2) involves analyzing the service dependency strength graph in the service recommendation model. The pruning process is as follows: Step (5.2.2.1) Obtain the output of the implicit dependency strength map of the service recommendation model in the online inference stage. ; Step (5.2.2.2) calculates the average service dependency strength excluding the diagonal elements: ; The average value Determined as the dependency strength filtering threshold; Step (5.2.2.3) generates filtered service dependency weights based on the dependency strength filtering threshold. : ; Step (5.2.2.4) As subsequent inputs to the model during the online inference phase, the definition is derived from the original model structure. The new model structure is as follows .

[0084] Step (5.2.3) uses the trained service recommendation model to perform feature transformation on the initial semantic features of the current demand, obtaining the enhanced features of the current demand: ; in, This represents the demand-side feature transformation network in the trained service recommendation model.

[0085] Step (5.3) Determine the set of recommended services ,as follows: Step (5.3.1) is for each registered service Calculate the preference score between current demand enhancement features and service enhancement features: ; Step (5.3.2) is based on each service Based on the current demand preference score, a set of service preference scores is obtained: ; Step (5.3.3) sorts the registered services in descending order of service preference scores and selects the top-ranked services. Each registration service determines the set of recommended services. : ; in This indicates that the service preference scores are sorted and then the top-ranked services are selected. Operation of each service This is a preset quantity parameter used to determine the number of recommended services to be output.

[0086] Step 6: Construct an enhanced execution trajectory and gradually generate inference execution results: Associate the recommended service information output in Step 5 with the service call actions in the basic historical trajectory to construct an enhanced execution trajectory, and complete inference, service call or text output in sequence according to the enhanced execution trajectory.

[0087] The process of step six in this embodiment is as follows: Step (6.1) Obtain the basic historical trajectory and Recommendation Services and information ,as follows: Step (6.1.1) Obtain the basic historical trajectory generated in Step 1 .in, Indicates the first Actions already executed in each time step This indicates the corresponding action output; Step (6.1.2) Obtain the recommended service set generated in Step 5 based on the current service requirement text. Each recommended service Corresponding service structured information The service structured information includes service name, preference score, service description, input parameter structure, parameter type constraints, output field structure, and call interface information, which are used for subsequent service selection, parameter generation, and output parsing.

[0088] Step (6.2) Constructing the Enhanced Execution Trajectory ,as follows: Step (6.2.1) identifies the service call action and structured information, as follows: Step (6.2.1.1) reads the actions in the basic historical trajectory sequentially. , judge the action Does it constitute a service invocation action? Step (6.2.1.2) when the action When it is not a service invocation action, set the corresponding service structured information to... When the action When a service invocation action occurs, the corresponding recommended service is determined from the recommended service set, and the structured information of that service is obtained. .

[0089] Step (6.2.2) For each action in the basic historical trajectory—output pair This is combined with the corresponding service structured information to obtain enhanced trajectory elements. .

[0090] Step (6.2.3) arranges the enhanced trajectory elements according to the chronological order in the basic historical trajectory, resulting in: ; Step (6.3) Construct the current execution input ,as follows: Step (6.3.1) retrieves the result of the previous step. When At that time, set the result of the previous correction to ;when At that time, obtain the corrected execution result generated and verified at the previous execution position. ; Step (6.3.2) combines the current enhanced trajectory element with the result of the previous correction to obtain the current execution input. .

[0091] Step (6.4) is based on the current execution input. The candidate execution results for the current step are generated as follows: Step (6.4.1) will execute the current input. The input reasoning agent generates the current reasoning trajectory according to preset step-by-step reasoning instructions. .in, Indicates the first An intermediate reasoning result, Indicates the number of intermediate inference results; Step (6.4.2) is based on the current execution input. and the current reasoning trajectory Generate candidate execution results for the current step. The candidate execution result can be a service call input, an intermediate text result, or a final text result; the service call input is used to select a service and generate service parameters, the intermediate text result is used to save the current inference state, and the final text result is used to output to the user when the task is completed.

[0092] Step (6.5) performs self-evaluation and internal correction on the candidate execution results to generate the current step's corrected execution result. ,as follows: Step (6.5.1) will execute the current input. Current reasoning trajectory and current candidate execution results Input feedback function to generate reflective feedback The reflective feedback is used to represent the content to be corrected that the reasoning agent identifies itself. Step (6.5.2) generates the current step's corrected execution result based on the current execution input, current inference trajectory, candidate execution results, and reflective feedback, using an improvement operator. .

[0093] Step (6.6) executes the service or generates text based on the corrected execution result, as follows: Step (6.6.1) determines the result type of the correction execution result and performs classification processing, as follows: Step (6.6.1.1) Read the current correction execution result. The result type identifier; Step (6.6.1.2) When the result type is a service call, proceed to step (6.6.2); when the result type is text output, proceed to step (6.6.6). Step (6.6.2) is based on the current execution status. User requirement text Current correction execution results and recommendation service collection The current service is selected by the reasoning execution agent. ; Step (6.6.3) generates a service parameter vector based on the input parameter structure of the currently selected service, the current execution input, and the current correction execution result. .in, This represents the structured information of the current service. This represents the parameter generation function; Step (6.6.4) will convert the service parameter vector Input the execution function of the current service and get the original service output. .in, Indicates the service execution function. The output space belongs to the current service; Step (6.6.5) outputs the original service. By combining the current enhanced execution trajectory input-output parsing function, the next execution state is obtained. ; Step (6.6.6): When the current correction execution result is text output, it is determined as the text execution result corresponding to the current execution position. The text execution result, together with the next enhanced trajectory element, constitutes the input for the next execution position, until the enhanced execution trajectory processing is completed or the final text result is generated.

[0094] Step 7: Perform layered failure verification on the execution process: The qualified verification agent verifies the service selection, parameter generation and output parsing respectively, and generates execution failure information when an execution failure is detected.

[0095] Step seven of this embodiment is as follows: Step (7.1) verifies whether the current service selection is invalid, as follows: Step (7.1.1) Obtain service selection validation input, including user request text. Current execution status Currently selected service Recommended service collection and target state ; Step (7.1.2) inputs the service selection verification into the qualified verification agent to obtain the service selection failure risk. .in, This is used to indicate the risk of selecting the wrong service.

[0096] Step (7.2) verifies whether the current service parameters are invalid, as follows: Step (7.2.1) Perform parameter syntax validation. Based on the current service's input parameter structure, determine the service parameter vector. Check whether the necessary fields are complete, whether the data types are correct, and whether the parameter format meets the input requirements to obtain the parameter syntax validation result. ; Step (7.2.2) performs parameter semantic consistency verification. The service parameter vector... User requirement text Context constraints of the current execution location and current services Input a qualified verification agent to obtain the risk of semantic invalidation of parameters. The verification includes at least entity consistency, value range, context constraints, and parameter conflicts.

[0097] Step (7.3) verifies whether the service output parsing is invalid, as follows: Step (7.3.1) Obtain output parsing and verify input, including the original service output of the current service. The next execution state after parsing And the output field structure of the current service; Step (7.3.2) The qualification verification agent generates a reference state based on the original service output and the output field structure. Alternatively, it can generate the state consistency constraints that the next execution state should satisfy. Step (7.3.3) inputs the original service output and the next execution state into the qualified verification agent to obtain the output parsing failure risk. .

[0098] Step (7.4) generates comprehensive execution failure information, as follows: Step (7.4.1) When any execution failure occurs, generate execution failure information. Each field represents the failure type, failure location, failure score, and the data or constraints that triggered the failure determination. Step (7.4.2) involves assembling relevant information into metacognitive regulatory input. And send it to step eight; If no execution failure is detected in step (7.4.3), the current execution result is submitted and the next enhanced trajectory element is processed.

[0099] Step 8: Generate metacognitive correction schemes based on execution failure information: Input the reasoning and output process that has resulted in execution failure into metacognitive regulatory agents with different decision roles and attribute vectors to generate multiple independent initial correction schemes.

[0100] The process of step eight in this embodiment is as follows: Step (8.1) Construct a set of metacognitive regulatory agents ,as follows: Step (8.1.1) Define the set of agents .in, The proposing agent represents the solution. This represents the logical verification agent. This represents the boundary condition verification agent. This indicates a counter-consensus verification agent; Step (8.1.2) is for each metacognitive agent Configuration Attribute Vector The four components represent logical rigor, prudence, cooperative tendency, and antagonism, respectively. The attribute matrix is ​​composed of these attribute vectors. Furthermore, the attribute vectors are embedded into the corresponding agent's role prompt text to adjust the strategy for generating corrective solutions.

[0101] Step (8.1.3) configures the agent prompting strategy, as follows: Step (8.1.3.1) Configure the scheme proposal agent. Scheme proposal agent Based on the current execution input, current inference trajectory, corrected execution result, and execution failure information, generate candidate correction schemes for the execution failure; Step (8.1.3.2) Configure the logic verification agent. Logic Verification Agent Check the logical connections and contextual consistency between the requirement text, service selection, parameter generation, and output parsing; Step (8.1.3.3) Configure the boundary condition verification agent. Boundary condition verification agent Extract the boundary conditions from the current context constraints and examine the entity references, parameter ranges, and output parsed fields in the service parameters; Step (8.1.3.4) Configure the anti-consensus verification agent. Anti-consensus verification agent Check for any errors that may have been missed in the high-confidence correction scheme, and check whether the high-ranking services in the recommended service set meet the actual execution conditions.

[0102] Step (8.2) Generate the first round of metacognitive correction scheme: respectively input metacognitive regulation into and attribute vector Input the corresponding metacognitive agent to generate the first round of correction scheme. And form the first round of revised schemes. Output to step nine.

[0103] Step 9: Evaluate the metacognitive correction scheme and execute rerouting: Perform scheme evaluation, confidence update and scheme iteration among multiple metacognitive agents. When the consensus condition is met or the upper limit of the iteration round is reached, determine the target correction scheme and trigger the corresponding rerouting action according to the correction type of the target correction scheme.

[0104] The process of step nine in this embodiment is as follows: Step (9.1) Establish communication relationships between metacognitive agents: Define communication relationships .when At that time, metacognitive intelligent agents Metacognitive agents Evaluate the proposed amendments; when At that time, the evaluation will not be performed; Step (9.2) generates evaluation information on the correction scheme among metacognitive agents, as follows: Step (9.2.1) in the first In the evaluation round, metacognitive intelligent agents Targeting metacognitive agents The revised schemes generate general reliability scores respectively. Service ranking reliability score Consistency score of verification conclusion These represent the overall credibility of the solution, the credibility of the service sorting adjustment, and the consistency between the solution and the execution failure information, respectively. Step (9.2.2) is performed according to the preset evaluation weight vector. The three sub-item scores are weighted to obtain the comprehensive evaluation score. ; Step (9.2.3) Metacognitive Intelligent Agent It also generates solutions for the correction. Evaluation feedback text This indicates the content in the evaluated solution that needs to be retained, modified, or deleted.

[0105] Step (9.3) Initialize and update the agent confidence matrix. The process is as follows: Step (9.3.1) Construct the confidence matrix .in, Represents intelligent agents For intelligent agents The confidence level, and ; Step (9.3.2) Generate the intelligent agent For intelligent agents Initial rating probability distribution The process is as follows: Step (9.3.2.1) defines the rating set. Obtain the agent's response to the initial correction plan. Output each score The probability of; Step (9.3.2.2) utilizes temperature parameters The scoring probabilities are normalized. The time score distribution is more concentrated. The score distribution is smoother, thus yielding the initial score probability distribution. ; Step (9.3.3) when Calculate the initial confidence level. The process is as follows: Step (9.3.3.1) Calculate the expected score based on each scoring probability. ; Step (9.3.3.2) transforms the expected rating from the rating interval. Linear mapping to To obtain the initial confidence level ; Step (9.3.4) in the first After each round of evaluation, the confidence level is updated using a pre-set confidence calibration function based on the previous round's confidence level, the current overall evaluation score, and the evaluation feedback. ; Step (9.4) Calculate the overall credibility of each correction scheme in the current round: for the agent In the The correction scheme generated in each round is summarized based on the confidence level and comprehensive evaluation score given by other agents according to their communication relationships: ; in, To prevent the default positive number with a denominator of zero.

[0106] Step (9.5) Based on evaluation feedback Update and fix ,as follows: Step (9.5.1) Metacognitive Intelligent Agent Obtain the evaluation feedback set generated by other agents for their current solution. ; Step (9.5.2) updates the current correction scheme based on the evaluation feedback set and its own attribute vector, resulting in... .

[0107] Step (9.6) performs consensus determination as follows: Step (9.6.1) Determine the scheme with the highest overall credibility from the revised schemes in the current round. ; Step (9.6.2) determines whether the consensus conditions are met. When and At that time, it was determined that a consensus had been reached, and This was determined to be the target modification scheme. Among them, Indicates the minimum confidence threshold. Indicates the minimum leading margin; Step (9.6.3) determines whether the upper limit of the number of iteration rounds has been reached. The process is as follows: Step (9.6.3.1) When consensus is not reached and the current iteration round is less than [number missing], If the time is not met, return to step (9.2) to perform the next round of scheme evaluation; Step (9.6.3.2) When consensus has not been reached but has been achieved Then, proceed to step (9.7) to compare solutions with similar credibility; Step (9.7) performs pairwise comparisons of schemes with similar credibility, as follows: Step (9.7.1) When the combined confidence of at least two corrective schemes reaches the minimum confidence threshold, but the difference between the highest confidence schemes is less than... When that happens, the corresponding solution will be identified as the solution to be compared. Step (9.7.2) performs a double sequential pairwise comparison, as follows: Step (9.7.2.1) involves comparing two schemes. and , respectively construct in front, In the first comparison input after that, and with in front, The second comparison input follows; Step (9.7.2.2) obtains the selection results and selection probabilities corresponding to the two comparison inputs respectively, and combines the results of the two orders to determine the instant comparison result, so as to reduce the influence of the arrangement order; Step (9.8) Calculate the long-term ability score based on the historical comparison results, as follows: Step (9.8.1) Statistical analysis of historical correction schemes Superior to the modified scheme The number of times, recorded as ; Step (9.8.2) involves constructing the Bradley-Terry model, as follows: Step (9.8.2.1) sets a long-term ability score for each metacognitive agent. ; Step (9.8.2.2) will revise the solution. Superior to the modified scheme The probability is expressed as ; Step (9.8.2.3) constructs a log-likelihood target based on the number of historical wins and losses, which is used to estimate the long-term ability score of each metacognitive agent; Step (9.8.3) uses the MM algorithm to iteratively update the long-term ability score. The process continues until the parameter changes satisfy a preset convergence condition. The MM algorithm is an iterative optimization algorithm that maximizes the bound and updates the parameters by repeatedly replacing the original objective function with a function that is easier to solve and is tangent to the original objective function at the current point, until convergence. In this embodiment, a global lower bound is constructed using the first-order tangent of the convex function; Step (9.8.4) is to weight the immediate pairwise comparison results and the long-term capability score to determine the target correction scheme from the correction schemes with similar credibility. Step (9.9) performs different types of result corrections and triggers the corresponding rerouting actions, as follows: Step (9.9.1) Perform text result correction: When the target correction scheme indicates that the text output is incorrect and there is no need to re-recommend or call the service, regenerate the text result and return to step seven for verification; Step (9.9.2) Perform recommended service reordering: When the target correction scheme indicates that the service selection is incorrect, send the candidate service reordering information to the service recommendation module to adjust the order of the recommended service set or regenerate the recommended service set; then return to step (6.2) to update the enhanced execution trajectory, or return to step (6.6.2) to reselect the current service; Step (9.9.3) Perform inference retry or parameter correction: When the target correction scheme indicates that the inference trajectory or service parameter is incorrect, the inference error correction information is sent to the inference execution module to regenerate the current inference trajectory or service parameter vector, and return to step seven to perform the corresponding level of verification; Step (9.9.4) Perform output parsing correction: When the target correction scheme indicates an output parsing error, correct the output parsing constraints or parsing rules according to the target correction scheme, re-parse the original service output, and return to step (7.3) to perform output parsing verification.

[0108] This embodiment compares and analyzes other service recommendation and execution methods, including the following steps: Step 1: Introduction to end-to-end service recommendation and execution methods; The end-to-end service experiment is used to evaluate whether the system can complete the entire process from intent parsing, initial service recommendation, inference orchestration, service invocation to final result generation after receiving user requests.

[0109] The baseline approach used employs GPT-5 as the agent, and the service recommendation methods include: RAG Dense Vector Retrieval: This method uses dense retrieval based on BGE-base-en-v1.5 vector matching to obtain initial recommendation services based on user needs.

[0110] GNN: Uses deep learning graph neural networks to retrieve services that meet your needs from a service set.

[0111] The service execution methods used are divided into four categories: single-agent: a reasoning-action alternation mechanism in which a single agent recommends and executes services.

[0112] Self-consistency: Multi-path generation plus consistent aggregation guides LLM to perform multiple independent inferences on the same problem and uses mechanisms such as "majority voting" to select the most consistent answer.

[0113] Self-refine is a technique that allows large models to autonomously optimize their output through a closed-loop iteration of "generation-feedback-refinement," significantly improving the quality of complex tasks without additional training.

[0114] Multi-Agent Debate: Uses a standard multi-agent discussion mechanism, but does not incorporate the social attributes, confidence matrix, and Bradley-Terry approximate ranking mechanism designed in this paper.

[0115] Ours: This invention presents a complete multi-agent cooperative system. The text encoding model used for optimization in step two of the system is also BGE-base-en-v1.5.

[0116] Step 2: Introduction to the End-to-End Service Recommendation and Execution Dataset; The ToolBench dataset contains 3451 service sets, 16,464 real services, 126K user dialogues, and 469K service call traces, which can be used to verify the recall capabilities of service recommendation modules in a large service space. This dataset has broad coverage and a large service space, making it suitable for evaluating service recall and end-to-end service call capabilities. ToolBench is divided into three generalization test subsets, G1, G2, and G3, based on different task complexity levels. G1 is for single-tool tasks. G2 is for multi-tool tasks of the same category. G3 is for multi-tool tasks of the same set.

[0117] Step 3: End-to-end service recommendation and performance indicators; The end-to-end service recommendation experiment evaluates whether the system, after receiving user requests, can fully complete the entire process from intent parsing, initial service recommendation, inference orchestration, service invocation to final result generation using recommended services. The metrics used are: : The probability of all independent and identically distributed task trials succeeding is calculated and averaged over all tasks.

[0118] Step 4: Evaluate and compare the results.

[0119] Table 1 shows the evaluation and comparison results;

[0120] As shown in Table 1, the complete multi-agent cooperative system proposed in this invention achieves optimal results on all Pass metrics across the three generalization test subsets G1, G2, and G3, indicating that the system has good adaptability to single-service tasks, multi-service tasks of the same category, and multi-service tasks of the same set. Specifically, the method of this invention achieves optimal results on the three subsets. The respective accuracy rates were 66.0%, 66.5%, and 69.0%, which were 3.7, 4.1, and 4.2 percentage points higher than the best-performing comparison method, GNN+Multi-Agent Debate, which had accuracy rates of 62.3%, 62.4%, and 64.8%. They increased by 3.7, 4.2, and 4.5 percentage points respectively. These figures represent increases of 3.8, 4.5, and 4.7 percentage points, respectively. When employing the same execution strategy, the GNN recommendation method consistently outperformed the RAG recommendation method. For example, under the Multi-Agent Debate strategy, GNN outperformed RAG. The performance improved by 6.9, 8.2, and 8.8 percentage points on G1, G2, and G3 respectively, indicating that graph structure modeling of the relationships between services is beneficial to improving the matching quality of candidate services. Meanwhile, under the same recommendation method, the multi-agent discussion mechanism is significantly better than the single-agent mechanism, with GNN+Multi-Agent Debate showing superior performance compared to GNN+single-agent. The scores were increased by 12.7, 14.2, and 14.8 percentage points, respectively. As the number of consecutive successes increased from 1 to 4, the Pass values ​​of each method gradually decreased, consistent with the characteristic that evaluation conditions become more stringent when multiple tasks require success. The method of this invention still maintained a stable leading position, indicating that the introduced social attributes, confidence matrix, and Bradley-Terry approximate ranking mechanism can improve the stability of agent collaborative decision-making and service execution, thus verifying the effectiveness of the end-to-end service recommendation and execution method of this invention.

[0121] Step 5: Introduction to service recommendation and comparison methods.

[0122] MLP: Multilayer perceptron establishes connections for prediction.

[0123] coACN: Enriches descriptive information through domain-level attention units and jointly models demand and service information using collaborative attention convolution.

[0124] LightGCN: It only utilizes historical demand-service call relationships for modeling, without introducing the verb semantic enhancement and implicit supervision loss of this paper, and learns collaborative representations in the interaction graph through linear neighbor aggregation.

[0125] MTFM: Integrates collaborative filtering and content-based technologies to predict and recommend service categories through multi-task learning.

[0126] DySR: Uses dynamic graphs to learn service evolution and aligns requirements with service representations for recommendations.

[0127] PD-WACR: Based on API association graphs, it takes into account popularity, compatibility and diversity.

[0128] FSFM: Integrates API functional semantics with heterogeneous network structure information for recommendation.

[0129] AdaFlow: This method utilizes GNNs to learn service workflow constraints and potential combinatorial patterns. It also uses multiple time slices to learn service evolution relationships, but since the experimental data did not include multiple time slices, this part was removed for testing purposes.

[0130] NFGCL: Enhance collaborative representation through contrastive learning of negative sampling maps.

[0131] SubMCWACR: It satisfies both functional requirements and API compatibility through subgraph matching.

[0132] ours: The method of the service recommendation module proposed in this invention.

[0133] Step 6: Introduction to the service recommendation comparison dataset.

[0134] This invention uses real data from 2019 to 2020 crawled from the ProgrammableWeb dataset to conduct a more in-depth validation of the service recommendation module. This dataset is widely used in service recommendation research and provides comprehensive information on services and call history.

[0135] Step 7: Service Recommendation Comparison Metrics: To evaluate the performance of the service recommendation method, Precision@k (P@k), Recall@k (R@k), Hit Ratio@k (HR@k), and Normalized Discounted Cumulative Gain@k (NDCG@k) are used as evaluation metrics.

[0136] P@k: Represents the proportion of relevant services among the top k recommended services, used to measure the accuracy of the recommendation results; R@k: Represents the proportion of truly relevant services covered by the top k recommended services, used to measure the recall capability of the recommendation results; HR@k: Indicates whether the first k recommendation results contain at least one relevant service, used to measure recommendation hit rate; NDCG@k: In addition to considering the number of related services, its ranking position in the recommendation list is also taken into account. The higher the ranking of a related service, the higher its index value.

[0137] Step 8: Evaluate and compare the results.

[0138] Table 2 shows the evaluation results.

[0139] As shown in Table 2, the service recommendation module proposed in this invention outperforms the listed comparison methods in all twelve evaluation results (P@k, R@k, HR@k, and NDCG@k), indicating that the module can balance the recommendation accuracy, relevant service coverage, hit rate, and ranking quality across several indicators. As the recommendation list length increases from 5 to 20, the P@k of each method decreases, while R@k, HR@k, and NDCG@k generally increase. This change is consistent with the general variation in accuracy and coverage after expanding the candidate range. The P@5, P@10, and P@20 of the method in this invention are 0.40, 0.36, and 0.29, respectively; the corresponding R@k are 0.46, 0.62, and 0.76; HR@k are 0.51, 0.64, and 0.78; and NDCG@k are 0.44, 0.50, and 0.55, respectively. This demonstrates that it can maintain the accuracy of recommendations at the top positions while continuously covering more relevant services after expanding the number of candidates. Compared to the baseline SubMCWACR, which has the best overall performance, the method of this invention improves P, R, HR, and NDCG by 0.01, 0.02, 0.01, and 0.02 respectively at k=5; all four metrics improve by 0.02 at k=10; and by 0.02, 0.02, 0.03, and 0.02 respectively at k=20. Compared to AdaFlow, the method of this invention improves the four metrics by 0.04, 0.06, 0.06, and 0.05 respectively at k=20. Compared to MLP, the improvements are 0.12, 0.21, 0.21, and 0.18 respectively. These results demonstrate that the joint modeling of user demand semantics, service function information, and service association structure in this invention can reduce irrelevant services entering the candidate set and improve the ranking of relevant services, thus verifying the effectiveness of the service recommendation module of this invention on real service call data.

[0140] The embodiments described in this specification are merely examples of implementations of the inventive concept and are for illustrative purposes only. The scope of protection of this invention should not be considered limited to the specific forms stated in these embodiments; rather, it extends to equivalent technical means conceived by those skilled in the art based on the inventive concept.

Claims

1. A cloud-based service recommendation and execution method based on multi-agent and graph convolution, characterized in that, First, semantic enhancement is performed on the service description text, and a text feature extraction model is trained using contrastive learning. Subsequently, a heterogeneous relationship graph is constructed based on the historical call relationships between demands and services, as well as the attribution relationships between services and tags. Service co-occurrence relationships and affinity relationships are integrated to generate an implicit service dependency graph. Then, adjacent service features are aggregated through graph convolution to complete the preference calculation and service recommendation between demands and services. Next, a demand processing agent is used to generate candidate actions and identify early failures. The structured information of the recommended services is written into the execution trajectory, and the inference execution agent gradually generates service call results or text results. Finally, a systematic verification and correction mechanism is constructed through a multi-role metacognitive agent.

2. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 1, characterized in that, The method includes the following steps: Step 1: Parse user requirements and correct early failures: Generate candidate actions based on user requirement text, model internal knowledge, parameterized memory, and historical trajectories; perform early failure detection on the candidate actions; when a candidate action passes the early failure detection, it is determined as the action to be executed; when a candidate action fails the early failure detection, a new candidate action is generated; when the action to be executed belongs to the service call action set, extract the current service requirement text from the action to be executed. Step 2: Construct semantically enhanced samples and train the text feature extraction model: Perform semantic enhancement on the service description text by replacing verbs, construct comparative learning samples based on the service description text before and after enhancement, and use the comparative learning samples to train the text feature extraction model. Step 3: Construct the implicit service dependency graph: Based on the call relationship between historical requirements and registered services, as well as the attribution relationship between registered services and service tags, generate an implicit service dependency graph representing the strength of service collaboration; Step 4: Train the service recommendation model: Enhance the semantic features of services using the implicit dependency graph, calculate the preference scores of historical demands for registered services, and train the service recommendation model based on historical service call records. Step 5, Online Inference Stage: Determine the Recommended Service Set Based on the Current Service Request Text: Receive the current service request text output from Step 1, and determine the top recommended services corresponding to the current service request text from the registered service set. Individual registration service.

3. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 2, characterized in that, The method further includes the following steps: Step 6: Construct an enhanced execution trajectory and gradually generate inference execution results; associate the service information output in Step 5 with the service call actions in the basic historical trajectory, construct an enhanced execution trajectory based on the association results, and complete inference, service call or text output in sequence according to the enhanced execution trajectory; Step 7: Perform layered failure verification on the execution process; the qualified verification agent performs execution verification in service selection, parameter generation and output parsing respectively, and generates execution failure information when execution failure is detected; Step 8: Generate metacognitive correction schemes based on execution failure information: Input the reasoning and output processes that have resulted in execution failures into metacognitive regulatory agents with different decision roles and attribute vectors to generate multiple independent initial correction schemes. Step 9: Evaluate the metacognitive correction scheme and execute rerouting: Perform scheme evaluation, confidence update and scheme iteration among multiple metacognitive agents. When the consensus condition is met or the upper limit of the iteration round is reached, determine the target correction scheme and trigger the corresponding rerouting action according to the correction type of the target correction scheme.

4. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 2 or 3, characterized in that, The process of step one is as follows: Step (1.1) Obtain the input for demand processing and construct the current decision state. ; Step (1.2) Based on the current decision state Generate the current candidate action; Step (1.3) involves performing early failure detection on the current candidate action through an intent failure detection agent. Early failure detection is defined as: when executing the current candidate action... Previously, it was determined whether the current candidate action belonged to the categories of ignored demand, overconfidence, or unproductive loops; Step (1.4) Execute candidate actions based on the early failure discrimination results. Alternatively, rerouting can be performed.

5. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 2 or 3, characterized in that, The process of step two is as follows: Step (2.1) Obtain service semantic training data; Step (2.2) performs verb replacement on the service description text to obtain a new enhanced service description text; Step (2.3) identifies positive samples from the candidate enhanced description text; Step (2.4) Construct a complete contrastive learning sample and training text feature extraction model; The process of step three is as follows: Step (3.1) Obtain service relationship data and construct a heterogeneous relationship graph ; Step (3.2) determines service co-occurrence relationships and service affinity relationships; Step (3.3) generates co-occurrence relationship channel features and affinity relationship channel features respectively; Step (3.4) merges the two types of relationship channels and generates service relationship edge features; Step (3.5) uses the Sigmoid function to generate a service implicit dependency graph; Step (3.6) Calculate the structural constraint loss of the service implicit dependency graph.

6. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 2 or 3, characterized in that, The process of step four is as follows: Step (4.1) Strengthen service characteristics based on service implicit dependency graph; Step (4.2) Generate requirement features Service characteristics ; Step (4.3) for historical requirements and registration services Calculate the inner product of demand-enhancing features and service-enhancing features; Step (4.4) Training the building and service ranking loss calculate; Step (4.5) Calculate the implicit structure supervision loss. ; The process of step five is as follows: Step (5.1) When the action to be executed generated in step one belongs to the service invocation action set. At that time, extract the current service request text from the executed action. ; Step (5.2) Generate semantic features that enhance the current requirements ; Step (5.3) Determine the set of recommended services .

7. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 3, characterized in that, The process of step six is ​​as follows: Step (6.1) Obtain the basic historical trajectory and Recommendation Services and information ; Step (6.2) Constructing the Enhanced Execution Trajectory ; Step (6.3) Construct the current execution input ; Step (6.4) is based on the current execution input. Generate candidate execution results for the current step; Step (6.5) performs self-evaluation and internal correction on the candidate execution results to generate the current step's corrected execution result. ; Step (6.6) Execute the service or generate text based on the modified execution result.

8. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 3, characterized in that, The process of step seven is as follows: Step (7.1) Verify whether the current service selection is invalid; Step (7.2) verifies whether the current service parameters are invalid; Step (7.3) Verify whether the service output parsing is invalid; Step (7.4) generates comprehensive execution failure information.

9. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 3, characterized in that, The process of step eight is as follows: Step (8.1) Construct a set of metacognitive regulatory agents ; Step (8.2) Generate the first round of metacognitive correction scheme: respectively input metacognitive regulation into and attribute vector Input the corresponding metacognitive agent to generate the first round of metacognitive correction scheme.

10. The cloud-based service recommendation and execution method based on multi-agent and graph convolution as described in claim 3, characterized in that, The process of step nine is as follows: Step (9.1) Establish communication relationships between metacognitive agents and define the communication relationship matrix; Step (9.2) Generate evaluation information on metacognitive agent schemes among metacognitive agents; Step (9.3) Initialize and update the agent confidence matrix. ; Step (9.4) targets metacognitive agents. In the The correction scheme generated in each round is based on the confidence level of the current round. and communication relationship Calculate the overall credibility; Step (9.5) Based on evaluation feedback Update and fix ; Step (9.6) Perform consensus determination; Step (9.7) involves pairwise comparisons of schemes with similar credibility. Step (9.8) Calculate the long-term ability score based on the historical comparison results; Step (9.9) performs different types of result corrections and triggers the corresponding rerouting actions.

Images