MCP service scenario packaging system and method based on large model agent

Abstract

The invention provides an MCP service scenario packaging system based on a large model agent, and belongs to the crossing field of artificial intelligence and software engineering. The system comprises a file processing module, a static analysis module, a packaging intention generation module, an agent engine module, a deployment verification module and a visualization module. After a user uploads an original code warehouse, a system constructs a packaging intention through structured analysis and a scenario form, a large model agent executes packaging reasoning and tool scheduling under a ReAct architecture, and a deployable service unit conforming to an MCP protocol is automatically generated. A packaging intention structuring mechanism is introduced into the system, service granularity is adaptively divided, a self-repairing closed loop is deployed, and packaging input standardization, execution process intellectualization and packaging result verifiability are achieved. The system is suitable for model service deployment, agent application integration and AI native system construction, and has the advantages of encapsulation automation, verification closed loop, user collaborative optimization and the like.

Description

Technical Field

[0001] This invention relates to the technical field of the intersection of artificial intelligence and software engineering, specifically to a system and method for encapsulating service concepts based on large model intelligent agents using MCP (Model Context Protocol). Background Technology

[0002] With the rapid development of AI-native systems, efficiently encapsulating algorithm models into schedulable, deployable, and composable service units has become a key challenge in intelligent systems engineering. MCP (Model Context Protocol), as a service standard for interaction within large model contexts, is gradually becoming an important foundation for building AI-native applications. Key characteristics of MCP services include: a clearly defined context input structure, semantically bound call logic, clear resource encapsulation boundaries, and robust containerized deployment capabilities. Building such services requires not only accurate parsing of the original code structure but also the completion of interface semantic abstraction, runtime environment construction, and deployment verifiability assurance.

[0003] However, in real-world engineering environments, the encapsulation and deployment of MCP-type services still heavily rely on manual analysis and operation. Developers often need to manually identify service boundaries, write encapsulation scripts and configuration files, which is particularly difficult in code repositories with complex structures, mixed languages, or lacking documentation. This manual approach is not only inefficient and error-prone, but also makes it difficult to guarantee the consistency of encapsulation results and the stability of deployment, severely restricting the large-scale generation and delivery of model services.

[0004] While some CI / CD systems or automation tools currently offer deployment capabilities, most are still based on static templates or rule generation, lacking semantic understanding and adaptive encapsulation capabilities derived from source code with arbitrary structures. In complex project scenarios with heterogeneous code and scattered interfaces, these tools often fall short, requiring significant manual intervention and making it difficult to establish a unified and standardized encapsulation process.

[0005] In recent years, Large Language Models (LLMs) have demonstrated impressive capabilities in code understanding, structural refactoring, and command generation. By introducing an intelligent agent architecture with reasoning and tool scheduling capabilities, models can automatically complete semantic analysis, encapsulation, and deployment verification, showcasing their potential for building automated encapsulation systems. However, existing encapsulation methods based on large model agents, such as interactive programming agents or code generation assistants (e.g., Cursor, Copilot), mostly use natural language prompts as input, relying on users to describe the encapsulation target in free language. In engineering practice, this type of input often suffers from significant ambiguity, poor stability, and insufficient contextual consistency, making it difficult to form standardized and reproducible encapsulation input contexts, thus becoming a key obstacle to the widespread application of intelligent encapsulation.

[0006] For example, the patent application "Meta-application Intelligent Agent Service System Based on AI Technology Microservices" (application number: 202411857619.4) previously submitted by the inventors' team provides a basic framework for the microservice encapsulation, release, containerized operation and maintenance, and application-oriented service composition of AI technology resources, but the solution still has the above-mentioned problems. Summary of the Invention

[0007] To address the aforementioned issues, this invention, building upon the patent application "Meta-application Intelligent Agent Service System Based on AI Technology Microservices," further addresses the engineering implementation needs of MCP (Model Context Protocol) services for large-scale intelligent agents by proposing an MCP service conceptual encapsulation system and method. This system generates standardized and reproducible encapsulation intent inputs through conceptual structured interaction and, combined with an intelligent agent encapsulation execution and deployment verification closed loop, achieves automated delivery of MCP services from source code semantic parsing to encapsulation generation, runtime environment construction, deployment, and verification.

[0008] This invention proposes a novel encapsulation method—"idea-based encapsulation." "Idea-based encapsulation" refers to guiding users to construct service encapsulation targets in a structured manner using non-free natural language through pre-set hierarchical structured configuration forms, encapsulation scenario templates, and an automatic parameter pre-filling mechanism based on user role profiles. It generates standardized and reproducible encapsulation intent input through multiple rounds of configuration verification, replacing encapsulation methods driven by free natural language prompts. The introduction of this mechanism enables the system to construct a stable and consistent encapsulation input context even in scenarios where the encapsulation target is unclear or the user lacks professional expression skills, providing controllable and engineered input conditions for large-scale intelligent agents to perform automated encapsulation.

[0009] The "idea encapsulation" mentioned above refers not only to the input mechanism that expresses the encapsulation target in a structured form, but also includes three aspects: First, it supports optional descriptions of the encapsulation subject, including different roles such as algorithm providers, encapsulation executors, and service users; second, the expression of encapsulation requirements can adopt multimodal natural interaction methods such as text, graphical interfaces, and voice, supporting combined input of functional goals, scenario constraints, and performance requirements; third, the system provides a multi-round iterative optimization mechanism based on consistency verification, performance evaluation, and user feedback after encapsulation. Through the combination of the above three elements, the "idea" forms an encapsulation input context that can be described in a standardized manner, verified and evaluated, and dynamically optimized, providing a standardized semantic foundation for automatic encapsulation reasoning of large model agents.

[0010] Specifically, the present invention adopts the following technical solution:

[0011] This invention provides a conceptual encapsulation system for MCP services based on a large-model intelligent agent. The system comprises: a file processing module for receiving and decompressing a user-uploaded code repository compressed package to obtain project files, and generating a standardized workspace containing the project files; an encapsulation intent generation module for guiding users to define the encapsulation goals and configuration intents of the MCP service through a conceptual structured interactive approach, and generating a standardized encapsulation intent template; a static parsing module for performing syntax parsing and dependency analysis on the project files, and generating a project summary of the project file structure; an intelligent agent engine module for encapsulating the project files based on the encapsulation intent template and the project summary, using an intelligent agent based on a large language model under the ReAct architecture to perform encapsulation inference and tool scheduling, thereby obtaining deployable MCP resources; and a deployment verification module for performing container construction and runtime testing based on the MCP resources to achieve engineering-level verification of the MCP resources. The encapsulation intent generation module includes: an encapsulation form configuration unit, used to provide a multi-round guided structured configuration form for users to input encapsulation configuration information, including encapsulation parameters, operating environment, interface specifications, and dependency constraints, thereby obtaining an encapsulation intent form; a role profile integration unit, used to pre-fill the encapsulation intent form based on the user's historical operation behavior and role profile information; and an intent template generation unit, used to perform consistency verification on the encapsulation intent form after user input, and generate a standardized encapsulation intent template based on the encapsulation intent form after the verification passes.

[0012] The MCP service specification encapsulation system based on large model intelligent agents provided by this invention may also have the following technical features, wherein the file processing module includes: an upload receiving unit, used to receive the code repository compressed package uploaded by the user and perform integrity verification; a decompression unit, used to decompress the code repository compressed package to obtain the project file and generate the directory structure of the project file; and a workspace management unit, used to uniformly manage the file path and dependency relationship of the decompressed project file and generate the standardized workspace.

[0013] The MCP service concept encapsulation system based on large model intelligent agents provided by this invention may also have the following technical features: the multi-round guided structured configuration form includes the following layers: target and scenario layer, capability and usage layer, data and constraint layer, and acceptance and performance layer. Each layer contains multiple configuration items. The configuration items include at least model purpose, service function type, resource exposure strategy, interface behavior expectation, and target deployment environment parameters. One or more of the configuration items are default configuration items. The role profile integration unit pre-fills the default configuration items based on the role profile information. The intent template generation unit performs multi-round consistency checks on the encapsulation intent form after user input. When the check fails, it prompts the user to complete or correct their input in business language according to a preset follow-up strategy. The multi-round consistency checks include: completeness check, logical consistency check, capability consistency check, constraint consistency check, and acceptance executability check. The follow-up strategy includes: first completing the key capability fields that affect the encapsulation path selection, then completing the deployment constraint and network strategy fields, and finally completing the optimization-related fields.

[0014] The MCP service concept encapsulation system based on large model intelligent agents provided by this invention may also have the following technical features: the role profile information is constructed in the following ways: setting role identity when the user registers or the platform authorizes, automatically generating based on the user's usage behavior and history, or the user explicitly selects or switches roles when creating the encapsulation task. The preset role types include: algorithm publisher, model user, middleware operator and application developer. The role profile integration unit adopts a form differentiation strategy for each of the role types, including: dynamic configuration of form item sets, injection of default values ​​for form items, and differentiation of form verification rules and questioning order.

[0015] The MCP service specification encapsulation system based on large model intelligent agents provided by this invention may also have the following technical features, wherein the static parsing module includes: an abstract syntax tree parsing unit, used to parse the class, function and logical structure information in the source code of the project file to obtain the parsing result; a dependency graph construction unit, used to identify and analyze the dependency relationships between multiple functional modules in the source code of the project file and generate a dependency topology graph; and a summary generation unit, used to generate a project summary of the project file structure based on the parsing result and the dependency topology graph.

[0016] The MCP service concept encapsulation system based on a large model agent provided by this invention may also have the following technical features, wherein the agent engine module includes: a large model access unit, used to access a large language model with multi-turn reasoning and code generation capabilities as the agent for encapsulation; a context management unit, used to integrate the encapsulation intent template, the project summary, and the task status through the agent to obtain an encapsulation reasoning context; a tool management unit, used to maintain a set of external tools that can be called, including file editing tools, command-line execution environments, and code analysis tools; an agent decision-making unit, used to plan the encapsulation task based on the reasoning action architecture and to implement the encapsulation task planning and dynamic invocation of the external tools based on the encapsulation reasoning context; and a scheduling control unit, used to coordinate the task execution order and resource allocation of the agent based on the encapsulation task planning, and to monitor the status of the agent's task execution to obtain the task status.

[0017] The MCP service concept encapsulation system based on a large model intelligent agent provided by this invention may also have the following technical features, wherein the deployment verification module includes: a container building unit, used to generate a containerized runtime environment configuration based on the encapsulation intent template, build a corresponding container, and simultaneously build an image based on the service package and deploy the image in the container; a service testing unit, used to perform interface function testing and runtime status verification on the container running the corresponding MCP service based on the encapsulation intent template; and an error handling unit, which records an error log when the service testing unit detects an error and sends it back to the intelligent agent engine module, and the intelligent agent corrects its encapsulation logic and re-deploys according to the error log.

[0018] The MCP service concept encapsulation system based on large model intelligent agents provided by the present invention may also have the following technical features: the system further includes a visualization module, used to realize the real-time display of the running status, task progress and log information of the MCP service concept encapsulation system based on large model intelligent agents.

[0019] The MCP service concept encapsulation system based on large model intelligent agents provided by this invention may also have the following technical features, wherein the visualization module includes: a streaming transmission unit, used to collect and transmit real-time data of encapsulation and deployment in real time during the execution of the file processing module, the encapsulation intent generation module, the static parsing module, the intelligent agent engine module, and the deployment verification module; and a visualization unit, used to generate corresponding visualization data based on the real-time data and a predetermined visualization algorithm, and display the visualization data on the user's front end in a graphical interface.

[0020] This invention provides a method for encapsulating MCP service scenarios based on a large-model intelligent agent, implemented through the aforementioned system. The method comprises the following technical features: a file processing stage, receiving a user-uploaded code repository compressed package, decompressing it to obtain project files, and generating a standardized workspace containing the project files; a static parsing stage, performing syntax parsing and dependency analysis on the project files, and generating a project summary of the project file structure; an encapsulation intent generation stage, guiding the user to define the encapsulation goals and configuration intents of the MCP service through a scenario-based structured interactive approach, and generating a standardized encapsulation intent template; an intelligent agent encapsulation execution stage, based on the encapsulation intent template and the project summary, using an intelligent agent based on a large language model to call appropriate tools to encapsulate the project files, obtaining a deployable service package; and a deployment verification stage, performing container construction and runtime testing based on the service package to achieve engineering-level verification of the service package.

[0021] The role and effect of invention

[0022] The MCP service concept encapsulation system based on a large-model intelligent agent, provided by this invention, includes a file processing module, a static parsing module, an encapsulation intent generation module, an intelligent agent engine module, a deployment verification module, and a visualization module. After a user uploads the original code repository compressed package, the system constructs the encapsulation intent through structured parsing and concept forms. The intelligent agent based on the large language model executes encapsulation inference and tool scheduling under the ReAct architecture, automatically generating deployable service units conforming to the MCP protocol. The system introduces a structured encapsulation intent mechanism, adaptive service granularity partitioning, and a self-healing deployment loop, achieving standardized encapsulation input, intelligent execution process, and verifiable encapsulation results. This system is suitable for model service deployment, intelligent agent application integration, and AI-native system construction, and has advantages such as automated encapsulation, closed-loop verification, and user-coordinated optimization. Attached Figure Description

[0023] Figure 1 This is a schematic diagram illustrating the working principle of the MCP service conceptualization encapsulation system based on a large model intelligent agent in this embodiment of the invention.

[0024] Figure 2 This is a block diagram of the module composition of the MCP service concept encapsulation system based on large model intelligent agents in an embodiment of the present invention;

[0025] Figure 3 This is an execution flowchart of the MCP service concept encapsulation method based on large model intelligent agents in this embodiment of the invention;

[0026] Figure 4 This is a system interaction sequence diagram of the code upload and parsing phase in an embodiment of the present invention;

[0027] Figure 5 This is a system interaction sequence diagram of the service encapsulation stage in an embodiment of the present invention;

[0028] Figure 6 This is a system interaction sequence diagram of the deployment verification and iterative repair phases in an embodiment of the present invention.

[0029] Figure label:

[0030] File processing module 11; Upload and receive unit 111; Decompression unit 112; Workspace management unit 113; Encapsulated intent generation module 12; Encapsulated form configuration unit 121; Role profile integration unit 122; Intent template generation unit 123; Static parsing module 13; Abstract syntax tree parsing unit 131; Dependency graph construction unit 132; Summary generation unit 133; Agent engine module 14; Large model access unit 141; Context management unit 142; Tool management unit 143; Agent decision-making unit 144; Scheduling and control unit 145; Deployment verification module 15; Container construction unit 151; Service testing unit 152; Error handling unit 153; Visualization module 16; Streaming unit 161; Visualization unit 162. Detailed Implementation

[0031] To make the technical means, creative features, objectives and effects of this invention easy to understand, the following describes in detail the MCP service concept encapsulation system and method based on large model intelligent agents.

[0032] Example

[0033] This embodiment provides a model context protocol (MCP) service concept encapsulation system and method based on large model agents. It focuses on the intelligent encapsulation and verification of MCP services from code repositories to deployable units, constructing a collaborative mechanism for the entire encapsulation process for users with different roles. Through a closed-loop operation of structured parsing, concept encapsulation intent generation, knowledge-enhanced reasoning, and containerized verification, the system achieves automated encapsulation and iterative optimization of MCP services, improving the standardization of encapsulation inputs, the intelligence of execution, and the reliability of results. It can be widely applied to model service publishing, agent system construction, and AI engineering deployment scenarios.

[0034] The original code repository includes, but is not limited to, complete algorithm source code, algorithm description scripts, model configuration files, interface (API) definition documents, and papers or patent texts containing algorithm logic descriptions. The code repository can have a multi-language hybrid structure, with available languages ​​such as Python, C++, and Java, and can originate from online open-source resources, research results, or internal enterprise projects. The system can perform unified parsing and dependency modeling on code repositories from different sources and with different structures, thereby achieving cross-language and cross-source encapsulation input compatibility.

[0035] MCP services are designed for building large-scale intelligent agent ecosystems. Essentially, they expose call interfaces to agents in the form of structured capability protocols. MCP services are typically built using Python, preferably the FastMCP framework, but are also compatible with other frameworks that meet the protocol specifications. Unlike traditional REST / RPC microservices, MCP services possess stronger capability abstraction, semantic consistency, and context fusion capabilities. Their encapsulation process not only focuses on code runnability but also on clear capability boundaries, consistent call constraints, and interpretable capability combinations.

[0036] The classification of entities that expose the capabilities of MCP services to the outside world is shown in Table 1 below:

[0037] Table 1. Entity Classification Table of MCP Service Capabilities

[0038] Ability Type Name (in English) describe Common forms Tool capabilities Tool It possesses the ability to execute structured functions by intelligent agents, with input and output field definitions, and can be used for single-row, batch, and streaming processing. Inference functions, conversion modules Resource capabilities Resource Accessible static or semi-static resource units, including models, rules, configurations, dictionaries, knowledge, etc. .bin model files, .json configuration files, and .csv samples Hint ability Prompt Prompt templates for agents organize input into a structured context or control call format. JSON template + Prompt slot definition

[0039] The goal of encapsulation is to encapsulate unstructured, non-standard code, resources, inputs and outputs into MCP service modules that are clearly structured, have verifiable contracts, and are deployable, and can be directly called by downstream intelligent agents.

[0040] Figure 1 This is a schematic diagram illustrating the working principle of the MCP service concept encapsulation system based on a large model intelligent agent in an embodiment of the present invention.

[0041] like Figure 1 As shown, the system first performs code preprocessing on the user-uploaded code repository, completing code structure standardization and dependency extraction, and generating a code repository dependency graph to provide static semantic support for subsequent encapsulation. Then, the user inputs their encapsulation intent through the system's interactive interface. This intent describes the encapsulation goal, deployment environment, and interface requirements in a structured form. The system combines the user's role profile with the platform's existing service knowledge, uniformly embedding and strengthening this knowledge in the knowledge enhancement module, ensuring contextual consistency and semantic interpretability in the subsequent encapsulation reasoning process.

[0042] Multi-source information, after knowledge augmentation processing, is input into the MCP service parsing and publishing agent. This agent uses a built-in large code model as its core inference unit, performing encapsulation parsing, task planning, and code generation based on the augmented context. It also invokes various external auxiliary tools as needed for the encapsulation task, including file editing tools, a bash virtual environment, and other auxiliary tools. During inference execution, the agent can not only use these preset tools but also write its own code to generate new temporary tools, which it can then encapsulate and reuse to complete complex operations.

[0043] After the encapsulation result is generated, the system hands over the generated MCP service to the automatic deployment verification module for containerized building and runtime testing. The verification module initializes, tests, and reports errors to the service execution environment. When a deployment anomaly is detected, it automatically feeds back the logs to the MCP service parsing and publishing agent. The agent then automatically adjusts the encapsulation logic and redeploys based on the error information, forming a self-healing encapsulation verification closed loop.

[0044] Through the above process, this system achieves a fully automated working principle from user encapsulation intent construction and agent encapsulation reasoning to service deployment and verification. The knowledge enhancement module in the system ensures the integrity and consistency of the encapsulation semantics, the MCP service parsing and publishing agent realizes the intelligent generation and tool-based execution of code-level encapsulation logic, and the automatic deployment and verification module realizes the engineering-level verification of the encapsulation results, thus forming a service encapsulation operation mechanism that can be self-iteratively optimized.

[0045] Figure 2 This is a block diagram of the module composition of the MCP service concept encapsulation system based on large model intelligent agents in an embodiment of the present invention.

[0046] like Figure 2 As shown, specifically, the MCP service concept packaging system based on large model intelligent agents in this embodiment includes: a file processing module 11, a packaging intent generation module 12, a static parsing module 13, an intelligent agent engine module 14, a deployment verification module 15, and a visualization module 16. These modules are interconnected through task scheduling and data channels to achieve collaborative operation throughout the entire process from code input to automated packaging and deployment verification of the MCP service. Furthermore, the system provides an interactive interface or can communicate with a user frontend that has an interactive interface. Users upload the compressed package of the code repository to be packaged through the interactive interface, and the system provides users with multi-round guided structured forms through the interactive interface for users to input packaging intent information.

[0047] The file processing module 11 has upload and receive, decompression, and workspace management functions, which enable standardized processing of user-uploaded code repositories. The file processing module 11 includes an upload and receive unit 111, a decompression unit 112, and a workspace management unit 113.

[0048] The upload receiving unit 111 is used to receive the compressed code repository package uploaded by the user and perform integrity verification.

[0049] The decompression unit 112 is used to automatically decompress the uploaded code repository compressed package to obtain the project files and generate the directory structure of the project files.

[0050] The workspace management unit 113 is used to uniformly manage the file paths and dependencies of the decompressed project files, generate standardized workspaces, and provide an input environment for subsequent code parsing and encapsulation.

[0051] The encapsulation intent generation module 12 guides users to define the encapsulation goals and configuration intents of the MCP service through a predefined structured interaction method. The encapsulation intent generation module 12 includes an encapsulation form configuration unit 121, a role profile integration unit 122, and an intent template generation unit 123.

[0052] The encapsulation form configuration unit 121 guides users to define encapsulation targets in a structured form through a pre-defined encapsulation mechanism. It provides a multi-round guided structured configuration form for users to input encapsulation configuration information, including encapsulation parameters, runtime environment, interface specifications and dependency constraints, thereby obtaining the encapsulation intent form.

[0053] The character profile integration unit 122 is used to automatically complete encapsulation parameters based on the user's historical operation behavior and character profile information, thereby enabling personalized encapsulation support for different types of users. The character profile integration unit 122 pre-fills default configuration items in the hierarchical configuration form based on the user's historical operation behavior and character profile information.

[0054] The intent template generation unit 123 is used to perform multiple rounds of consistency verification on the encapsulated intent form after user input, and generate a standardized encapsulated intent template based on the encapsulated intent form after the verification is passed.

[0055] Among them, the "Scenario-based Encapsulation Mechanism" is an engineering-driven encapsulation mechanism for large-scale intelligent agent ecosystems, driven by structured business intents. Its main features include: input is a structured business form, rather than traditional technical configuration; the system automatically derives encapsulation directives to drive the encapsulation agent to generate MCP services; the generated service products have a multi-round verification and feedback closed-loop mechanism, supporting iterative optimization; it supports input from different role perspectives and automatically achieves differentiated encapsulation capability output; "Scenario" refers to a pre-defined scenario, where the system models business goals and behavioral expectations based on role profiles and platform strategies, thereby completing a feasible service encapsulation without requiring users to provide technical details.

[0056] Specifically, the "predefined encapsulation mechanism" proposed in this embodiment aims to transform the traditional encapsulation task, which relies on configuration by technical personnel, into a structured task input process that can be operated by business personnel. The core design idea is to drive the execution of MCP service encapsulation tasks by filling out structured business forms, without requiring users to understand underlying technologies such as MCP, Docker, and FastMCP. The mechanism will be explained in detail below from the following aspects: input design principles, form hierarchy structure, field types and interaction design, multi-round guidance and consistency inquiry mechanism, form-to-instruction field mapping basics, field constraints, and default strategies.

[0057] Regarding input design principles, to improve form filling efficiency, reduce comprehension costs, and control input consistency, the system follows these input design principles: Multi-level structured layering: Task input is divided into four semantic levels, collecting service goals, capability requirements, deployment constraints, and acceptance criteria layer by layer; Differentiated field generation: Based on user role profiles, different sets of form fields and default items are dynamically displayed; Form interaction friendliness: Single-choice and multiple-choice fields are prioritized to collect user intent, and text input is only used when necessary; Mapping operability: Form fields should have clear semantics and can be mapped to structured encapsulated instruction fields.

[0058] Regarding the form hierarchy, a four-level structure is adopted as the whole. The information collected at each level participates in the subsequent encapsulation instruction generation and consistency verification, as shown in Table 2 below.

[0059] Table 2 Form Hierarchy Structure

[0060] level name Description Target and Scene Layer Collect information such as business objectives, expected service models, and domain tags to construct and encapsulate target summaries. Capabilities and Usage Layer The plan should include fields indicating the required input / output types, calling method, batch processing, and interpretability. Data and Constraints Layer Describe the constraints such as compliance requirements, data sensitivity level, deployment location, network access, and log auditing. Acceptance and performance layer Clearly define service deliverability metrics such as acceptance criteria, performance levels, and acceptable failure handling strategies.

[0061] Regarding the design of field types and interaction methods, in order to improve the standardization and business friendliness of structured input, the system adopts specific interaction design strategies for each type of field, as shown in Table 3 below.

[0062] Table 3 Field Types and Interaction Methods

[0063] Field type Data collection method Example illustrate Enumeration type (single choice) radio buttons Data sensitivity level (high / medium / low) One option must be selected to avoid ambiguity. Set type (multiple selections) Multiple selection boxes Required abilities: preprocessing, reasoning, interpretation Supports multiple selections and generates driving capabilities. Hierarchical (cascaded) Drop-down linkage Deployment Environment → Intranet Platform / Public Network Platform / Local Prompt for context consistency Structure input Text box or file upload Sample input / output pairs, acceptance test case scripts Provide unstructured data to assist in reasoning

[0064] Regarding the multi-round guidance and consistency inquiry mechanism, the system supports multi-round form completion guidance, verifying field consistency in real time during form completion, identifying missing information or logical conflicts, and initiating follow-up in business language. Multi-round consistency checks mainly include: Completeness check: checking whether required fields at each level are filled; Logical consistency check: checking whether combinations of fields such as objectives and capabilities, constraints and deployments cause logical conflicts; Capability consistency check: whether capabilities corresponding to business objectives are enabled in the capability layer, for example, if the business objective includes "batch call," whether batch capabilities are enabled in the capability layer; Constraint consistency check: for example, contradictions such as high data sensitivity but network policy set to "allow outbound calls"; Acceptance executability check: checking whether the user has provided an executable acceptance example or whether the system needs to automatically generate an acceptance script. When a check fails, the system prompts the user to complete or correct the input according to a preset inquiry strategy, with the following inquiry priority: first, complete key capability fields affecting the encapsulation path selection (such as whether batch processing or interpretation capabilities are required); then, complete deployment constraint and network policy fields; finally, complete optimization-related fields such as performance requirements and logging policies.

[0065] Regarding the basics of form-to-directive field mapping, a unified mapping mechanism maps multi-level structured form inputs to structured fields in encapsulation directives. The mapping strategy uses a one-to-one correspondence between form field names and directive field names, supplemented by rule-triggered completion logic. Through structured design, the system can automatically construct encapsulated semantics such as RoleContext, BusinessGoalSummary, CapabilityPlan, Constraints, AcceptanceCriteria, and QoSTargets from user input.

[0066] Table 4 below shows the basic mapping relationship between form fields and the main fields of encapsulated instructions. The mapping in Table 4 is only a basic example; the actual encapsulated instruction fields involve more complex combinational logic and completion rules.

[0067] Table 4. Basic Mapping Relationship between Form Fields and Main Fields of Encapsulated Instructions

[0068] Form hierarchy Form field names Instruction structure fields Mapping Description Target and Scene Layer Service name (service_name) BusinessGoalSummary.name Core service identifier representing the encapsulation task Target and Scene Layer Main purpose BusinessGoalSummary.task_type Capability types corresponding to business objectives Capabilities and Usage Layer Input type (input_type) CapabilityPlan.input_format Specify the input data format for the service Capabilities and Usage Layer Whether to perform batch processing (need_batch_processing) CapabilityPlan.stages If so, add "batch" to the stage list. Data and Constraints Layer Compliance level Constraints.compliance Compliance strategy constraints Data and Constraints Layer Network access policy (network_policy) Constraints.network Deploy network access constraints Acceptance and performance layer Performance profile (qos_profile) QoSTargets.profile Performance target level mapping Acceptance and performance layer Sample input / output (example_io) AcceptanceCriteria.examples Used for generating acceptance test scripts later.

[0069] Regarding field constraints and default policies, to improve the automation of encapsulation, the system sets default policies for certain fields. The source of the default policies can be determined by the user profile, historical usage records, or platform policies. Table 5 below provides an example of the default policies for some fields.

[0070] Table 5 Field Constraints and Default Policies

[0071] Fields effect Default policy Data Sensitivity Level Impact on compliance and cyber strategy If no selection is made, the default is "Low". Batch processing? Impact on QoS planning If the business objective is to sign contracts in bulk, then the default is "Yes". Acceptance method Specify acceptance execution logic Default comparison by sample + automatic testing

[0072] The above content constitutes a multi-level structured form design scheme for predefined encapsulation, ensuring the standardization, interpretability, and mapping of business input, and providing a reliable input foundation for subsequent encapsulation instruction generation and automated execution.

[0073] To support personalized business input driving the MCP service encapsulation process, this embodiment introduces a "role profile" mechanism to model the differences among users in terms of business goals, technical preferences, compliance constraints, and deployment habits. The system dynamically adjusts the form field set, default options, capability generation strategies, and follow-up paths based on the role profile, thereby improving the accuracy and usability of automated encapsulation. The following sections will explain this mechanism in detail from several aspects: role types and basic characteristics, role profile field definitions, role-driven form differentiation strategies, role profile construction methods, and role-driven mapping rule systems.

[0074] Regarding role types and basic characteristics, the system pre-defines four typical role types, covering the main participants in the MCP service ecosystem, as shown in Table 6 below.

[0075] Table 6. Preset Typical Role Types

[0076] Character Name Brief description Algorithm publisher Engineers who provide algorithms or models typically focus on operability, template reuse, and deployment efficiency. Model users Researchers using existing models for scientific research or experiments focus on interpretability, semantic clarity, and experimental reproducibility. Mid-platform operators Platform-side operations and maintenance personnel are responsible for batch deployment, unified configuration management, and compliance assurance. Application developers Developers who want to integrate services for business scenarios should focus on the stability of interface contracts and end-to-end performance.

[0077] Regarding the definition of the character profile field, each type of character profile is defined by a set of structured fields, which serve as the input basis for subsequent encapsulation logic and rule adaptation. The field definitions are shown in Table 7 below.

[0078] Table 7 Character Portrait Field Definition Table

[0079] Field Name (English) Description role_type Role type identifiers (such as "model user", "platform maintainer" etc.) domain Category-specific tags (e.g., "finance", "manufacturing", "scientific research") compliance_level Compliance level (high / medium / low) affects the generation of encapsulation constraints. deployment_preference Deployment preferences (local / platform / internal network, etc.) qos_profile Expected performance levels (low / medium / high) audit_requirement Enable audit logging mechanism history_template_preference (optional) Previous preferences for encapsulation templates (influencing template recommendations)

[0080] Regarding the role-driven form differentiation strategy, the system automatically adjusts the visible form fields, default options, and input prompts based on the user's role, achieving customized form structure configuration. For example: for "model users," the system emphasizes input interpretability and retains experimental record fields by default; for "platform maintainers," the system mandates the display of concurrency levels, audit strategies, and rollback strategies; for "application developers," the system highlights interface contracts, output structure stability, and end-to-end use case input fields; and for "algorithm publishers," the system emphasizes model version, domain tags, service type, and code structure simplicity. The implementation mechanism of the form differentiation strategy can include: dynamic configuration of form item sets (field addition and removal); injection of default values ​​for form items; and differentiation of validation rules and questioning order.

[0081] For example, Tables 8 and 9 below show the differences in form tables for several different roles. Tables 8 and 9 illustrate the differences in field visibility, required fields, and default value strategies for different roles.

[0082] Table 8. Comparison of Forms Between Model Users and Platform Operators

[0083] Form hierarchy Field Name Model users Mid-platform operators Target and scenario Task objective description Emphasis on research / reproduction Emphasizing service consistency and batch deployment Capability layer Should experimental records be retained? yes No (Hidden field) Acceptance layer Performance threshold type Runtime (in minutes) Concurrency and P95 Delay (Mandatory) Acceptance layer Acceptance strategy Sample comparison + manual inspection Automatic acceptance + log sampling

[0084] Table 9. Comparison of Forms Between Algorithm Publishers and Those Facing Disasters in the Mid-Levels

[0085] Belonging level Field Name Algorithm publisher Mid-platform operators Target and scenario Service Name Required field; default suggestions will be provided. Required field; default suggestions will be provided. Target and scenario Main uses Display with a wide range of options Display with a wide range of options Capabilities and Usage Batch processing? show Forced display Data and Constraints Compliance Level Default Medium / Low Default High Data and Constraints Network access policy Optional Forced to fill in Acceptance and performance Minimum QoS threshold Not required Required field, set upper limit

[0086] Regarding the construction of character profiles, there are three possible methods: setting character identity during user registration or platform authorization; automatically generating profiles based on user behavior and history; and allowing users to explicitly select or switch characters when creating encapsulated tasks.

[0087] Regarding the role-driven mapping rule system, in addition to the basic one-to-one mapping mentioned above, the system defines a "role-driven rule system" that combines role profiles and domain templates. This system is used to dynamically adjust the content of encapsulated instructions or fill in missing fields. Table 10 below shows examples of several typical mapping rules.

[0088] Table 10 Role-Driven Mapping Rule System

[0089] Rule Number Triggering conditions Encapsulation instruction operation illustrate R1 If your role is a platform maintenance worker and the concurrency level is medium / high, or if you select "Batch Processing = Yes" in the form... Force the addition of "batch" in CapabilityPlan.stages Ensure consistency in batch capacity planning R2 Input types include table / graph structures and the business objective is detection / risk control, etc., or "Preprocessing required = Yes / Uncertain". Add "preprocessing" to CapabilityPlan.stages Forced data preprocessing stage R3 High compliance level and high data sensitivity level Constraints.network is set to block outbound network access, sensitive fields are masked, and audit logs are retained. Add strong constraints R4 Deployment location: Platform / Internal Network Environment Requires generating a Dockerfile and docker-compose, configuring health checks, etc. Forced containerization deployment artifacts R5 The form provides sample inputs / outputs or end-to-end business use cases. Add AcceptanceCriteria.examples to the test task definition. Transform the sample into a verification task. R6 The user selects "Explanation / Evidence Output Required" Add "explanation" to AbilityPlan.stages and require the field to be explained in the AcceptanceCriteria condition. Capability to generate interpreted output R7 The user is a model user and needs to retain reproducible experimental records. Add record metadata output requirements to Constraints Forced recording of experimental logs and parameters R8 The failure strategy should prioritize "automatic repair". Enable feedback loop mechanism and fix limit in Constraints Enable automatic repair and iteration mechanism R9 Domain tag matching preset templates such as "risk control / anti-money laundering" Incorporate domain capability templates into CapabilityPlan and AcceptanceCriteria Load domain predefined capability templates R10 The form field is missing key information (such as concurrency level, input size, etc.). The system triggers follow-up questions to complete the logic. Dynamically complete key fields

[0090] Through the structured role modeling mechanism described above, the system can significantly improve the adaptability of business inputs and the accuracy of encapsulation path prediction.

[0091] The static parsing module 13 achieves a structured understanding of the code repository through syntax parsing and dependency analysis, transforming algorithm code repositories, model projects, or business scripts into structured evidence objects that can be used by encapsulated intelligent agents for reasoning. The static parsing module 13 includes an abstract syntax tree parsing unit 131, a dependency graph construction unit 132, and a summary generation unit 133.

[0092] Abstract syntax tree parsing unit 131 is used to parse and extract class, function and logical structure information from the source code of the project file to obtain the parsing result.

[0093] The dependency graph construction unit 132 is used to identify and analyze the dependency relationships between multiple functional modules in the source code of the project file and generate a dependency topology graph.

[0094] The summary generation unit 133 is used to generate a summary document of the project structure (denoted as project summary) based on the parsing results and analysis results (i.e., the dependency topology graph), providing semantic input for agent reasoning.

[0095] Specifically, the source code parsing process does not rely on the natural language input from the business logic. Instead, it generates structured evidence based on programming language specifications and static code analysis results. This evidence aims to assist the encapsulation agent in capability assessment, refactoring requirement identification, dependency constraint extraction, and test case generation. In this embodiment, a structured static source code parsing mechanism is used to automatically extract candidate capability clues and engineering metadata from the user-submitted code repository, forming a set of source code evidence, referred to as RepoEvidence, used to drive the execution of the encapsulation task. Its data structure is shown in Table 11 below.

[0096] Table 11 RepoEvidence Data Structure Table

[0097] Field Name Data types illustrate project_tree Multi-level structure This represents the directory and file hierarchy of the code repository. language text The project's primary programming language (e.g., Python) dependencies List External dependency information (such as requirements.txt or environment file extraction) entry_points List Candidate entry function, service startup script or module interface candidate_functions List object Functions or classes in the code that can be identified as capability modules configuration_clues List Configure clues (such as YAML, JSON, README document fields). data_resources List object Includes model files, rule base, sample data, etc. docstring_keywords List Document comments highlight keywords related to functional semantics. code_metrics key-value pairs Code metrics (such as complexity, number of lines, etc.)

[0098] The structured fields in Table 11 together constitute the source code capability clue library, which is used by the encapsulated intelligent agent for subsequent capability judgment and reconstruction analysis.

[0099] Furthermore, RepoEvidence not only records code structure but also extracts candidate capability modules based on static analysis rules to assist in generating capability plans. For example, the extraction rules include: function / class naming rules: if the name or comment contains specific keywords (such as preprocess, infer, score, transform, etc.), it is marked as a candidate capability; input / output signature analysis: inferring the input / output format of the capability through function parameter types and return types; code call relationship graph: analyzing code call paths to identify possible capability combinations; document clue matching: if business semantic fields appear in the README, configuration file, or comments, they are used as the basis for capability semantic verification; configuration hints and model paths: automatically completing model resource paths and dependency information based on configuration file fields. These extraction rules can cover capability functions in traditional monolithic services and can also be extended to microservice decomposition and component capability identification.

[0100] The agent engine module 14 is the core execution module of the system. It encapsulates and generates resources and calls tools through a large language model inference framework to obtain deployable MCP resources. The agent engine module 14 includes a large model access unit 141, a context management unit 142, a tool management unit 143, an agent decision-making unit 144, and a scheduling and control unit 145.

[0101] The large model access unit 141 is used to access a large language model with multi-round reasoning and code generation capabilities based on preset agent information, and to serve as an agent for encapsulation.

[0102] The context management unit 142 is used to integrate encapsulated intent, project summary and task status to build an encapsulated reasoning context.

[0103] The tool management unit 143 is used to maintain a set of external tools that can be called, including file editing tools, command-line execution environments (such as bash virtual environments), and other auxiliary tools (such as abstract syntax structure locators such as AST structure locators).

[0104] Specifically, the aforementioned RepoEvidence, together with the EncapsulationDirective generated based on the business form, constitutes the semantic context for the reasoning and execution of the encapsulation agent, used for the following tasks: Capability Exposure Decision: The encapsulation agent determines which capabilities can be directly exposed as Tools or Resources based on candidate_functions, and which capabilities need to be encapsulated or refactored; Input / Output Mapping Verification: Verifies whether the input format declared in the business form is consistent with the actual code capabilities using signatures and documentation comments; Refactoring Task Generation: When a candidate capability does not meet business goals or interface standards, automatically generates a refactoring task (such as extracting a functional module into an independent capability function); Dependency and Environment Configuration Generation: Generates container build dependencies and deployment environment configurations based on dependencies and configuration_clues; Test Case Generation and Verification: Combines example inputs and outputs with the test generator corresponding to candidate_functions to generate smoke test and unit test scripts; Log and Metadata Output Configuration: Sets log collection points, input / output records, and performance metric collection strategies based on parsing clues. Therefore, RepoEvidence not only improves the automation of packaging, but also provides a reliable static evidence basis for subsequent verification closed-loop mechanisms.

[0105] The agent decision-making unit 144 implements encapsulation task planning and dynamic invocation of external toolsets based on the reasoning action (ReAct) architecture and the aforementioned encapsulated reasoning context. Specifically, the agent decision-making unit 144 generates an encapsulation task plan based on a preset prompt word template containing the ReAct process and an encapsulation intent template through a large language model, including the execution order of each encapsulation task and the tools involved in each encapsulation task.

[0106] Furthermore, the agent decision-making unit 144 can automatically generate new temporary tools for reuse based on the needs of the encapsulated task. For example, task requirements, input / output requirements, etc., can be input into a large language model, which can then write code snippets for temporary tools and summarize and encapsulate these code snippets into reusable tools. Through this mechanism, the agent can complete the entire process from understanding code structure and abstracting interfaces to generating deployment configurations without the need for predefined rules, forming a highly adaptive encapsulation execution path.

[0107] The scheduling and control unit 145 is used to plan and coordinate the task execution order and resource allocation of the intelligent agent based on the above-mentioned encapsulation task, and to monitor the status of the intelligent agent in performing the task, so as to ensure the stability and traceability of the encapsulation process.

[0108] Under the control of the scheduling and control unit 145, the large-scale model agent encapsulates the code repository. During the encapsulation process, the encapsulation results are modularly generated according to the MCP service granularity partitioning principle. The MCP service granularity partitioning principle follows the standard of "functional completeness, independent interfaces, and composable invocation," and the interface design balances agent invocation efficiency with cross-domain data security. During the encapsulation inference phase, the large-scale model agent can dynamically adjust the MCP service granularity based on a reinforcement learning model to balance encapsulation reusability and execution performance, and support flexible scheduling and extended deployment in multi-agent collaborative environments. Simultaneously, the scheduling and control unit 145 monitors the status of each agent executing its respective tasks in real time, obtaining status information.

[0109] The deployment verification module 15 performs automated container building and runtime testing based on MCP resources (i.e., the encapsulation results) to achieve engineering-level verification of the encapsulation results. The deployment verification module 15 includes a container building unit 151, a service testing unit 152, and an error handling unit 153.

[0110] The container building unit 151 is used to generate Docker or other containerized runtime environment configurations based on the encapsulation intent template, build the corresponding containers, build the corresponding images based on MCP resources, and deploy the images in the containers.

[0111] Service testing unit 152 is used to perform interface function testing and runtime status verification on containers running corresponding MCP services based on encapsulated intent templates.

[0112] When the service testing unit 152 detects an anomaly, the error handling unit 153 records an error log and sends it back to the intelligent agent engine module 14. The intelligent agent then automatically corrects the encapsulation logic and redeploys the deployment, thus forming an automatic repair verification loop.

[0113] Specifically, to ensure that the encapsulated artifacts of MCP services not only run but also meet business objectives, interface agreements, delivery standards, and performance expectations, this embodiment proposes a four-category feedback closed-loop iterative optimization mechanism for MCP services. This mechanism collects structured feedback during the construction, testing, business intent verification, and performance verification phases, and drives the encapsulation agent to perform automatic repair and optimization operations, thereby improving the success rate of engineering-level encapsulation. The following will explain this mechanism in detail from several aspects: feedback information sources, feedback event structure, feedback-repair action mapping mechanism, automatic repair iteration execution process, and modification of iteration termination conditions.

[0114] Regarding feedback sources, the system collects four types of feedback information at different stages of the encapsulation process. This feedback runs through the entire encapsulation lifecycle and is used to address design flaws, fix functional anomalies, standardize capability interfaces, and optimize performance. The four types of feedback sources include: Build and container runtime log feedback (F1): primarily used to capture structured failure traces during the container build and remote runtime phases, including Dockerfile configuration errors, dependency installation failures, improper environment variable settings, path mounting issues, and runtime crash stacks; Smoke testing and service layer unit testing feedback (F2): used to verify the logical correctness of refactored or newly generated capability modules, ensuring that the function interface behavior is consistent and meets expectations after capability decomposition; MCP intent compliance testing feedback (F3): introducing a dedicated MCP interface testing agent to simulate business agents calling running MCP services along typical business paths, and comparing the call trajectory, parameters, and return results with the encapsulation instructions / acceptance criteria to identify differences in capability loss, behavior inconsistency, or business unavailability; Performance and QoS verification feedback (F4): used to verify whether the encapsulated artifacts meet the user-declared performance thresholds, such as concurrent processing capability P95 latency, throughput, and resource consumption.

[0115] Regarding the feedback event structure, the system has constructed a unified structure called FeedbackEvent for all feedback, which contains the fields shown in Table 12 below. Through this unified structured design, various feedback events can be parsed and the repair action located by the agent's inference module.

[0116] Table 12 Feedback Event Structure Fields Table

[0117] Field Name Field Description source_type Feedback source type (F1 / F2 / F3 / F4) stage Feedback collection phase (e.g., building, testing, intent validation, performance verification) evidence Fragments of evidence of failure (such as log fragments, stack traces, call logs, etc.) failing_case Description of the failed test cases or triggering conditions diff_to_acceptance Set of differences between the acceptance criteria and the acceptance criteria suggested_fix_scope It is recommended to fix the scope of actions (such as Dockerfile modifications, missing capability additions, etc.). iteration_id Current iteration number and context-related label

[0118] Regarding the feedback-repair action mapping mechanism, to achieve efficient automatic repair, the system defines a feedback type-repair action mapping table (ActionMap). This mapping table associates common failure types with corresponding repair strategies, allowing the agent to directly trigger the repair process based on feedback. The repair actions defined in ActionMap include both logical operations such as code refactoring, Dockerfile configuration correction, and capability module completion, as well as the execution of performance optimization strategies. Table 13 below shows some mapping examples.

[0119] Table 13 Mapping Table of Feedback Types and Repair Actions

[0120] Feedback event types Typical failure symptoms Example of core evidence Recommended repair actions F1 (Build / Run) Dockerfile syntax error, missing dependencies Build log error codes and stack traces Dockerfile fixes, dependency completion, and path corrections F2 (Smoke / Single Test) Function interface behavior does not match expectations Test assertion failed, output structure error Correct function signature and output structure alignment F3 (Intentional Mismatch) Lack of ability or behavior deviating from the business path Missing field returned in return value; call failed. Extract missing capabilities, complete capability registration, and adjust interface contracts. F4 (Performance not up to standard) Throughput / latency / concurrency performance not meeting standards Performance benchmark test results Batch processing strategy, cache optimization, concurrency parameter tuning

[0121] Regarding the automatic repair iteration execution process, the encapsulated agent performs automatic repair and iterative optimization according to the following process after each round of feedback events: parse the differences and failure evidence in the FeedbackEvent; identify the corresponding set of repair actions based on the ActionMap; execute the repair actions, including Dockerfile / Compose repair, code logic adjustment, capability extraction or completion, test script generation repair, etc.; trigger the rebuild and verification process; collect a new round of feedback (F1 / F2 / F3 / F4); repeat the above steps until the termination condition is met.

[0122] Regarding the modification of the iteration termination condition, automatic iteration repair will stop when any of the following conditions are met: all enabled verification items pass verification, including build, smoke test, intent compliance, and performance benchmark test; the preset iteration limit is reached; the resource budget or security policy limit is reached; or a logical conflict that cannot be automatically repaired occurs, requiring manual intervention.

[0123] Furthermore, for the aforementioned feedback event type F3, the agent engine module 14 also integrates a large model as an intent testing agent, specifically for intent compliance testing, to ensure that the encapsulated product truly meets the calling intent and business path requirements of the business agent. The intent testing agent takes structured encapsulated instructions and service runtime information as input, and verifies whether the capability exposure, calling path, and return behavior of the MCP service are consistent with business expectations by simulating real-world calling scenarios.

[0124] The testing objective of the intent testing agent is to verify whether the running MCP service possesses the following characteristics: service capabilities conform to the plans and constraints defined in the encapsulation instructions; the service correctly responds to all capability nodes called on the main business path; the structure, fields, and semantics of the returned results meet the acceptance criteria; and the service exhibits no uncaught errors or behavioral anomalies during intent testing. The inputs to the intent testing agent include encapsulation instructions (containing business objectives, capability plans, constraints, verification criteria, and performance targets), running service access information (containing service address, capability registration list, and capability call specifications), and typical domain business call paths (containing predefined or user-specified standard business call sequences).

[0125] The intent testing agent automatically generates a call plan from the encapsulated instructions, following these steps during execution: parsing the encapsulated instructions and typical business paths in the domain; converting each call node into a specific service request, including path parameters, input structure, and value domain; initiating actual HTTP or RPC calls to the corresponding capability interface of the MCP service; recording the call trajectory, return result, latency, and status of each request; comparing the returned data structure and results with the acceptance criteria defined in the encapsulated instructions; summarizing differences and failures, and generating a structured difference report. This difference report can be used as a feedback loop (F3) event to be fed back to the encapsulated agent to drive automatic repair actions. Table 14 below shows the fields of the difference report.

[0126] Table 14 Differentiation Report Fields

[0127] Field Name Field Description missing_capability List the capabilities that are expected by the business but not yet exposed. mismatch_behavior List of descriptions of abilities and behaviors that do not match expectations business_unusable_reason Statement of the main reasons for service unavailability recommendations Suggested repair directions or filler strategies call_trace Actual call trajectory and return result record related_acceptance_criteria Mapping to unmet acceptance criteria

[0128] The DiffReport and FeedbackEvent (source_type=F3) output by the intent test agent will serve as the main inputs to the encapsulated agent, driving the following automatic repair process: generating a missing capability completion task based on missing_capability; adjusting the capability plan or output format based on mismatch_behavior; correcting the input format conversion or invocation strategy based on business_unusable_reason; supplementing unmet acceptance criteria based on related_acceptance_criteria; and triggering redeployment and testing after the repair is performed.

[0129] Furthermore, during the feedback loop verification process, the new version of RepoEvidence is compared with the feedback information to determine whether the capability clue set needs to be re-parsed, supplemented, or expanded. For example, if the feedback event indicates "capability missing," the encapsulation agent will rescan the code to find potentially missing capability modules; if performance feedback requires refactoring the batch processing logic, the parsing module will analyze the inference function call path to support the generation of batch encapsulation tasks; if the intent compliance test report indicates that the output structure does not meet business requirements, the parsing module will extract more document clues to assist in refactoring. Through the above iterative mechanism, RepoEvidence is continuously improved, supporting capability iteration and feedback optimization throughout the encapsulation process.

[0130] The visualization module 16 is used to display the system's operating status, task progress, and log information in real time. The visualization module 16 includes a streaming unit 161 and a visualization unit 162.

[0131] The streaming unit 161 is used to collect and transmit real-time data of encapsulation and deployment during the execution of the above modules.

[0132] The visualization unit 162 is used to generate corresponding visualization data based on real-time data and a predetermined visualization algorithm, and to display the visualization data in a graphical interface on the user front end, including parsing status, packaging progress, deployment results and exception information, etc. In other words, the information is synchronized to the user interface in real time through a streaming push mechanism, thereby realizing the observability and interactive feedback of the entire automated packaging process.

[0133] Through the coordinated operation of the above modules, the MCP service concept packaging system based on large model agents of the present invention can realize the fully automated processing from parsing the code repository compressed package, constructing the packaging intent, agent-driven packaging to automatic deployment and verification, ensuring the high precision, reusability and verifiability of the packaging task.

[0134] In this embodiment, the output of the MCP conceptual packaging system includes not only the core code of the MCP service, but also multiple dimensions such as capability registration, build configuration, deployment files, verification data, and metadata, as shown in Table 15 below:

[0135] Table 15 Composition of Packaged Products for the MCP Conceptual Packaging System

[0136] Composition of packaged products Content Description Service main code The service implementation is based on FastMCP and includes the registration and scheduling logic for Tools / Resources / Prompts. Container build files Dockerfile, docker-compose.yml, and required entrypoint scripts Deployment Configuration Environment variables, ports, resource constraints, health checks, and restart policies Verification and acceptance of products Test cases, smoke scripts, QoS benchmark test reports, acceptance logs, etc. Encapsulated metadata Encapsulate process logs, instruction structure (EncapsulationDirective), role context, and source code analysis results (RepoEvidence).

[0137] By combining the multi-layered products shown in Table 3, the encapsulation process can be reproduced, the encapsulated content can be verified, the encapsulation target can be deployed, and the encapsulation capabilities can be connected, thus realizing a complete engineering closed loop from "intent input" to "runnable service".

[0138] Figure 3This is an execution flowchart of the MCP service concept encapsulation method based on large model intelligent agents in an embodiment of the present invention.

[0139] like Figure 3 As shown, based on the above-mentioned MCP service conceptual encapsulation system based on large model intelligent agents, the corresponding method can include the following stages (steps): file processing stage S1, static parsing stage S2, closed intent construction stage S3, intelligent agent encapsulation execution stage S4, deployment verification stage S5, and visualization feedback stage S6. Each stage is connected in sequence and forms a complete automated execution link through data channels and task status transmission, realizing end-to-end encapsulation and verification from the original code repository to the deployable MCP service.

[0140] Specifically, firstly, the user uploads a compressed code repository package through an interactive interface and inputs encapsulation configuration information through a multi-round interactive configuration form. In the file processing stage S1, the upload receiving unit 111 of the file processing module 11 receives the compressed code repository package uploaded by the user. Then, the decompression unit 112 decompresses the compressed code repository package to obtain source code files, standardizes their path organization, and uniformly transfers the decompressed and path-standardized source code files to the system's preset workspace directory. The workspace management unit 113 establishes a unified directory index and dependency record for these source code files, providing a consistent input basis for the subsequent parsing module.

[0141] The process then proceeds to the static parsing phase S2. In this phase, the abstract syntax tree parsing unit 131 of the static parsing module 13 performs structural analysis on the source code file, extracting the dependencies between classes, functions, and modules. The dependency graph construction unit 132 parses the source code file based on the extracted information and generates a project dependency topology. The summary generation unit 133 generates a summary document at the "module-dependency-function" level based on the parsing results (i.e., the project dependency topology), serving as the semantic basis for encapsulating the input and providing structured contextual support for large model agents.

[0142] Then, in the encapsulation intent construction phase S3, the encapsulation form configuration unit 121 of the encapsulation intent generation module 12 guides the user to define the encapsulation target in a structured form based on the pre-defined encapsulation mechanism. It provides a configuration form containing hierarchical configuration items for the user to input encapsulation configuration parameters based on the user role, service type, and deployment target. The role profile integration unit 122 automatically completes some missing parameters in the configuration form based on historical user operation behavior and role profile information. The intent template generation unit 123 generates an encapsulation intent template based on the completed encapsulation intent form, which, together with the summary document generated in the static parsing phase S2, serves as the context input for agent reasoning.

[0143] Subsequently, in the agent encapsulation execution phase S4, the large model access unit 141 of the agent engine module 14 loads a large language model with multi-turn reasoning capabilities as the agent. The context management unit 142 integrates the encapsulated intent template, item summary, and task state to form semantic input (i.e., encapsulated reasoning context). Then, under the scheduling of the agent decision unit 144 and the control of the scheduling control unit 145, the agent, according to the encapsulation task plan, calls corresponding external tools (including file editors, command-line execution environments, and AST structure locators) through the tool management unit 143 to perform interface partitioning, logic reconstruction, and configuration generation on the source code. If necessary, the agent can generate temporary tools according to task requirements to expand its own tool library and achieve the execution of more complex tasks. Finally, the agent generates a service directory structure and container deployment configuration file conforming to the MCP protocol specification, which are then processed by the deployment verification module 15.

[0144] Then, in the deployment verification phase S5, the container building unit 151 of the deployment verification module 15 performs image generation and deployment operations, and the service testing unit 152 completes the runtime status detection and health check. When deployment fails, the error handling unit 153 captures the error log and feeds it back to the intelligent agent engine module 14. After parsing the error information, the intelligent agent re-plans the encapsulation logic, performs automatic repair and re-encapsulation, forming a closed-loop operation path of "encapsulation-verification-repair-retry", ensuring the stability and operability of the encapsulation result.

[0145] In other words, during the agent encapsulation execution phase S4 and the deployment verification phase S5, the large-model agent not only performs semantic understanding and code generation based on the encapsulated intent template and structured summary documents, but also utilizes a reinforcement learning model to dynamically optimize the encapsulation granularity and interface definition. The system adaptively adjusts the agent encapsulation strategy by evaluating metrics such as the functional coverage, execution efficiency, and deployment success rate of the encapsulation results.

[0146] Once the encapsulation result passes deployment verification, the system can generate an encapsulation report and metadata records, and conduct authorization negotiation and registration with the copyright or algorithm provider of the original code repository to ensure the legal use and traceability management of the encapsulation results.

[0147] In the visualization feedback phase S6, the streaming transmission unit 161 of the visualization module 16 outputs the execution status, running logs, and deployment results of each of the above phases in real time. The visualization unit 162 displays this information graphically on the interactive interface, enabling users to monitor the encapsulation progress and execution status in real time, achieving transparency and observability throughout the entire process. Understandably, the visualization feedback phase S6 is also continuously executed synchronously during the execution of each of the above phases.

[0148] Through the steps described above, the method in this embodiment achieves fully automated execution across the entire chain, from source code input, semantic parsing, encapsulation generation to deployment verification and result feedback. The system leverages the semantic understanding and reasoning capabilities of a large language model to complete the encapsulation target modeling and code refactoring, and ensures the engineering usability and adaptive repair capabilities of the encapsulated product through a deployment verification closed-loop mechanism, significantly improving the intelligence and stability of the MCP service encapsulation.

[0149] Figure 4 This is a system interaction timing diagram of the file processing stage and the static parsing stage in this embodiment.

[0150] Figure 4 This diagram illustrates the interaction between the user front-end, file processing module 11, static parsing module 13, encapsulation intent generation module 12, intelligent agent engine module 14, deployment verification module 15, and visualization module 16 during the code upload and parsing phases. The sequence diagram demonstrates the task triggering chain, data transmission path, and information synchronization logic of the file processing phase S1 and the static parsing phase S2 (these two phases can be referred to as the encapsulation preparation phases), serving as the input foundation for subsequent encapsulation inference and deployment verification.

[0151] During the encapsulation preparation phase, the user frontend first initiates an upload request for the code repository compressed package. The file processing module 11 receives the uploaded code repository compressed package and performs a decompression operation, transferring the decompressed project files to the system's preset workspace directory (WORKSPACE). Project indexes and dependency path information are then generated in the workspace management unit 113. The file processing module 11 then passes the workspace path to the static parsing module 13, triggering the execution of the parsing task.

[0152] After receiving the workspace path, the static parsing module 13 sequentially performs the following steps: Abstract Syntax Tree (AST) construction, module dependency extraction, and summary document generation. The AST parsing unit 131 models the syntactic structure of the source code files in the project, extracting the semantic relationships between classes, functions, and modules. The dependency graph construction unit 132 generates a module dependency topology graph based on the extraction results, forming a complete structural relationship model. The summary generation unit 133 then generates a structured summary document based on the dependency topology graph and structural information, providing semantic input that can be understood by the large model for subsequent encapsulation. After parsing is complete, the static parsing module 13 inputs the parsing results and the summary document to the encapsulation intent generation module 12 and the user frontend.

[0153] In this phase, the intelligent agent engine module 14 and the deployment verification module 15 have not yet participated in the interaction and are only in a standby state. The visualization module 16 monitors the status changes of the file processing and static parsing process in real time, and outputs the parsing progress, log information and stage results to the interactive interface in a streaming manner, realizing real-time observability of the process and feedback on the execution status.

[0154] Through the above interaction process, the encapsulation preparation stage completes the input preparation work from user code upload to generating structured semantic summaries, establishes the unified semantic context and input data foundation required for encapsulation execution, and provides complete preconditions for the reasoning execution of the agent encapsulation stage.

[0155] Figure 5 This is a system interaction sequence diagram for the service encapsulation phase in this embodiment.

[0156] Figure 5 The diagram illustrates the interaction between the static parsing module 13, the encapsulation intent generation module 12, the agent engine module 14, and the visualization module 16 in the encapsulation intent construction phase S3 and the agent encapsulation execution phase S4 (these two phases can be referred to as the service encapsulation phases). This is the core phase of the key mechanism for realizing "idea encapsulation based on large model agents" in the method of this embodiment.

[0157] After the file upload and parsing in the previous stage are completed, the system has generated a structured summary document and dependency topology diagram of the project files. At the same time, the encapsulation intent generation module 12 has formed a standardized concept encapsulation intent. This stage uses this as input to start the agent encapsulation execution chain.

[0158] First, the static parsing module 13 and the encapsulation intent generation module 12 respectively provide the parsed summary document, dependency topology graph, and generated concept encapsulation intent template to the agent engine module 14. After receiving these inputs, the agent engine module 14 initializes the large language model and activates its ReAct inference architecture, entering the task execution state.

[0159] Subsequently, the agent engine module 14 concatenates the encapsulation intent template with the project summary to form a complete encapsulation inference context, establishing an encapsulation context with both structured and semantic constraints. Based on this context, the agent autonomously selects and invokes the external tools required for encapsulation (including code editors, abstract syntax structure locators, command execution environments, and dependency management scripts, etc.) to perform encapsulation operations such as functional understanding, module division, logic correction, and interface abstraction on the source code in the project file.

[0160] During the encapsulation inference execution process, the agent engine module 14 dynamically generates or reuses tools based on the inference results to automate code understanding and rewriting tasks. This mechanism enables the agent to have self-expansion and self-learning capabilities, allowing it to complete complex encapsulation tasks without fixed templates.

[0161] After the encapsulation process is complete, the agent generates resource definitions and container configuration files conforming to the MCP protocol specification based on the execution results, forming a deployable MCP service unit. The encapsulation result will be output to the deployment verification module 15 through the data channel, ready to enter the subsequent deployment verification and iterative repair phase.

[0162] Meanwhile, during the above process, the visualization module 16 monitors the status changes of the intelligent agent engine module 14 in real time, and synchronizes the encapsulation progress, tool call status and generation results to the user interface through a streaming push mechanism, so that the user can observe the encapsulation execution process in real time and grasp the task progress and status feedback of the encapsulation stage.

[0163] Through the above interactions, this stage achieves automation and intelligence in the encapsulation process. The intelligent agent engine module 14, under the ReAct architecture, completes the entire process from encapsulation intent parsing, context fusion, code understanding, tool scheduling to deployment configuration generation, forming a unified execution path for system semantic reasoning and engineering encapsulation. This is a key technical stage in the method of this embodiment for achieving end-to-end intelligent encapsulation.

[0164] Figure 6 This is a system interaction sequence diagram for the deployment verification and iterative repair phases in this embodiment.

[0165] Figure 6 The interaction logic between the deployment verification module 15 and the intelligent agent engine module 14 in the deployment verification phase S5 and the visualization feedback phase S6 (these two phases can be referred to as the deployment verification and iterative repair phases) is shown, demonstrating the system's adaptive repair and closed-loop control mechanism after automated encapsulation. This phase is a key link in the method of this embodiment to realize the integrated operation path of "encapsulation-deployment-verification-repair-retry".

[0166] After the service encapsulation phase is completed, the intelligent agent engine module 14 passes the generated container configuration file and service code to the deployment verification module 15. The deployment verification module 15 then initiates image building and containerized deployment operations accordingly. The deployment verification module 15 generates a runtime image, deploys the container, and executes service startup, port listening, and health check tasks to verify the runnability of the encapsulated artifacts. Simultaneously, the visualization module 16 intervenes, outputting deployment status, logs, and runtime information to the user interface in real time to ensure the observability of the deployment process.

[0167] When the deployment verification module 15 detects a runtime anomaly (such as container build failure, missing dependencies, service startup anomaly, or interface response anomaly), the system immediately triggers an error log feedback mechanism. The deployment verification module 15 feeds back the error log and anomaly type to the intelligent agent engine module 14 as input for replanning the encapsulation strategy. After receiving the error information, the intelligent agent engine module 14 automatically analyzes the cause of failure based on the error context, calls the large language model to re-infer and generate a repair solution, and performs code correction, configuration adjustment, and dependency completion operations to form a corrected encapsulation solution.

[0168] After the repair is completed, the intelligent agent engine module 14 retransmits the updated service code and configuration file to the deployment verification module 15, initiating a new round of deployment. The deployment verification module 15 re-executes image building, container deployment, and health checks, and synchronizes the new execution results to the visualization module 16. If the deployment verification is successful, the system marks the corresponding service status as "deployment successful" and outputs a runnable MCP service unit; if an anomaly is still detected, the above "error feedback - repair - retry" process is repeated until the deployment is successful or the system's preset retry limit is reached.

[0169] Throughout the closed-loop process, the visualization module 16 maintains real-time communication with the intelligent agent engine module 14 and the deployment verification module 15, and displays the deployment progress, error logs and repair results in a streaming manner through the user interface, ensuring that users can perceive the system's automatic repair behavior and final execution results throughout the process.

[0170] Through the above interactions, this stage implements an autonomous repair mechanism for the encapsulated results after deployment verification failure, constructing a cyclical execution chain from error detection, anomaly feedback, model inference repair to redeployment verification. This mechanism enables the system to possess high reliability and adaptability in complex engineering environments, significantly improving the deployment success rate and operational stability of the encapsulated products. This is one of the core innovations that distinguishes the system and method of this embodiment from traditional automated encapsulation tools.

[0171] In one example, the above system and method are applied to the encapsulation of an anti-money laundering monitoring service for cross-border trade payment supervision. In this scenario, the user role is a middleware operator, and the business goal is to build an anti-money laundering monitoring MCP service that supports automatic invocation by the regulatory intelligent agent. This service needs to preprocess graph-structured transaction data, perform batch inference, and output interpretable results, while meeting high compliance requirements, intranet deployment restrictions, and high concurrency performance requirements. The user fills in the business objectives and service forms at the goal and scenario layer of a multi-level structured form, specifies the required preprocessing, batch inference, and interpretation capabilities at the capability layer, declares high data sensitivity at the constraint layer, prohibits data from leaving the network, and enables audit logs, and sets sample inputs and outputs, acceptance methods, and high-performance level requirements at the acceptance layer. The system generates encapsulation instructions based on the filled-in content. These instructions clarify the business objective summary, capability plan, constraints, and performance indicators, and extract candidate entry points and candidate capability functions based on the RepoEvidence generated by static parsing. During the initial deployment and verification of the packaged artifacts, feedback from the system during the build and unit testing phases indicated a lack of batch processing and preprocessing capabilities. Intent compliance testing revealed that the service only supported single calls and did not correctly expose graph construction logic, and performance testing failed to meet high concurrency requirements. Based on this feedback, the system automatically generated remediation tasks, including supplementing batch processing packaging logic, extracting preprocessing modules, adjusting capability registration configurations, and generating test scripts, and then automatically redeploying. After several rounds of iterative remediation, the final generated MCP service met the requirements for preprocessing, batch inference, interpretation output, and audit logs, and passed all build, testing, intent compliance, and performance verifications, generating a complete containerized artifact and verification report.

[0172] In another example, the system and method of this embodiment are applied to the encapsulation of the AI4Science eutectic structure prediction service. In this scenario, the user is a model user who wants to encapsulate a scientific research model into an MCP service to support data prediction and experimental record reproduction in the laboratory. The user describes the business objective in the form as "generating candidate structures and confidence levels based on eutectic structure descriptions," and specifies the requirements for input validation, batch execution, result interpretation, and experimental record retention, while also agreeing on sample input / output, acceptable response time, and acceptance strategies. After the system generates the encapsulation instructions, it performs static source code analysis, identifying the prediction entry function and parameter configuration file, but no unified input validation module is found. During the unit testing phase, the initially generated service artifact showed feedback of input validation logic errors. Based on the feedback analysis, the agent inserted unified input parsing logic and generated a default value strategy, making the input structure conform to the expected format. Subsequently, in the intent compliance test, the test agent simulated real business calls and verified that the service could correctly execute batch prediction and result interpretation, meeting the acceptance criteria and performance expectations. The final artifact includes complete MCP service code, container build scripts, and generated experimental records and verification reports.

[0173] In another example, the system and method of this embodiment are applied to the encapsulation of a domain detection capability embedding service. Application developers can use this service to embed domain detection capabilities into business modules. In this scenario, the developer specifies the required business detection capabilities at the form target layer, specifies at the capability layer that preprocessing, main inference, and interpretation output capabilities should be included, sets intranet deployment and medium data sensitivity requirements at the constraint layer, and defines P95 latency metrics, concurrency levels, and interface stability standards at the acceptance layer. The static parsing module identifies detection and interpretation functions when analyzing the source code library, but lacks unified input conversion logic. During the initial container building phase, the system reports that the build script lacks necessary dependencies, and the agent automatically repairs the Dockerfile and redeploys accordingly. Subsequently, intent compliance testing reveals that the returned results lack expected interpretation fields, and the system completes the interpretation capability output logic and updates the capability registration configuration accordingly. During the performance verification phase, performance testing shows that the initial service fails to meet the set P95 latency requirements. The agent enables a caching strategy and adjusts the concurrency configuration to ensure service performance meets the standards. The final generated MCP service artifact meets comprehensive requirements such as interface contract stability, output interpretability, and performance indicators, and comes with a complete verification report and encapsulated metadata.

[0174] The role and effect of the embodiments

[0175] The MCP service concept encapsulation system and method based on a large-model intelligent agent provided in this embodiment includes a file processing module, a static parsing module, an encapsulation intent generation module, an intelligent agent engine module, a deployment verification module, and a visualization module. After the user uploads the original code repository compressed package, the system constructs the encapsulation intent through structured parsing and concept forms. The intelligent agent based on the large language model executes encapsulation inference and tool scheduling under the inference action (ReAct) architecture, automatically generating deployable service units that conform to the MCP protocol. The system introduces a structured encapsulation intent mechanism, adaptive service granularity partitioning, and a deployment self-repair closed loop, realizing standardized encapsulation input, intelligent execution process, and verifiable encapsulation results. This system is suitable for model service deployment, intelligent agent application integration, and AI native system construction, and has advantages such as automated encapsulation, closed-loop verification, and user collaborative optimization.

[0176] In summary, the system and method of this embodiment can automatically generate deployable service units conforming to the MCP protocol specification for source code repositories and encapsulation requirements of any structure, achieving end-to-end automated processing from encapsulation intent construction, agent encapsulation execution to deployment verification. Through the conceptual encapsulation mechanism, users can define encapsulation targets using structured forms instead of natural language prompts, significantly improving the standardization and reproducibility of encapsulation input. Through agent reasoning and dynamic tool scheduling mechanisms, the system achieves adaptive execution of code structure understanding, interface abstraction, and configuration generation. Through the deployment verification closed-loop mechanism, the system can achieve error self-diagnosis and automatic repair in complex engineering environments, improving the stability and operability of the encapsulation results.

[0177] The system and method of this embodiment effectively solve the problems of strong reliance on manual labor, non-standard input, non-reproducible encapsulation, and error-prone deployment in existing model encapsulation systems. It realizes automated encapsulation, verification, and adaptive optimization of AI native services, and has the advantages of engineering, intelligence, and scalability. It can be widely used in the fields of model service deployment, intelligent agent application integration, and AI system engineering development.

[0178] The above embodiments are merely illustrative of specific implementations of the present invention, and the present invention is not limited to the scope of the description of the above embodiments. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are only for illustrating the principles of the present invention. Various changes and modifications can be made to the present invention without departing from the spirit and scope thereof, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A service concept encapsulation system based on large model intelligent agents, characterized in that, include: The file processing module is used to receive the code repository compressed package uploaded by the user, decompress it to obtain the project file, and generate a standardized workspace containing the project file. The encapsulation intent generation module is used to guide users to define the encapsulation goals and configuration intents of MCP services through a predefined structured interaction method, and to generate standardized encapsulation intent templates. The static parsing module is used to perform syntax parsing and dependency analysis on the project files, and generate a project summary of the project file structure based on this. The intelligent agent engine module, based on the encapsulated intent template and the project summary, encapsulates the project file by performing encapsulation reasoning and tool scheduling under the ReAct architecture through an intelligent agent based on a large language model, thereby obtaining deployable MCP resources; as well as The deployment verification module is used to perform container construction and operation testing based on the MCP resources, so as to realize the engineering-level verification of the MCP resources, and output a runnable MCP service unit when the verification is successful.

2. The MCP service concept encapsulation system based on large model intelligent agents as described in claim 1, Its features are: in, The file processing module includes: An upload receiving unit is used to receive the compressed code repository package uploaded by the user and perform integrity verification; The decompression unit is used to decompress the code repository compressed package to obtain the project files and generate the directory structure of the project files; as well as The workspace management unit is used to uniformly manage the file paths and dependencies of the decompressed project files and generate the standardized workspace.

3. The MCP service concept encapsulation system based on large model intelligent agents according to claim 1, Its features are: in, The encapsulation intent generation module includes: The encapsulated form configuration unit is used to provide a multi-round guided structured configuration form for users to input encapsulation configuration information, including encapsulation parameters, runtime environment, interface specifications, and dependency constraints, thereby obtaining the encapsulation intent form; The character profile integration unit is used to pre-fill the encapsulated intent form based on the user's historical operation behavior and character profile information; as well as The intent template generation unit is used to perform consistency verification on the encapsulated intent form after user input, and generate a standardized encapsulated intent template based on the encapsulated intent form after the verification is passed.

4. The MCP service concept encapsulation system based on large model intelligent agents according to claim 3, characterized in that: in, The multi-round guided structured configuration form is a hierarchical configuration form, in which the configuration items include at least the model purpose, service function type, resource exposure strategy, expected interface behavior, and target deployment environment parameters. One of the configuration items is a default configuration item. The character profile integration unit pre-fills default configuration items based on the character profile information. The intent template generation unit performs multiple rounds of consistency checks on the encapsulated intent form.

5. The MCP service concept encapsulation system based on large model intelligent agents according to claim 1, Its features are: in, The static parsing module includes: Abstract syntax tree parsing unit is used to parse the class, function and logical structure information in the source code of the project file to obtain the parsing result; The dependency graph construction unit is used to identify and analyze the dependency relationships between multiple functional modules in the source code of the project file and generate a dependency topology graph. as well as The summary generation unit is used to generate a project summary of the project file structure based on the parsing results and the dependency topology graph.

6. The MCP service concept encapsulation system based on large model intelligent agents according to claim 1, Its features are: in, The intelligent agent engine module includes: A large model access unit is used to access a large language model with multi-round reasoning and code generation capabilities, serving as an encapsulated intelligent agent. The context management unit is used to integrate the encapsulated intent template, the project summary, and the task status through the agent to obtain the encapsulated inference context; The tool management unit is used to maintain callable external toolsets, including file editing tools, command-line execution environments, and code analysis tools; The intelligent agent decision-making unit is used to plan the encapsulation task based on the ReAct architecture, and the encapsulation inference context is used to plan the encapsulation task and dynamically call the external toolset; and The scheduling and control unit is used to coordinate the task execution order and resource allocation of the agent based on the encapsulated task planning, and to monitor the status of the agent's task execution to obtain the task status.

7. The MCP service concept encapsulation system based on large model intelligent agents according to claim 1, Its features are: in, The deployment verification module includes: The container building unit is used to generate a containerized runtime environment configuration based on the encapsulation intent template, build the corresponding container, build an image based on the MCP resources, and deploy the image in the container. The service testing unit is used to perform interface function testing and runtime status verification on the container running the corresponding MCP service based on the encapsulation intent template. as well as The error handling unit records an error log when the service testing unit detects an error and sends it back to the agent engine module. The agent corrects its encapsulation logic and redeploys based on the error log.

8. The MCP service concept encapsulation system based on large model intelligent agents according to claim 1, characterized in that, Also includes: The visualization module is used to display the running status, task progress, and log information of the MCP service concept encapsulation system based on the large model intelligent agent in real time.

9. The MCP service concept encapsulation system based on large model intelligent agents according to claim 8, Its features are: in, The visualization module includes: The streaming unit is used to collect and transmit real-time data of encapsulation and deployment during the execution of the file processing module, the encapsulation intent generation module, the static parsing module, the intelligent agent engine module, and the deployment verification module. as well as A visualization unit is used to generate corresponding visualization data based on the real-time data and a predetermined visualization algorithm, and to display the visualization data on a user terminal using a graphical interface.

10. A method for encapsulating MCP service paradigms based on large model intelligent agents, characterized in that, include: During the file processing stage, the system receives the compressed code repository package uploaded by the user, decompresses it to obtain the project files, and generates a standardized workspace containing the project files. In the static parsing phase, the project files are parsed and their dependencies are analyzed, and a project summary of the project file structure is generated based on this. During the encapsulation intent generation phase, users are guided to define the encapsulation goals and configuration intents of the MCP service through a predefined structured interactive approach, and a standardized encapsulation intent template is generated. During the agent encapsulation and execution phase, based on the encapsulation intent template and the project summary, the agent based on the large language model calls the corresponding tools to encapsulate the project file, thereby obtaining a deployable MCP resource. as well as During the deployment and verification phase, container construction and runtime testing are performed based on the MCP resources to achieve engineering-level verification of the MCP resources.

Images