Model context protocol service scheduling method and system, and storage medium

Abstract

The application relates to the technical field of service scheduling, and particularly discloses a model context protocol service scheduling method and system and a storage medium, the method comprises the following steps: querying the service type of a service scene, acquiring a task execution table of the service type based on pre-acquired authority; comparing the task execution tables of different service types, determining the correlation between the service types, and creating a task link according to the correlation; acquiring the subject information of a user in real time, identifying the subject information, matching the task link, and updating the service process of each service type according to the task link. The application counts the service process of a user, determines different task links, generates a preprocessing instruction in advance when serving a certain user, sends the preprocessing instruction to a subsequent service system, and the subsequent service system normally executes a service task and performs preprocessing work in an idle state. From the perspective of a user, the efficiency of the entire service scene is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of service scheduling technology, specifically a model context protocol service scheduling method, system, and storage medium. Background Technology

[0002] The Model Context Protocol (MCP) is a standardized way for Large Language Models (LLMs) to interact with external data sources and tools. It provides a unified "universal adapter" for AI models, enabling them to securely and flexibly access and manipulate various external resources, breaking down data silos. However, in multi-system scenarios, when the same AI model calls various systems, the amount of data interaction is extremely large, which slightly reduces the response efficiency of each system. How to optimize the scheduling architecture to improve the response efficiency in multi-system scenarios is the technical problem that this invention aims to solve. Summary of the Invention

[0003] The purpose of this invention is to provide a Model Context Protocol (MCP) service scheduling method, system, and storage medium to solve the problems mentioned in the background art.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] A method, system, and storage medium for scheduling Model Context Protocol services, the method comprising:

[0006] Query the service type of the service scenario and obtain the task execution table of the service type based on the pre-acquired permissions;

[0007] Compare the task execution tables of different service types to determine the correlation between service types, and create task links based on the correlation.

[0008] Real-time acquisition of user's main information, identification of the main information, and matching of task links;

[0009] Update the service processes of each service type according to the task chain;

[0010] All service providers and entities collecting subject information use the same model context protocol.

[0011] As a further aspect of the present invention: the step of obtaining the task execution table of the service type based on the pre-acquired permissions in the query service scenario includes:

[0012] Query all service subsystems in the service scenario and treat each service subsystem as a service type;

[0013] For any service type, during the service process, send an information listening request to the user and receive the access permissions granted by the user;

[0014] Based on the obtained permissions, user information containing time tags is retrieved, and feature extraction is performed on the user information to obtain user tags; the time tags are time periods.

[0015] Establish a connection channel with the log module built into the service subsystem to obtain log information;

[0016] User tags are inserted into the log information based on time stamps, serving as the task execution table.

[0017] As a further aspect of the present invention: the step of comparing task execution tables of different service types, determining the correlation between service types, and creating task chains based on the correlation includes:

[0018] Read the task execution table of the service type, quantify the log information, and generate the operation curve of the task execution table; the operation curve is used to characterize the operation volume ratio of the process at each time in the log information, and the operation volume ratio is the normalized operation volume.

[0019] By comparing the computation curves of different service types, the service types are initially classified.

[0020] For the same type of service, query the number of identical user tags in the task execution table, and determine the relevance between service types based on the number.

[0021] A task chain is created based on the aforementioned relevance.

[0022] As a further aspect of the present invention: the step of comparing the operation curves of different service types to perform initial classification of service types includes:

[0023] For any two service types, extract the computation curves within a preset time period and calculate the DTW distance between the computation curves;

[0024] When the DTW distance is less than the preset distance threshold, the two service types are marked as the same type, resulting in a binary service type.

[0025] For binary service types that have overlap, query the relevance of non-overlapping elements, select the minimum relevance value, and when the minimum relevance value is greater than the preset relevance threshold, merge the binary service types to obtain ternary service types;

[0026] For ternary service types that have overlap, a merging process is performed to obtain quaternary service types. This process is repeated until the merging condition is no longer triggered, resulting in an N-ary service type. During the merging process to generate N-ary service types, the relevance threshold varies and is inversely proportional to N.

[0027] The step of creating a task link based on the relevance includes:

[0028] Select the service type in sequence as the initial task;

[0029] Query all N-ary service types that contain the initial task, determine the task combination order among the N-ary service types, and obtain a task link of length N.

[0030] Count all task links corresponding to each service type to obtain a link set indexed by service type.

[0031] As a further aspect of the present invention: the steps of acquiring user subject information in real time, identifying the subject information, and matching the task chain include:

[0032] Receive interaction requests from users and send information to users to obtain permissions;

[0033] Based on the obtained information access permissions, the interaction content and demand information are obtained, the interaction content is identified, and the service type is determined.

[0034] The query service type corresponds to the set of links, which are used as the matched task links.

[0035] As a further aspect of the present invention: the step of updating the service processes of each service type according to the task chain includes:

[0036] For the queried task chains, obtain the second service type in each task chain;

[0037] Send the request information to the service subsystem corresponding to the second service type;

[0038] Open information receiving ports to all service subsystems; when an execution instruction is received from any service subsystem, narrow down the queried task chain.

[0039] Send the request information to the service subsystem corresponding to the next service type;

[0040] The process continues in a loop until no execution instruction is received within a preset time frame.

[0041] The present invention also provides a model context protocol service scheduling system, the system comprising:

[0042] The task table retrieval module is used to query the service type of a service scenario and retrieve the task execution table for the service type based on the pre-acquired permissions.

[0043] The task link creation module is used to compare the task execution tables of different service types, determine the correlation between service types, and create task links based on the correlation.

[0044] The task link matching module is used to acquire the user's main information in real time, identify the main information, and match the task link.

[0045] The service process update module is used to update the service processes of each service type according to the task chain.

[0046] All service providers and entities collecting subject information use the same model context protocol.

[0047] As a further aspect of the present invention: the task table acquisition module includes:

[0048] The service type query unit is used to query all service subsystems in a service scenario, classifying each service subsystem as a service type.

[0049] The permission acquisition unit is used to send information listening requests to users during the service process for any service type and to receive the access permissions granted by users.

[0050] The user tag extraction unit is used to obtain user information containing time tags based on the acquired permissions, extract features from the user information, and obtain user tags; the time tags are time periods.

[0051] The log information acquisition unit is used to establish a connection channel with the log module built into the service subsystem to acquire log information.

[0052] The user tag insertion unit is used to insert user tags into the log information based on the time tag, as a task execution table.

[0053] As a further aspect of the present invention: the task link creation module includes:

[0054] The computation curve generation unit is used to read the task execution table of the service type, quantify the log information, and generate the computation curve of the task execution table; the computation curve is used to characterize the computation volume ratio of the process at each time in the log information, and the computation volume ratio is the normalized computation volume.

[0055] The initial classification unit is used to compare the operation curves of different service types and perform initial classification of the service types.

[0056] The relevance determination unit is used to query the number of identical user tags in the task execution table for the same type of service, and determine the relevance between service types based on the number of tags.

[0057] Create an execution unit for creating a task chain based on the relevance.

[0058] The present invention also provides a storage medium storing a computer program. The computer-readable storage medium stores a computer program, and the computer program is executed by a processor to perform the steps of the Model Context Protocol Service Scheduling Method.

[0059] Compared with the prior art, the beneficial effects of the present invention are:

[0060] This invention is applied to integrated systems with the same Model Context Protocol (MCP). Users receive services at each subsystem. An AI model statistically analyzes the user's service process under the MCP architecture to determine different task chains. When serving a user, preprocessing instructions are generated in advance and sent to subsequent service systems. When executing service tasks, the subsequent service systems perform normal execution. During idle periods, they perform preprocessing work. Although this increases the workload, it is only during idle periods. From the user's perspective, the efficiency of the entire service scenario is greatly improved. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention.

[0062] Figure 1 The overall flowchart of the Model Context Protocol Service Scheduling Method is shown.

[0063] Figure 2 The structure diagram of the Model Context Protocol Service Scheduling System is shown. Detailed Implementation

[0064] To make the technical problems to be solved, the technical solutions, and the beneficial effects of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present invention and are not intended to limit the present invention.

[0065] Figure 1 A flowchart illustrating the overall process of a Model Context Protocol (MCP) service scheduling method, system, and storage medium is provided. In this embodiment of the invention, a MCP service scheduling method is provided, the method comprising:

[0066] Step S100: Query the service type of the service scenario and obtain the task execution table of the service type based on the pre-obtained permissions;

[0067] The service scenario of this invention is a higher-level concept, corresponding to a scenario with multiple services, such as a hospital campus, a smart exhibition hall, and a smart amusement park. These scenarios involve numerous service types and multiple intelligent systems that share the same model context protocol. That is, they interact with the AI ​​agent using the same protocol, which allows the AI ​​to take over all systems and achieve unmanned service needs (in this case, human intervention is mainly for auxiliary review work). Under this architecture, the service type in the service scenario is the system that provides various services. The service process itself is an interaction with the user. When analyzing the user's interaction process, it is first necessary to obtain the user's information, which requires explicit authorization from the user. Generally, when a user enters the service scenario, a unified permission acquisition operation is performed, and in subsequent processes, it is assumed that the user has already granted permissions.

[0068] For each service type, obtain all service information generated within a preset time range. This is itself a time series, called the task execution table. The tasks in the task execution table indicate which users the execution subject of this method provided which services.

[0069] Step S200: Compare the task execution tables of different service types, determine the correlation between service types, and create task links based on the correlation.

[0070] By comparing task execution tables for different service types pairwise, we can determine whether there is a correlation between service types, represented by the correlation parameter. The more related the service types are, the greater the correlation. The practical meaning of correlation is whether a user will immediately perform the next service after performing a certain service. If a large number of users perform service A and then immediately perform service B, then service A and service B are related. Based on the correlation analysis results, we can create some task chains. These task chains represent some consecutive behaviors that users are likely to perform within the service scenario.

[0071] Step S300: Obtain the user's main information in real time, identify the main information, and match the task link;

[0072] Within a service scenario, users will have demand information. They need to interact with the execution entity of this method to indicate what type of service they need. The demand information, combined with the user's personal information, yields the information of which user needs what service. This is called the subject information, which is generally acquired and identified by an AI intelligent assistant. By identifying the subject information, it is possible to determine what type of service the user needs and then match the task chain. At this point, the task chain indicates what operations the user will perform in the next period of time.

[0073] Step S400: Update the service processes of each service type according to the task chain;

[0074] Once the task chain is obtained, the types of services the user may need in the coming period can be determined. At this point, the request information can be sent to these service types in advance to make preparations. When the user arrives at the destination, the system can respond directly. It is conceivable that this process with a very high lead time can greatly optimize the service efficiency of the entire service scenario (from the user's perspective).

[0075] It should be noted that the different service types mentioned above correspond to different subsystems, and user interaction also involves intelligent systems. These systems all use the same Model Context Protocol (MCP) to interface with AI. That is, all service providers and the entities collecting the main information use the same Model Context Protocol. Specifically, in the technical solution of this invention, multiple systems within the service scenario build their interaction links based on a unified Model Context Protocol (MCP). As a standardized model interface protocol, MCP provides a unified data format, context organization structure, permission description model, and asynchronous event mechanism between different service providers (such as hospital systems, exhibition hall systems, and smart park systems) and AI agents. This protocol unifies the following capabilities:

[0076] Unified context encapsulation format: All user events, tasks, statuses, and commands reported by the system are encapsulated as MCP context messages (ContextMessage).

[0077] A unified permission declaration and verification mechanism: any event involving user data carries a PermissionToken, and the AI ​​agent only parses the content while the authorized context is valid.

[0078] Unified Capability Declaration: Each subsystem registers its own service capabilities through MCP, such as "registration service", "explanation and navigation", and "amusement equipment queue numbering", enabling AI to automatically analyze and plan tasks.

[0079] Unified Invocation Chain: A can send MCP instruction messages (InstructionMessage) to any system, which are automatically mapped to atomic operations that can be executed by the subsystem.

[0080] Furthermore, when different systems need to query context data, upstream and downstream systems automatically inherit the context (Context Propagation): when a user switches from one service type to another, there is no need to re-initialize the session. The AI ​​agent automatically tracks the user context based on MCP to achieve continuous service. Through the above mechanism, the core modules such as "task execution table", "task link" and "subject information identification" in the method of this invention are all built on the context management capabilities of MCP, realizing unified scheduling across systems, high concurrency and multiple scenarios.

[0081] Regarding step S100, the step of obtaining the task execution table for the service type based on the pre-acquired permissions for the query service scenario includes:

[0082] Query all service subsystems in the service scenario and treat each service subsystem as a service type;

[0083] For any service type, during the service process, send an information listening request to the user and receive the access permissions granted by the user;

[0084] Based on the obtained permissions, user information containing time tags is retrieved, and feature extraction is performed on the user information to obtain user tags; the time tags are time periods.

[0085] Establish a connection channel with the log module built into the service subsystem to obtain log information;

[0086] User tags are inserted into the log information based on time stamps, serving as the task execution table.

[0087] In one example of the technical solution of this invention, the process of obtaining the task execution table is described. All service subsystems in the service scenario are queried, and each service subsystem is treated as a service type. Based on the obtained permissions, user information containing time tags is obtained. Feature extraction is performed on the user information to obtain user tags. In this process, the types of user information obtained are numerous, such as visual information, behavioral information, or identity information. The user information is extracted and used as a unique tag for the user. The simplest way is to use the numbers and timestamps of the user's previous operations when arriving at the service type's location as the user tag. This method involves almost no personal information of the user. Of course, obtaining other personal information is also feasible. The technical solution of this invention has already received the user's granted access permissions in advance. Furthermore, the time tag is a time period, that is, user information within a certain period is obtained. Since the process of obtaining user information and extracting features is very easy for those skilled in the art with the necessary permissions, it will not be elaborated further here.

[0088] Furthermore, a connection channel is established with the log module built into the service subsystem to obtain log information. User tags are inserted into the log information according to the time stamp, resulting in log information containing user tags, which is called the task execution table. Of course, in practical applications, the log information can be combined. For example, the various log entries in the log information can be grouped and then combined to determine the behavior name corresponding to each group. At this time, the task execution table is simplified into a name table, which is a more intuitive and easier-to-understand data structure.

[0089] It should be noted that, based on the unified structure of the MCP protocol, heterogeneous systems do not need to design their own data reporting interfaces. All service events enter the MCP context stream in the form of context messages. The AI ​​agent can utilize the time-series processing capabilities provided by the protocol to directly aggregate these events into a task execution table. This ensures that task data across service types in this method is inherently consistent, thereby guaranteeing the reliability of subsequent correlation analysis.

[0090] Regarding step S200, the step of comparing the task execution tables of different service types, determining the correlation between service types, and creating a task chain based on the correlation includes:

[0091] Read the task execution table of the service type, quantify the log information, and generate the operation curve of the task execution table; the operation curve is used to characterize the operation volume ratio of the process at each time in the log information, and the operation volume ratio is the normalized operation volume.

[0092] By comparing the computation curves of different service types, the service types are initially classified.

[0093] For the same type of service, query the number of identical user tags in the task execution table, and determine the relevance between service types based on the number.

[0094] A task chain is created based on the aforementioned relevance.

[0095] The above describes the creation process of the task chain. It reads the task execution table for each service type, quantifies the log information, and generates the computation curve of the task execution table. This process simplifies the log curve; for example, the CPU utilization rate at each time point can be used as the computation curve. Since the computation curves need to be compared in subsequent processes, normalization is required during quantization. One feasible solution is to obtain the computation volume of the process at each time point in the log information, calculate the difference between the computation volume and the minimum computation volume in historical data as the first difference, then calculate the difference between the maximum and minimum computation volumes in historical data as the second difference, calculate the ratio of the first and second differences, use the ratio as the computation volume ratio, and statistically fit the computation volume ratio at each time point to obtain the computation curve.

[0096] Given the known computation curves, comparing the computation curves of different service types allows for an initial classification of service types. This provides a simplified service type classification scheme, meaning that service types with the same trigger frequency are more likely to have adjacent relationships, which can greatly simplify the subsequent task chain creation process.

[0097] For service types of the same type after initial classification, query the number of identical user tags in the task execution table, and determine the relevance between service types based on the number. This process is very simple; it simply involves determining whether two service types have served the same user. If so, calculate the number of such users and determine the relevance based on the direct proportion of the number. In practical terms, the more users there are, the higher the relevance. Finally, create a task chain based on the relevance.

[0098] Specifically, the step of comparing the computation curves of different service types to perform initial classification of service types includes:

[0099] For any two service types, extract the computation curves within a preset time period and calculate the DTW distance between the computation curves;

[0100] When the DTW distance is less than the preset distance threshold, the two service types are marked as the same type, resulting in a binary service type.

[0101] For binary service types that have overlap, query the relevance of non-overlapping elements, select the minimum relevance value, and when the minimum relevance value is greater than the preset relevance threshold, merge the binary service types to obtain ternary service types;

[0102] For ternary service types that have overlap, a merging process is performed to obtain quaternary service types. This process is repeated until the merging condition is no longer triggered, resulting in an N-ary service type. During the merging process to generate N-ary service types, the relevance threshold varies and is inversely proportional to N.

[0103] The initial classification process was explained above. First, for any two service types, the computation curves within a preset time period were extracted, and the DTW distance between the curves was calculated. Since there is inherent latency between different service types, using a time-domain matching algorithm to calculate the DTW distance is more in line with reality. When the DTW distance is less than a preset distance threshold, the two service types are marked as belonging to the same category, resulting in binary service types. After processing, all service types are classified pairwise. On this basis, for binary service types with intersection, the relevance of non-intersecting elements is queried. If there is one intersection, the other two are non-intersecting elements with only one relevance. If it is a ternary service type, there may be multiple relevances, which involves a selection process. The minimum relevance value is selected for analysis. When the minimum relevance value is large enough, the binary service types are merged to obtain ternary service types. This process combines matching binary groups into triplets.

[0104] Furthermore, merging triples yields quadruples, merging quadruples yields quintuples, and so on. It should be noted that during the merging process of generating N-ary service types, the relevance threshold varies and is inversely proportional to N. This means that the larger N is, the smaller the relevance threshold becomes when generating more service type combinations, making it easier to satisfy. However, it is not infinitely small; it generally only decreases slightly.

[0105] The step of creating a task link based on the relevance includes:

[0106] Select the service type in sequence as the initial task;

[0107] Query all N-ary service types that contain the initial task, determine the task combination order among the N-ary service types, and obtain a task link of length N.

[0108] Count all task links corresponding to each service type to obtain a link set indexed by service type.

[0109] The process of creating a task link is not complicated. Service types are selected sequentially as initial tasks. That is, a service type is selected as the initial service type of the task link. All N-ary service types that contain the initial task are queried. The task combination order is determined among the N-ary service types. This process is a permutation problem. For example, in a 4-ary service type, after the first service type is determined, there are multiple permutations. Each permutation is a task link, resulting in a task link of length N. After the permutation process is completed, all task links corresponding to each service type are counted to obtain a link set indexed by the service type.

[0110] The above solution is also based on the MCP protocol architecture. Based on the context timeline provided by MCP, the system can directly extract event groups of different service types from the global event stream and determine their order relationship. The correlation between different service types is not based on low-level data comparison, but on reasoning based on the unified event model provided by MCP, thereby accurately reflecting the natural flow path of users when operating across systems. The task links automatically created based on these correlations are also a kind of MCP context link, which can maintain upstream and downstream consistency when making cross-system calls.

[0111] Regarding step S300, the steps of acquiring the user's main information in real time, identifying the main information, and matching the task link include:

[0112] Receive interaction requests from users and send information to users to obtain permissions;

[0113] Based on the obtained information access permissions, the interaction content and demand information are obtained, the interaction content is identified, and the service type is determined.

[0114] The query service type corresponds to the set of links, which are used as the matched task links.

[0115] In one example of the technical solution of this invention, the matching process of the task link is described. Based on the known task link, the interaction request sent by the user is received, the user is sent information to obtain permissions, the interaction content and demand information are obtained based on the obtained information and permissions, the interaction content is identified, and the service type is determined. This process is very simple for the AI ​​agent, since the link set itself is indexed by the service type, the link set corresponding to the service type can be queried as the matched task link.

[0116] In the MCP architecture, the subject information is not a simple user description, but a contextualized object. When this object enters the MCP Context Stream, it is automatically integrated with the user's historical context, permission context, and spatial context, enabling the AI ​​agent to directly perform link matching without additional interfaces. This context-driven service approach ensures that users maintain a continuous experience when using cross-system services.

[0117] Regarding step S400, the step of updating the service process of each service type according to the task chain includes:

[0118] For the queried task chains, obtain the second service type in each task chain;

[0119] Send the request information to the service subsystem corresponding to the second service type;

[0120] Open information receiving ports to all service subsystems; when an execution instruction is received from any service subsystem, narrow down the queried task chain.

[0121] Send the request information to the service subsystem corresponding to the next service type;

[0122] The process continues in a loop until no execution instruction is received within a preset time frame.

[0123] In one example of the technical solution of this invention, the final service process update process is described. For the queried task chain, the first service type is the service type currently required by the user, which has a clear demand signal and therefore does not need to be considered. Starting from the second service type, the demand information is sent to the service subsystem corresponding to the second service type. For binary service types, the second service type is the final service type. For more diverse service types, there may be a third or fourth service type, etc. However, only up to the second service type, the information receiving port for all service subsystems is opened. When an execution instruction is received from any service subsystem, the queried task chain is narrowed down. This process means that only when the user has clearly reached the second service type will the third service type be read, the demand information be sent to the third service type, and so on, continuously executing. When the user no longer appears in the service subsystem corresponding to any service type, the above process stops.

[0124] Since all service systems are interconnected based on MCP, the AI ​​agent can send pre-preparation events to multiple service types simultaneously through a unified command protocol after generating the task chain. When each service system receives these events, it automatically extracts the corresponding user context from the MCP and completes initialization, resource scheduling, and other operations in advance, achieving a highly efficient "service upon arrival" experience.

[0125] Figure 2 A structural diagram of a Model Context Protocol (MCP) service scheduling system is shown. In a preferred embodiment of the technical solution of the present invention, a MCP service scheduling system is also provided, the system 10 comprising:

[0126] The task table acquisition module 11 is used to query the service type of the service scenario and obtain the task execution table of the service type based on the pre-acquired permissions.

[0127] The task link creation module 12 is used to compare the task execution tables of different service types, determine the correlation between service types, and create task links based on the correlation.

[0128] The task link matching module 13 is used to acquire the user's main information in real time, identify the main information, and match the task link.

[0129] Service process update module 14 is used to update the service process of each service type according to the task chain;

[0130] All service providers and entities collecting subject information use the same model context protocol.

[0131] Furthermore, the task table acquisition module 11 includes:

[0132] The service type query unit is used to query all service subsystems in a service scenario, classifying each service subsystem as a service type.

[0133] The permission acquisition unit is used to send information listening requests to users during the service process for any service type and to receive the access permissions granted by users.

[0134] The user tag extraction unit is used to obtain user information containing time tags based on the acquired permissions, extract features from the user information, and obtain user tags; the time tags are time periods.

[0135] The log information acquisition unit is used to establish a connection channel with the log module built into the service subsystem to acquire log information.

[0136] The user tag insertion unit is used to insert user tags into the log information based on the time tag, as a task execution table.

[0137] Specifically, the task link creation module 12 includes:

[0138] The computation curve generation unit is used to read the task execution table of the service type, quantify the log information, and generate the computation curve of the task execution table; the computation curve is used to characterize the computation volume ratio of the process at each time in the log information, and the computation volume ratio is the normalized computation volume.

[0139] The initial classification unit is used to compare the operation curves of different service types and perform initial classification of the service types.

[0140] The relevance determination unit is used to query the number of identical user tags in the task execution table for the same type of service, and determine the relevance between service types based on the number of tags.

[0141] Create an execution unit for creating a task chain based on the relevance.

[0142] Furthermore, the task link matching module 13 includes:

[0143] The request receiving unit is used to receive interactive requests sent by users and send information to users to obtain permissions;

[0144] The content recognition unit is used to obtain interactive content and demand information based on the obtained information access permissions, identify the interactive content, and determine the service type;

[0145] The query unit is used to query the set of links corresponding to the service type, which will be used as the matched task links.

[0146] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A model context protocol service scheduling method, characterized in that, The method includes: Query the service type of the service scenario and obtain the task execution table of the service type based on the pre-acquired permissions; Compare the task execution tables of different service types to determine the correlation between service types, and create task links based on the correlation. Real-time acquisition of user's main information, identification of the main information, and matching of task links; Update the service processes of each service type according to the task chain; All service type providers and subject information collectors use the same model context protocol; The step of comparing task execution tables for different service types, determining the correlation between service types, and creating task chains based on the correlation includes: Read the task execution table of the service type, quantify the log information, and generate the operation curve of the task execution table; the operation curve is used to characterize the operation volume ratio of the process at each time in the log information, and the operation volume ratio is the normalized operation volume. By comparing the computation curves of different service types, the service types are initially classified. For the same type of service, query the number of identical user tags in the task execution table, and determine the relevance between service types based on the number. A task chain is created based on the aforementioned relevance.

2. The model context protocol service scheduling method according to claim 1, characterized in that, The steps for obtaining the task execution table for the service type in the query service scenario, based on pre-acquired permissions, include: Query all service subsystems in the service scenario and treat each service subsystem as a service type; For any service type, during the service process, send an information listening request to the user and receive the access permissions granted by the user; Based on the obtained permissions, user information containing time tags is retrieved, and feature extraction is performed on the user information to obtain user tags; the time tags are time periods. Establish a connection channel with the log module built into the service subsystem to obtain log information; User tags are inserted into the log information based on time stamps, serving as the task execution table.

3. The model context protocol service scheduling method according to claim 1, characterized in that, The step of comparing the computation curves of different service types to perform initial classification of service types includes: For any two service types, extract the computation curves within a preset time period and calculate the DTW distance between the computation curves; When the DTW distance is less than the preset distance threshold, the two service types are marked as the same type, resulting in a binary service type. For binary service types that have overlap, query the relevance of non-overlapping elements, select the minimum relevance value, and when the minimum relevance value is greater than the preset relevance threshold, merge the binary service types to obtain ternary service types; For ternary service types that have overlap, a merging process is performed to obtain quaternary service types. This process is repeated until the merging condition is no longer triggered, resulting in an N-ary service type. During the merging process to generate N-ary service types, the relevance threshold varies and is inversely proportional to N. The step of creating a task link based on the relevance includes: Select the service type in sequence as the initial task; Query all N-ary service types that contain the initial task, determine the task combination order among the N-ary service types, and obtain a task link of length N. Count all task links corresponding to each service type to obtain a link set indexed by service type.

4. The model context protocol service scheduling method according to claim 1, characterized in that, The steps of acquiring user's main information in real time, identifying the main information, and matching the task link include: Receive interaction requests from users and send information to users to obtain permissions; Based on the obtained information access permissions, the interaction content and demand information are obtained, the interaction content is identified, and the service type is determined. The query service type corresponds to the set of links, which are used as the matched task links.

5. The model context protocol service scheduling method according to claim 4, characterized in that, The step of updating the service processes of each service type according to the task chain includes: For the queried task chains, obtain the second service type in each task chain; Send the request information to the service subsystem corresponding to the second service type; Open information receiving ports to all service subsystems; when an execution instruction is received from any service subsystem, narrow down the queried task chain. Send the request information to the service subsystem corresponding to the next service type; The process continues in a loop until no execution instruction is received within a preset time frame.

6. A model context protocol service scheduling system, characterized in that, The system includes: The task table retrieval module is used to query the service type of a service scenario and retrieve the task execution table for the service type based on the pre-acquired permissions. The task link creation module is used to compare the task execution tables of different service types, determine the correlation between service types, and create task links based on the correlation. The task link matching module is used to acquire the user's main information in real time, identify the main information, and match the task link. The service process update module is used to update the service processes of each service type according to the task chain. All service type providers and subject information collectors use the same model context protocol; The task link creation module includes: The computation curve generation unit is used to read the task execution table of the service type, quantify the log information, and generate the computation curve of the task execution table; the computation curve is used to characterize the computation volume ratio of the process at each time in the log information, and the computation volume ratio is the normalized computation volume. The initial classification unit is used to compare the operation curves of different service types and perform initial classification of the service types. The relevance determination unit is used to query the number of identical user tags in the task execution table for the same type of service, and determine the relevance between service types based on the number of tags. Create an execution unit for creating a task chain based on the relevance.

7. The Model Context Protocol Service Scheduling System according to claim 6, characterized in that, The task table acquisition module includes: The service type query unit is used to query all service subsystems in a service scenario, classifying each service subsystem as a service type. The permission acquisition unit is used to send information listening requests to users during the service process for any service type and to receive the access permissions granted by users. The user tag extraction unit is used to obtain user information containing time tags based on the acquired permissions, extract features from the user information, and obtain user tags; the time tags are time periods. The log information acquisition unit is used to establish a connection channel with the log module built into the service subsystem to acquire log information. The user tag insertion unit is used to insert user tags into the log information based on the time tag, as a task execution table.

8. A storage medium, characterized in that, The storage medium stores a computer program, and the computer program stored on the computer-readable storage medium executes the steps of the Model Context Protocol Service Scheduling Method as described in any one of claims 1 to 5 when the processor runs the computer program.

Images