Intelligent agent construction method and device based on context protocol, equipment and medium

Abstract

The invention relates to the technical field of artificial intelligence, can be applied to business scenes of financial science and technology, medical health and the like, and discloses a context protocol-based agent construction method, device, equipment and medium. The method comprises the following steps: deploying a model context protocol server in a processing environment and establishing communication connection with a target database, packaging the operation instruction for the target database and registering the operation instruction as a universal tool set; and the agent platform obtains service description information containing general tool set information, generates a service plug-in, creates an agent instance, loads the service plug-in, selects and determines a target tool through a tool, and binds the target tool to the agent instance. According to the method, the database operation instruction is packaged into the universal tool and introduced into the agent instance in the form of the service plug-in, so that the database capability can be uniformly accessed, selected and bound, the cost of manual interface development and repeated adaptation is reduced, and the standardization and reusability of tool access are improved.

Description

Methods, apparatus, devices, and media for constructing intelligent agents based on context protocols Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to a method, apparatus, device, and medium for constructing intelligent agents based on context protocols. Background Technology

[0002] With the development of artificial intelligence technology, intelligent agents built on large models are gradually becoming important interaction and execution carriers in complex business systems. Compared to simple model inference, intelligent agents typically need to acquire external real-time data, invoke business capabilities, and complete multiple rounds of interactive decisions during operation to support complex business processes. In this process, the way intelligent agents access external data sources and business capabilities directly affects their scalability, versatility, and adaptability efficiency in different business scenarios.

[0003] In existing technologies, intelligent agents typically rely on pre-developed, customized interface services when acquiring database data or performing business operations. These interfaces often exist in the form of function calls or dedicated APIs, requiring specialized design for specific database types, business logic, and model invocation methods. Because the interface definition is tightly coupled with the underlying data source, changes in database structure, access logic, or business requirements often necessitate synchronous modifications to the interface implementation, increasing system maintenance costs and limiting the rapid deployment and reuse of intelligent agents in different environments.

[0004] In the fintech business, intelligent agents are frequently used in scenarios such as risk analysis, transaction monitoring, financial statement analysis, and compliance review. These scenarios typically rely on access to real-time or near-real-time data in databases. Currently, different financial business systems often employ different data models and access methods, requiring intelligent agents to interface with each type of business system separately, resulting in fragmented tool capabilities. Simultaneously, interface capabilities are usually provided to large models through manual configuration, making it difficult for the models themselves to perceive the available operational scope. This limits the intelligent agent's ability to dynamically select appropriate tools based on context during multi-round interactions.

[0005] In the healthcare sector, intelligent agents are increasingly being applied to scenarios such as clinical decision support, health data analysis, and medical information management. These applications demand high accuracy and real-time performance of data. In existing implementations, medical data access interfaces are typically encapsulated separately by the business system, resulting in fixed interface definitions and long update cycles. When an intelligent agent needs to access different healthcare systems or perform multiple data operations, the interface logic often needs to be redeveloped or adjusted, increasing the difficulty of system integration. Furthermore, due to the lack of a unified description and registration mechanism for tool capabilities, intelligent agents struggle to autonomously discover available data operation capabilities based on context during operation, affecting the continuity of the interaction flow. Summary of the Invention

[0006] The main objective of this invention is to provide a method, apparatus, device, and storage medium for constructing intelligent agents based on a context protocol. This invention aims to address the technical problem that in the prior art, the ability of intelligent agents to access databases typically relies on customized interfaces and lacks a mechanism for encapsulating operation instructions into importable, selectable, and bindable general-purpose tools based on a unified protocol, resulting in high costs for tool access and reuse.

[0007] To achieve the above objectives, this invention provides a method for constructing an agent based on a context protocol, comprising: deploying a Model Context Protocol (MGP) server in a processing environment; reading connection configuration information of a target database through the MGP server and establishing a communication connection between the MGP server and the target database according to the connection configuration information; encapsulating operation instructions for the target database into a general toolset through the MGP server based on the MGP specification, and registering the general toolset within the MGP server; initiating a plugin import request to the MGP server through an agent platform, and receiving service description information containing general toolset information returned by the MGP server based on the plugin import request; generating a service plugin through the agent platform based on the service description information; generating an agent instance through the agent platform in response to an operation instruction to create an agent instance, and loading the service plugin into the agent instance in response to a plugin addition instruction for the agent instance; determining a target tool from the general toolset through the agent platform in response to a tool selection instruction for the service plugin, and binding the target tool to the agent instance.

[0008] Furthermore, to achieve the above objectives, the present invention provides an agent construction device based on a model context protocol, comprising: a connection management module, configured to deploy a model context protocol server in a processing environment, read connection configuration information of a target database through the model context protocol server, and establish a communication connection between the model context protocol server and the target database according to the connection configuration information; a tool encapsulation and registration module, configured to encapsulate operation instructions for the target database into a general tool set based on the model context protocol specification through the model context protocol server, and register the general tool set within the model context protocol server; and a plugin import and interaction module, configured to import and interact with the model context protocol through an agent platform. The protocol server initiates a plugin import request and receives service description information containing general toolset information returned by the model context protocol server based on the plugin import request; the service plugin generation module is used to generate service plugins based on the service description information through the agent platform; the agent instance assembly module is used to generate agent instances in response to operation instructions for creating agent instances through the agent platform, and load the service plugins into the agent instances in response to plugin addition instructions for the agent instances; the tool selection and binding module is used to determine the target tool from the general toolset in response to tool selection instructions for the service plugins through the agent platform, and bind the target tool to the agent instance.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a context-protocol-based agent building program stored in the memory and executable on the processor, wherein when the context-protocol-based agent building program is executed by the processor, it implements the steps of the context-protocol-based agent building method as described above.

[0010] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a context-protocol-based agent construction program, wherein when the context-protocol-based agent construction program is executed by a processor, it implements the steps of the context-protocol-based agent construction method as described above.

[0011] Beneficial Effects: This invention relates to the field of artificial intelligence technology and can be applied to business scenarios such as fintech and healthcare. It discloses a method, apparatus, device, and medium for constructing intelligent agents based on a context protocol, including: deploying a model context protocol server in a processing environment and establishing a communication connection with a target database; encapsulating and registering operation instructions for the target database as a set of general tools; the intelligent agent platform obtaining service description information containing information about the general tools set and generating service plugins; creating an intelligent agent instance and loading the service plugins; and selecting a target tool and binding it to the intelligent agent instance. This invention encapsulates database operation instructions as general tools and introduces them into the intelligent agent instance as service plugins, enabling unified access, selection, and binding of database capabilities. This reduces the cost of manual interface development and repetitive adaptation, and improves the standardization and reusability of tool access. Attached Figure Description

[0012] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the drawings: Figure 1 is a schematic diagram of an application environment of the intelligent agent construction method based on the context protocol in an embodiment of the present invention; Figure 2 is a schematic flowchart of an embodiment of the intelligent agent construction method based on the context protocol in the present invention; Figure 3 is a schematic diagram of the functional modules of a preferred embodiment of the intelligent agent construction device based on the context protocol in the present invention; Figure 4 is a schematic diagram of the structure of a computer device in an embodiment of the present invention; Figure 5 is another schematic diagram of the structure of a computer device in an embodiment of the present invention. Detailed Implementation

[0013] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0014] The intelligent agent construction method based on the context protocol provided in this invention can be applied in the application environment shown in Figure 1, where the client communicates with the server via a network. The server can deploy the Model Context Protocol server in the processing environment through the client and establish a communication connection with the target database. It encapsulates and registers operation instructions for the target database as a set of general tools. The intelligent agent platform obtains service description information containing the general toolset information and generates service plugins, creates an intelligent agent instance and loads the service plugins, and selects and binds the target tool to the intelligent agent instance. This invention encapsulates database operation instructions as general tools and introduces them into the intelligent agent instance as service plugins, enabling unified access, selection, and binding of database capabilities. This reduces the cost of manual interface development and repeated adaptation, and improves the standardization and reusability of tool access. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] Please refer to Figure 2, which is a flowchart illustrating an embodiment of the intelligent agent construction method based on a context protocol provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0016] As shown in Figure 2, the intelligent agent construction method based on the context protocol proposed in this invention includes the following steps: S10, deploying a model context protocol server in the processing environment, reading the connection configuration information of the target database through the model context protocol server, and establishing a communication connection between the model context protocol server and the target database according to the connection configuration information; In this embodiment, the processing environment is used to host runnable service entities, and has network communication, persistent operation, and access driver loading capabilities, and can be a local node, container environment, or controlled computing cluster. After the model context protocol server is deployed to the processing environment, it forms an accessible running instance and loads the connection configuration information during the startup phase. The connection configuration information is used to describe the access elements of the target database, including fields such as network location, communication port, access identity, and verification credentials, and the source can be a configuration file, environment variable, or centralized configuration center. After reading the information, the server performs structured parsing and field validation, mapping each field to internal connection parameters to avoid connection failure due to missing or abnormal formats. Subsequently, the server calls the connection driver component matching the target database, establishes a transmission channel based on the parsed network location and port, and completes the permission verification interaction with the access identity and verification credentials. After successful verification, the server maintains a reusable database session entity as the carrier of the communication connection, so that subsequent accesses to the target database are established in the same session context.

[0017] The processing environment can use container instances to host the server, injecting connection configuration information through startup parameters to automatically establish connections; alternatively, a persistent process can host the server, pulling connection configuration information from a configuration center and rebuilding the communication connection when the configuration changes. Communication connections can be configured with session reuse strategies based on concurrency requirements, and encrypted transmission channels or access proxies can be introduced based on network conditions to adapt to deployments across network regions.

[0018] This embodiment centrally deploys and runs the Model Context Protocol (MTP) server in the processing environment. The server uniformly reads the connection configuration information and establishes and maintains the communication connection. This enables the connection establishment process of the target database to have a continuous link of structured parsing, verification and session reuse, reducing the probability of errors caused by scattered connection configuration and improving the stability of connection establishment and maintenance.

[0019] S20, the Model Context Protocol (MGP) server, based on the MGP specifications, encapsulates the operation instructions for the target database into a general toolset and registers the general toolset within the MGP server. In this embodiment, after establishing a communication connection with the target database, the data access capabilities exposed by the MGP server need to be uniformly expressed in a structured and describable form. The operation instructions for the target database originate from abstractions of database access requirements, such as data querying, condition filtering, field mapping, or metadata reading. These operation instructions exist internally within the server in the form of logical definitions. The server encapsulates each operation instruction according to the MGP specifications, converting the operation semantics, parameter constraints, and invocation methods into a unified tool description structure, enabling it to be understood and parsed by external systems. During the encapsulation process, the server generates a corresponding tool definition for each operation instruction and aggregates multiple tool definitions to form a general toolset. This general toolset is used to centrally describe all the operation capabilities that the server can perform on the target database. After encapsulation, the server writes the general toolset into its own maintained registration space. By registering the toolset, the server marks it as discoverable and callable, thus maintaining consistent tool visibility throughout the server's runtime.

[0020] Operation commands can originate from predefined data access templates or be dynamically generated through configuration. When encapsulated as a general toolset, the expression of parameter structures can be adjusted according to different database types to adapt to different query syntaxes or field types. The registration process can employ an in-memory structure maintenance toolset or be combined with persistent storage to automatically restore the registration state after a server restart, thus adapting to long-running or elastically deployed processing environments.

[0021] This embodiment encapsulates the operation instructions for the target database into a common toolset and completes the registration on the server side. This enables the database operation capabilities to be centrally managed in a standardized and describable form, reducing inconsistencies caused by scattered operation definitions and providing a stable foundation for subsequent discovery and use of these operation capabilities by external systems.

[0022] S30: The intelligent agent platform initiates a plugin import request to the model context protocol server and receives service description information containing general toolset information returned by the model context protocol server based on the plugin import request. In this embodiment, in order to obtain the general toolset information registered by the model context protocol server, the intelligent agent platform needs to first form a plugin import request that can be recognized by the server. The composition of the plugin import request originates from the intelligent agent platform's need to locate the target access endpoint, and usually includes a service network address, protocol identification information, and a request field to express the import intent, enabling the server to distinguish that the request belongs to plugin access rather than database operation call. When initiating a plugin import request, the intelligent agent platform encodes the plugin import request into a network transmission payload and sends the payload to the model context protocol server through a transport layer connection, thereby triggering the server's response process for the import intent. After receiving the plugin import request, the model context protocol server reads the tool description content corresponding to the general toolset from its internal registration space, organizes the tool description content into service description information, and returns it. The service description information is used to express information about a general toolset, including at least the identification and description information of each tool in the toolset. This enables the intelligent agent platform to form a resolvable and structured understanding of the tool capabilities after receiving the data. After receiving the data returned by the server, the intelligent agent platform decodes and parses the network load to obtain the service description information. This service description information is then used as the input data source for generating usable plugin entities, thus achieving a continuous connection from the network interaction results to the usable description data within the platform.

[0023] Plugin import requests can use either a synchronous request-response mode or an asynchronous callback mode. In asynchronous mode, the agent platform maintains the request identifier after sending the plugin import request and completes the matching upon receiving the return result. Service description information can be carried in structured text format or binary serialization format, and the agent platform selects the corresponding parsing component based on the format. To adapt to different deployment environments, the agent platform can set timeout parameters and the number of retries, and ensures that the fields in the plugin import request remain consistent during retries to avoid ambiguity on the server side regarding the same import intent.

[0024] This embodiment enables the intelligent agent platform to obtain a structured description of the available tool capabilities on the server side through a unified network interaction method by initiating a plugin import request and receiving service description information containing general toolset information. This reduces inconsistencies caused by manual interface definition and provides stable data input for the subsequent formation of usable plugins on the platform side.

[0025] S40, the intelligent agent platform generates service plugins based on the service description information. In this embodiment, the process of generating service plugins based on service description information by the intelligent agent platform revolves around the parsability, storability, and interactivity of the service description information. The service description information comes from the returned data of the model context protocol server and is usually carried in the form of structured text or structured objects. Its content points to general tool set information. The general tool set consists of multiple tools, and each tool corresponds to at least three types of data that can be used to describe the tool's capabilities and calling constraints: tool name, functional description text, and input parameter structure definition. The intelligent agent platform performs format parsing on the service description information, converting the structured text into structured objects that can be processed internally by the platform. Then, it traverses the general tool set information, extracts the tool name, functional description text, and input parameter structure definition for each tool, and aggregates these data into a tool list object according to the tool dimension. The source of the tool list object is the parsing result of the service description information. Its function is to form a data carrier that can be persisted and reused by the platform internally for interactive rendering, avoiding the problem of tool description data being scattered in multiple places and difficult to reference consistently. Service plugins are generated using plugin instances as the underlying entity. Each plugin instance is created in the local repository of the agent platform and assigned a unique identifier. This unique identifier distinguishes different plugin instances and supports subsequent retrieval and updates. The agent platform writes the tool list object into the service plugin's internal data structure. This internal data structure can contain a set of tool entries, a tool entry index, and field mapping relationships, enabling the service plugin to hold structured information about a common tool set on the platform side. To make the service plugin interactive, the agent platform generates visual interactive components based on the input parameter structure definition in the tool list object. These visual interactive components originate from the field types, field constraints, and required field attributes defined in the input parameter structure definition. Examples include generating dropdown selection components based on enumeration constraints, text input components based on string constraints, and range input components based on numerical range constraints. After completing the writing of the internal data structure and the generation of the visual interactive components, the service plugin is marked as available. This availability indicates that the service plugin is ready to be displayed on the platform interface and recognized by the plugin management entry point.

[0026] Service description information can be carried in structured text, with the intelligent agent platform using key-value mapping and array traversal to generate a tool list object during parsing. Alternatively, it can be carried in binary serialization, with deserialization performed before field extraction during parsing. Plugin instances can store only the tool list object, or they can create an index table defining tool names and input parameter structures to accelerate name-based and field-based searches. Visual interaction components can be generated and persisted all at once when the service plugin is created, or they can be generated on demand when the interface is opened to reduce initial generation costs. When generated on demand, the tool list object remains the sole data source to maintain consistency.

[0027] This embodiment parses the service description information into a tool list object and writes the tool list object into the internal data structure of the service plugin. At the same time, it generates a visual interactive component based on the input parameter structure definition and marks its availability. This enables the service plugin to have both structured holding capability and interactive presentation capability on the platform side, thereby reducing the inconsistency caused by the scattered storage and repeated parsing of tool description information, and improving the operability and manageability of the plugin in the platform interface.

[0028] S50, the intelligent agent platform responds to the operation command to create an intelligent agent instance, generates an intelligent agent instance, and responds to the plugin addition command for the intelligent agent instance, loading the service plugin into the intelligent agent instance. In this embodiment, the operation command to create an intelligent agent instance originates from the platform-side interaction entry or interface call entry. The operation command carries at least the necessary fields for the instance creation request. The necessary fields may include instance type identifier, instance name, running mode identifier, etc., used to allow the platform to determine the form and default configuration set of the intelligent agent instance to be generated. The intelligent agent platform performs command parsing on the operation command to create the intelligent agent instance, extracts the fields used for instance creation, and generates an instance creation parameter set. The instance creation parameter set serves as the input carrier for subsequent generation of intelligent agent instances, used to avoid inconsistent field interpretations due to multiple parsings of the original command text in subsequent links. The generation of intelligent agent instances is carried by instance objects. The instance objects form a persistent record entity and a runnable loading entity on the platform side. The record entity is used to store the static configuration data of the instance, and the loading entity is used to carry the instance's running environment and configuration environment. To establish instance traceability, the agent platform assigns a unique identifier to each agent instance. This unique identifier originates from the platform's identifier generation rules or random sequence generation rules, and is used to distinguish different agent instances and support instance location by identifier. To establish instance configurability, the agent platform generates an initial configuration file for each agent instance. This initial configuration file is derived from the merged result of the instance creation parameter set and the platform's default configuration template. The initial configuration file records the instance's basic configuration items, plugin loading list, and plugin loading order, etc.

[0029] The agent platform responds to plugin addition commands for agent instances and loads service plugins into those instances. This process revolves around the target location of the plugin addition command, the searchability of the service plugin, the executableness of the loading action, and the verifiability of the loading result. Plugin addition commands originate from the platform's plugin management entry point or instance configuration entry point. These commands carry at least a unique identifier for the agent instance and an index identifier for the service plugin, allowing the platform to determine the loading target and object. The agent platform parses the plugin addition command, using the unique identifier to locate the target agent instance and the index identifier to locate the service plugin's storage reference address in the local repository. This storage reference address points to the location of the service plugin's internal data structure and runtime components. Loading the service plugin involves not only establishing a reference relationship but also loading the service plugin's runtime components into the loading entity associated with the agent instance. This enables the agent instance to access the service plugin's internal data structure and execute the service plugin's interactive capability configuration during runtime. To ensure the repeatability of the loading process, the agent platform writes the storage reference address of the service plugin into the plugin entry set in the initial configuration file. This plugin entry set records the binding relationship, loading order, and activation status between the service plugin and the agent instance. To ensure the verifiability of the loading process, the agent platform generates a loading result identifier and updates the status field in the initial configuration file after loading is complete, enabling the agent instance to be recognized by the platform interface or the runtime scheduling module as having a loaded service plugin.

[0030] This embodiment parses the operation instructions for creating intelligent agent instances and generates an instance creation parameter set, assigns a unique identifier, and generates an initial configuration file, enabling intelligent agent instances to have the basic conditions for being located and configured. By parsing the plugin and adding instructions to locate the intelligent agent instance and service plugin, obtaining the storage reference address and loading the runtime component, and writing the storage reference address into the initial configuration file and updating the status field, the loading process of the service plugin has an executable, traceable, and verifiable link, thereby improving the consistency and manageability of instance generation and plugin loading.

[0031] S60, the agent platform responds to the tool selection instruction for the service plugin, determines the target tool from the general tool set, and binds the target tool to the agent instance.

[0032] In this embodiment, the tool selection instruction originates from the interaction or interface entry point of the intelligent agent platform. The instruction carries at least the service plugin's identification information and the tool selection information. The service plugin's identification information is used to limit the search scope, and the tool selection information can be the tool name, tool identifier, or the tool's index number in a general tool set, allowing the intelligent agent platform to map the selection intent to a unique tool definition. After receiving the tool selection instruction, the intelligent agent platform performs instruction parsing, extracting the service plugin's identification information and the tool selection information into a tool selection parameter set. This parameter set serves as the input carrier for subsequent positioning and binding, avoiding field interpretation biases when repeatedly reading the original instruction text.

[0033] The general toolset is a collection of tool definitions registered with the Model Context Protocol (MCP) server and perceived by the agent platform through service description information. Each tool in the general toolset contains tool metadata such as tool name, functional description text, and input parameter structure definition, supporting the discovery and invocation of tools. The agent platform performs a matching search within the general toolset based on the tool selection parameter set. This matching search can be performed by exact matching of tool names, equivalent matching of tool identifiers, or location matching by index number. A successful match yields a unique tool definition entry, which is then identified as the target tool. To reduce ambiguity, the agent platform performs a consistency check when determining the target tool. This consistency check at least verifies the association between the target tool's general toolset and the service plugin, preventing tool selection instructions from pointing to tool definition entries inconsistent with the service plugin.

[0034] Binding a target tool to an agent instance involves establishing a persistent, resolvable, and executable binding relationship on the agent instance side. This allows the agent instance to map task requirements to target tool invocation requests during runtime. During the binding phase, the agent platform extracts functional description text and input parameter structure definitions from the target tool. The functional description text is used to constrain the tool's usage boundaries, and the input parameter structure definitions are used to constrain parameter fields, field types, mandatory rules, and value ranges. The agent platform integrates this information into the agent instance's configuration environment. This configuration environment can include a tool binding list, a tool invocation template, and a set of parameter validation rules. The tool binding list records the associations between the target tool and the agent instance, the tool invocation template forms the subsequent invocation request carrier, and the set of parameter validation rules performs structural consistency checks on the input parameters before invocation. After writing, the agent platform generates a binding identifier for this binding relationship and updates the status fields of the configuration environment, enabling the agent instance to identify the bound target tool and route invocations according to the binding relationship during scheduling.

[0035] This embodiment parses the tool selection instructions to form a tool selection parameter set and locates the target tool in a general tool set, making the tool selection have a clear and searchable path; by extracting the functional description text and input parameter structure definition of the target tool and integrating them into the configuration environment of the agent instance, a tool binding list, tool call template and parameter verification rule set are formed, making the binding relationship persistent and executable, thereby improving the callability of the target tool in the agent instance and the parameter consistency control capability.

[0036] In one embodiment, step S10 includes: S101, starting the background process of the Model Context Protocol (MGP) server in the processing environment and configuring the MGP server to load the connection configuration information of the target database; S102, reading the connection configuration information through the MGP server and parsing the host network address, service port number, access username, and authentication password from the connection configuration information; S103, calling the database connection driver through the MGP server and initiating a transport layer network connection request to the target database based on the host network address and the service port number; S104, after the transport layer network connection is established, performing authentication interaction with the target database through the MGP server using the access username and the authentication password, and generating a database session object that remains active as a communication connection after successful authentication.

[0037] In this embodiment, the processing environment is used to support the operation and network access capabilities of the Model Context Protocol (MGP) server. This environment can take the form of a physical server, a virtual machine, a container cluster, or a set of compute nodes with network isolation policies. Starting the background process of the MGP server involves creating a persistent service process or service container instance in the processing environment, providing the server with the basic conditions for listening on ports, processing requests, and maintaining state. The background process can be started through a process daemon mechanism to launch the executable program, or through a container orchestration system to launch a server image instance and assign it a process identifier, running user, working directory, and log output channel, ensuring that subsequent connection establishment actions have a traceable runtime environment. Configuring the MGP server to load connection configuration information from the target database involves importing the connection configuration information into the server's configuration loading chain. The source of the connection configuration information can be a configuration file, environment variables, a key management system's read interface, or a distribution channel from a centralized configuration center. The loading action requires writing configuration items into the server's memory configuration object or configuration cache, ensuring that subsequent read actions have a defined data source and field structure.

[0038] Reading connection configuration information and parsing the host network address, service port number, access username, and authentication password involves structured extraction and semantic normalization of connection parameters. The host network address identifies the network endpoint of the target database; it can be a domain name, IPv4 address, or IPv6 address. Parsing requires handling domain name resolution and address validity verification to reduce the probability of connection failures due to incorrect endpoints. The service port number identifies the listening entry point of the target database. Parsing requires converting it to a numeric type and validating the port range to avoid connection anomalies triggered by unexpected ports. The access username identifies the accessing entity, and the authentication password proves the accessing entity has permission. Parsing requires distinguishing between plaintext and ciphertext configurations. Ciphertext configurations need to be decrypted or tokenized on the server side before entering the subsequent authentication interaction chain to ensure that the authentication interaction obtains usable credentials. The parsing results of the above fields need to be written into the connection parameter object. The connection parameter object serves as the input carrier for the database connection driver, ensuring that the fields used in subsequent transport layer network connection requests come from the same parsing result, avoiding inconsistencies caused by independent parsing of fields in multiple places.

[0039] Calling the database connection driver and initiating a transport layer network connection request to the target database involves using the database driver to achieve protocol adaptation and network handshake. The database connection driver encapsulates socket creation, connection timeout control, retry strategies, and underlying protocol frame formats. When called, the host network address and service port number need to be injected into the driver's connection constructor or connection factory interface. The driver then creates a network connection handle and initiates a connection establishment request. The transport layer network connection request can correspond to the TCP connection establishment process or the transport layer session establishment process with encrypted channel capabilities. The driver can configure and enable connection timeout thresholds, connection retries, and backoff intervals to ensure connection recovery even during network jitter. After the connection is accepted, authentication interaction is performed on top of the established transport layer connection, involving access control verification. The server sends an authentication message to the target database using the access username and authentication password and receives an authentication response. Authentication interaction can include random challenges, digest calculations, or session key negotiation to reduce the risk of credential exposure during transmission. After successful authentication, a persistent database session object is generated as a communication connection. This is manifested internally on the server by creating a reusable session handle. This session handle needs to be bound to the target database endpoint information and authentication state information, and maintain heartbeat, idle timeout, and reconnection control parameters to ensure its validity during subsequent database operations. The significance of the database session object as a communication connection is that subsequent requests no longer require repeated endpoint resolution, transport layer connection establishment, and authentication interactions. Instead, executable statements or metadata requests are sent directly based on this database session object, thus forming a continuously available communication channel.

[0040] This embodiment ensures that connection parameters have a unified entry point and consistent field source by starting a background process in the processing environment and loading connection configuration information into the server's configuration loading chain. By parsing the connection configuration information to obtain the host network address, service port number, access username, and authentication password and forming a connection parameter object, a continuous input chain is formed between network endpoint location and credential preparation. By initiating a transport layer network connection request by calling the database connection driver and performing authentication interaction after the connection is accepted, a closed loop from network connectivity to access authorization is formed. By generating an active database session object as a communication connection after successful authentication, subsequent interactions can reuse the session and reduce the overhead of repeated handshakes and authentications, thereby improving the determinism and persistence of communication connection establishment.

[0041] In one embodiment, step S20 includes: S201, defining data query logic and metadata retrieval logic for the target database through the Model Context Protocol (MTP) server, and using the data query logic and metadata retrieval logic as operation instructions; S202, constructing a tool metadata object containing a tool name, function description text, and input parameter structure definition for each operation instruction through the MTP server in accordance with the MTP data definition specifications; S203, configuring a backend execution function corresponding to each operation instruction through the MTP server, wherein the backend execution function is used to receive request parameters conforming to the input parameter structure definition and convert the request parameters into executable statements for the target database; S204, establishing an association mapping between the tool metadata object and the backend execution function through the MTP server, and combining multiple generated mapping objects to form a general tool set; S205, storing the general tool set in the in-memory registry of the MTP server through the MTP server to complete registration.

[0042] In this embodiment, the Model Context Protocol (MGP) server encapsulates operation instructions targeting the target database into a set of general tools based on the MGP specification and registers them on the server side. Essentially, this establishes a system on the server side that can be recognized by the protocol, invoked remotely, and executed in the database, defining an instruction description and execution binding system. Data query logic and metadata retrieval logic are defined as operation instructions, representing the abstraction of two types of database interaction intentions towards the target database into discrete instruction units. Data query logic describes retrieval actions for business or analytical data, and its implementation may include query object range constraints, filter condition concatenation rules, pagination and sorting rules, return field selection rules, and result set formatting rules. Metadata retrieval logic describes retrieval actions for database structure information, and its implementation may include database-level and table-level information reading, field definition reading, index and constraint information reading, data type mapping information reading, and permission visibility filtering rules. Treating data query logic and metadata retrieval logic as operation instructions means that the server needs to assign a distinguishable instruction identifier to each operation instruction and solidify the instruction identifier and instruction semantic constraints into a data structure that the server can retrieve. This ensures that subsequent metadata object construction and backend execution function configuration can reference the same operation instruction without ambiguity.

[0043] Following the data definition specifications of the model context protocol, a tool metadata object is constructed for each operation instruction, which is a structured description of "callable capabilities". The tool name is used to uniquely identify the tool and serves as the entry point for invocation in protocol interactions. Its implementation must ensure that the naming does not conflict within the common tool set and is consistent with the semantic boundaries of the operation instruction. The functional description text explains the tool's purpose, input meaning, and output meaning in a machine-understandable and human-readable manner. Its implementation typically requires that the description be consistent with the behavior of the backend execution function to avoid invocation errors caused by inconsistencies between description and actual execution. The input parameter structure definition constrains the set of fields, field types, whether fields are required, field value ranges, and dependencies and mutual exclusions between fields. Its implementation can use structured constraint expressions to support validation and automatic generation of interactive interfaces. The tool metadata object needs to contain associated fields that correspond one-to-one with the operation instruction, so that the same operation instruction can accurately locate its tool metadata object in subsequent mapping stages.

[0044] Configuring a backend execution function for each operation command translates abstract instructions into executable computation paths. The backend execution function receives request parameters conforming to the input parameter structure definition. First, it performs parameter integrity and type consistency checks, with rules derived from the input parameter structure definition's limitations on field types, mandatory constraints, and value ranges. Then, it converts the request parameters into executable statements targeting the target database. This conversion process includes a set of rules mapping structured parameters to database statement fragments; for example, mapping filter parameters to predicate fragments, field selection parameters to projection fragments, and pagination parameters to constraint fragments. During the mapping process, keywords and special characters are escaped or parameterized to reduce the injection risk associated with statement concatenation. The executable statement can be a query statement, a metadata retrieval statement, or a database system table retrieval statement, depending on the semantics of the operation command. The backend execution function also needs to define the execution context, including database session reuse strategies, timeout control strategies, result set size limit strategies, and standardized output rules for error codes and exception information, ensuring the return structure of the same tool remains stable under different invocation conditions.

[0045] Establishing an association mapping between tool metadata objects and backend execution functions essentially binds the "description layer" and the "execution layer." This association mapping must at least include an index relationship from tool names to backend execution functions, enabling the location of the corresponding backend execution function when a call request based on the tool name is received. It also needs to include association fields from tool metadata objects to backend execution functions, allowing parameter validation and conversion in the backend execution functions to use the input parameter structure definition in the tool metadata object as a constraint. Generating multiple mapping objects and combining them to form a general tool set means that the general tool set is an aggregate structure composed of multiple mapping objects within the server. This aggregate structure needs to support retrieval by tool name, by operation command, and by capability type to meet the requirements of subsequent service description information generation and call distribution. The combination process of the general tool set also needs to handle tool name conflicts, version differences in input parameter structure definitions, and consistency checks of functional description text to ensure that the boundaries of each tool within the set are clear and that they can be called stably.

[0046] Storing a generic toolset in an in-memory registry on the model context protocol server for registration is implemented by establishing a quickly accessible registration index at server runtime. The in-memory registry stores the aggregate structure of the generic toolset and its retrieval index. During registration, the generic toolset is written to a specified namespace or service instance context within the in-memory registry, generating key-value indexes for lookup. For example, the tool name can be used as the key to locate the mapping object, and the operation instruction identifier can be used as the key to locate the tool metadata object. Completed registration also means enabling the in-memory registry in the server's request processing chain. This allows subsequent protocol requests to be processed through the in-memory registry for tool discovery, tool description return, and tool invocation distribution, without repeatedly constructing mapping objects or reloading tool metadata objects. This forms a closed loop from instruction definition, metadata description, execution binding to runtime registration.

[0047] This embodiment abstracts data query logic and metadata acquisition logic into operation instructions and constructs a tool metadata object for each operation instruction, containing a tool name, functional description text, and input parameter structure definition. This allows database-related capabilities to be uniformly described in a structured manner and have verifiable parameter constraints. By configuring a backend execution function for each operation instruction that can receive request parameters and convert them into executable statements, tool calls can stably land on the target database execution path and form a controllable output structure. By establishing an association mapping between tool metadata objects and backend execution functions and combining them to form a general tool set, the description layer and the execution layer remain consistent in the same mapping object, reducing the inconsistency risk caused by the separation of description and execution. By storing the general tool set in an in-memory registry for registration, the server can complete tool retrieval and call distribution in a low-overhead manner during runtime, thereby improving the reusability and response efficiency of the tool encapsulation and registration chain.

[0048] In one embodiment, step S30 includes: S301, providing a plugin configuration interface through the intelligent agent platform and receiving the service network address of the Model Context Protocol (MGP) server input through the plugin configuration interface; S302, constructing a plugin import request based on the service network address through the intelligent agent platform, wherein the plugin import request encapsulates handshake data for negotiating protocol versions with the MGP server; S303, sending the plugin import request to the service network address through the intelligent agent platform to trigger the MGP server to retrieve the registered general toolset; S304, receiving the network response data packet returned by the MGP server through the intelligent agent platform and parsing service description information from the network response data packet, wherein the service description information contains the metadata definition of each tool in the general toolset.

[0049] In this embodiment, the intelligent agent platform initiates a plugin import request to the model context protocol server and receives the returned service description information. This represents a closed-loop chain on the platform side, completing server location, request construction, network interaction, and response parsing. This allows the platform to obtain general toolset information and provide input data for subsequent plugin generation. The plugin configuration interface is used to collect service network addresses. Its implementation emphasizes transforming the server's access entry point into a set of connection parameters that the platform can process. The service network address may include components such as protocol type, host address, port, and path prefix. The interface needs to perform legality checks on the input format, such as checking whether the protocol type matches, whether the port is a resolvable value, and whether the path meets the preset routing rules. After successful verification, the service network address is written to the platform's connection configuration storage area, ensuring that subsequent request construction processes can use the same address data without branching. To reduce the probability of errors caused by repeated configuration, the plugin configuration interface can also cache the most recently successful service network address locally and add visibility control and expiration conditions to cached entries to avoid triggering erroneous connections using expired addresses.

[0050] Constructing a plugin import request based on a service network address involves encoding the "import intent" into a network-transmittable data structure and encapsulating handshake data within the request to complete protocol version negotiation. The plugin import request needs to include clear request target information and request semantic information. The request target information comes from the parsing result of the service network address, and the request semantic information indicates that the request is a plugin import type rather than a tool call type. The handshake data identifies the set of protocol versions supported by the platform, capability tags, and compatibility policies, enabling the server to select a matching protocol version and return service description information in the appropriate format. The handshake data encapsulation typically includes a version number field, a feature bit field, and a serialization rule field. The version number field expresses the acceptable range of protocol versions, the feature bit field expresses support for data structure fields, and the serialization rule field expresses the encoding method of the request and response bodies, thus avoiding parsing failures due to field or encoding differences. Constructing a plugin import request also requires determining the request method type and the set of request header fields, such as content type fields, session-related fields, and tracking identifier fields. The tracking identifier field is used to associate the request and response of a single import interaction, facilitating platform-side problem localization and reuse of the parsing context.

[0051] Sending a plugin import request to the service network address triggers the server to retrieve the registered general toolset. This involves transmitting the request over the network and waiting for the server to complete the toolset retrieval and description generation. The sending process requires establishing a connection channel and configuring communication parameters on the platform side, such as connection timeout thresholds, retry policies, and maximum response size limits. The connection timeout threshold prevents prolonged blocking of platform threads due to server unavailability, the retry policy handles transient network fluctuations, and the maximum response size limit prevents abnormal responses from causing resource consumption. To enable the server to accurately locate the general toolset internally, the plugin import request typically carries identification information related to the server's retrieval logic, such as service instance identifiers or toolset namespace identifiers. This allows the server to complete the retrieval in its memory registry and organize the returned content upon receiving the request. Triggering the retrieval does not equate to directly transmitting all runtime entities of the general toolset; rather, it triggers the server to output its publicly available descriptive information, allowing the platform to complete the plugin import in a description-driven manner.

[0052] Receiving network response packets and parsing service description information involves the platform decoding, structurally extracting, and verifying the consistency of the server's returned content to obtain service description information containing information about a general toolset. Network response packets typically include a status code, a response header, and a response body. The status code distinguishes between successful and abnormal responses, the response header expresses the protocol version selection result and encoding method, and the response body carries the specific content of the service description information. The parsing process first requires determining the decoding rules based on the response header and completing deserialization to restore the response body to a structured data object. Then, the metadata definitions of each tool in the general toolset are extracted from the structured data object. The metadata definitions must at least cover the tool name, function description text, and input parameter structure definitions so that the platform can subsequently generate interactive components and implement tool selection and binding. The parsing process also requires performing consistency checks, such as verifying whether the tool name is unique, whether the input parameter structure definition can be parsed into a set of field types supported by the platform, and whether the function description text has a basic correspondence with the field definitions, thereby reducing the probability of failure in the subsequent plugin generation stage. To ensure the reusability of import results, the platform can write service description information into local storage in a structured form and attach associated fields such as service network address and protocol version number. This allows the same server to perform difference comparison and incremental updates when importing again, without having to completely rebuild all description information each time.

[0053] This embodiment receives and verifies the service network address through the plugin configuration interface, enabling the platform to locate the model context protocol server through a unified connection entry point and reduce import failures caused by address configuration errors. By constructing a plugin import request containing handshake data based on the service network address, the platform and the server complete protocol version negotiation and stably determine the response data structure and encoding rules during the import interaction phase. By sending the plugin import request, the server is triggered to retrieve the registered general toolset, allowing the platform to obtain general toolset information using description information as a carrier without relying on manual organization. By receiving network response data packets and parsing service description information, the platform can extract the metadata definitions of each tool in the general toolset and form structured input, providing a consistent data foundation for subsequent plugin generation and interface generation.

[0054] In one embodiment, step S40 includes: S401, parsing the service description information using the intelligent agent platform to extract the names, function description texts, and input parameter structure definitions of each tool in the general toolset contained in the service description information, and assembling the names, function description texts, and input parameter structure definitions of each tool into a tool list object; S402, creating a unique plugin instance as a service plugin in the local repository using the intelligent agent platform; S403, writing the tool list object into the internal data structure of the service plugin using the intelligent agent platform to establish a data association between the service plugin and the general toolset; S404, generating a corresponding visual interactive component based on the input parameter structure definition contained in the tool list object using the intelligent agent platform, and marking the status of the service plugin as available.

[0055] In this embodiment, the intelligent agent platform generates service plugins based on service description information. This is manifested in the transformation of descriptive data returned by the server into persistent, interactive, and loadable plugin entities on the platform side, providing an operable carrier and data foundation for subsequent plugin additions and tool bindings. Format parsing of the service description information is used to restore network-transmitted data to structured content. The implementation of format parsing includes deserialization, field traversal, and field consistency checks. Deserialization converts the service description information from a string or binary representation into a platform-accessible structured object. Field traversal is used to locate the name, function description text, and input parameter structure definition of each tool within the general tool set. Field consistency checks confirm that the name field exists and is distinguishable, the function description text field can be read, and the input parameter structure definition field can be parsed into a set of parameter items and a set of constraints. Parsing the input parameter structure definition requires extracting the parameter item's name, type, optionality, and value constraints. Types can correspond to strings, numbers, booleans, enumerations, objects, or arrays, while value constraints can correspond to length ranges, numerical ranges, regular expressions, enumeration sets, or nested field rules. This allows subsequent visualization and interactive component generation to directly rely on the input parameter structure definition without manual completion. The names, function descriptions, and input parameter structure definitions of each tool are assembled into a tool list object, representing the convergence of scattered multi-tool information from service descriptions into a unified data container on the platform side. The tool list object needs to maintain structured entries at the tool level. Each entry includes a tool name field, a function description text field, and an input parameter structure definition field, and can also include fields such as entry number, source identifier, and parsing verification result to support traceability in subsequent writing and interface generation. The assembly process requires deduplication of tool names, structure verification of input parameter structure definitions, and code standardization of function description text, ensuring that entries within the tool list object meet the same format and verification standards.

[0056] Creating a unique plugin instance as a service plugin in the local repository provides a persistent, searchable, and loadable entity representation for the service plugin. The local repository hosts persistent records of the plugin instance, and the creation process includes generating a unique identifier, establishing storage records, and initializing the plugin instance's basic fields. The unique identifier distinguishes different plugin instances within the platform and supports subsequent plugin addition commands. Basic fields can include the plugin name, source service identifier, creation time, version identifier, and status field, giving the plugin instance a manageable minimum data set. Treating the plugin instance as a service plugin positions it as a carrier of general-purpose toolkit capabilities, providing a clear target and display object for subsequent writing of tool list objects and generation of visual interactive components. To reduce the probability of subsequent write failures, the storage space or default structure of the service plugin's internal data structure can be initialized synchronously during creation. For example, reserving storage areas for tool definitions, interactive component configurations, and status fields ensures that subsequent write operations are not interrupted due to a lack of structure.

[0057] The tool list object is written into the service plugin's internal data structure to establish a data association between the service plugin and the general toolset. This is manifested in the solidification of the parsed tool information into an internal area accessible to the plugin instance, allowing the service plugin to directly read the tool definitions corresponding to the general toolset after loading. The writing process requires determining the field layout and storage method of the internal data structure. The field layout defines the position and organization of the tool list object within the internal data structure, while the storage method can correspond to row-based records, key-value mappings, or nested document structures. To support quick location by tool name, the internal data structure can include an index mapping with the tool name as the key, enabling tool selection commands to quickly locate the corresponding entry using the tool name or tool identifier. The writing process may include version number writing and integrity verification. Version number writing identifies the version of the toolset being written, while integrity verification confirms that the number of tool entries in the written internal data structure matches the tool list object, that key fields are not lost, and that the input parameter structure definition can be parsed again, thus ensuring stable reading by the service plugin during subsequent loading and display phases. The meaning of data association is that the service plugin stores a set of tool metadata that is consistent with the general toolset, and this set is bound to the unique identifier of the service plugin, so that the information of the general toolset has a clear ownership on the platform side.

[0058] Based on the input parameter structure definition contained in the tool list object, corresponding visual interactive components are generated. This is manifested in transforming the parameter structure into a set of operable input control configurations, allowing users to provide parameters for tool calls in a structured manner. The generation process first requires field decomposition of the input parameter structure definition. Field decomposition breaks down the input parameter structure definition into a list of parameter items, labeling the type, required attributes, and constraint attributes of each parameter item. Next, control mapping rules are selected to map parameter item types to visual interactive component types. For example, string types map to text input controls, numeric types to numeric input controls, enumeration types to dropdown selection controls, boolean types to toggle controls, object types to grouping container controls, and array types to repeatable item controls. Constraint attributes are used to generate control-level validation rules and prompts, while required attributes are used to generate required field markers and submission validation rules, ensuring that the interactive component outputs a parameter data structure consistent with the input parameter structure definition during the parameter collection phase. After generation, the visual interactive component needs to be written into the service plugin's interface configuration area or component configuration area in configuration form, so that the service plugin can directly render the corresponding interface when loaded. Marking a service plugin as available signifies that availability switching has been completed in the plugin management dimension. This allows the platform to identify in the plugin list and plugin addition process that the service plugin has completed parsing, writing, and component generation. The status mark can be bound to the verification result. For example, the status field can be updated only after the tool list object write verification passes and the visual interaction component configuration is generated, thereby preventing the misuse of unfinished plugins.

[0059] This embodiment parses the service description information to extract the names, functional descriptions, and input parameter structure definitions of each tool, enabling the platform to obtain a set of structured tool information. By assembling the extracted content into a tool list object and writing it into the internal data structure of the service plugin, the service plugin forms a data association with the general tool set on the platform and has the ability to carry tool definitions that can be retrieved and reused. By creating a unique plugin instance as a service plugin in the local repository, the plugin has a persistent entity carrier and supports subsequent loading and management. By generating a visual interactive component based on the input parameter structure definition and marking the service plugin's status as available, the plugin has the configuration basis for parameter collection and verification at the interface layer and an availability identifier that can be called and added at the management layer.

[0060] In one embodiment, step S50 includes: S501, responding to an operation instruction to create an intelligent agent instance through the intelligent agent platform, creating an intelligent agent instance containing a unique identifier and an initial configuration file in the database of the intelligent agent platform; S502, receiving and parsing a plugin addition instruction for the intelligent agent instance through the intelligent agent platform, and extracting the index identifier of the service plugin to be loaded from the plugin addition instruction; S503, obtaining the storage reference address of the service plugin through the intelligent agent platform based on the index identifier, and loading the runtime component of the service plugin into the intelligent agent instance based on the storage reference address, the unique identifier of the intelligent agent instance, and the initial configuration file, thereby completing the loading of the service plugin into the intelligent agent instance.

[0061] In this embodiment, the intelligent agent platform responds to the operation command to create an intelligent agent instance and generates the instance. This is manifested in the transformation of an externally triggered instance creation intent into an instantiated object that is manageable, searchable, and referenced by subsequent loading processes on the platform side. The operation command to create an intelligent agent instance is a platform-recognizable control input, and its content includes at least the triggering information of the instance creation request and context information used to distinguish the source of the request. The response actions include command validity determination, instance creation entry scheduling, and creation result write-back. Validity determination is used to confirm that the command fields are complete and meet the platform-side creation constraints. Creation entry scheduling is used to route the command to the instance creation processing logic. Creation result write-back is used to output whether the instance creation was successful and the unique identifier corresponding to the instance.

[0062] Creating an agent instance containing a unique identifier and an initial configuration file in the agent platform's database involves persisting the agent instance as a record and forming a reusable identifier and configuration structure. The agent platform's database stores instance lifecycle data. The creation process includes assigning a unique identifier, generating a database record, and generating an initial configuration file and associating it with the database record. The unique identifier is used to locate the agent instance at the database index level and provides a basis for instance location when adding instructions to subsequent plugins. The generation of the unique identifier can be based on a random identifier generation mechanism, a time-series identifier generation mechanism, or a hash mapping mechanism, ensuring its uniqueness and retrieval on the platform side. The initial configuration file carries the runtime configuration content of the agent instance. The runtime configuration content includes at least a writable area for plugin reference information and a configuration field space related to plugin loading, allowing subsequent loading processes to use the initial configuration file as the configuration endpoint without relying on temporary variables. In addition to the unique identifier and initial configuration file, the database record may also include instance status fields, creation time fields, and version fields to support state switching and consistency checks before and after subsequent loading. Binding the initial configuration file to the agent instance means that the scope of the initial configuration file is limited to that agent instance, so that subsequent modifications to the initial configuration file can be interpreted as updates to the configuration of that agent instance.

[0063] The agent platform receives and parses plugin addition instructions for agent instances, which involves transforming the plugin mounting request into an executable set of loading parameters. The plugin addition instruction at least includes target instance pointer information and the pointer information for the service plugin to be loaded. The receiving action includes obtaining the instruction payload from the instruction input channel and decoding its format. The parsing action includes extracting the index identifier of the service plugin to be loaded and extracting location information related to the agent instance. The index identifier represents the location-defined key value of the service plugin on the platform side. Its source can be a unique identifier of the service plugin, a combination of the service plugin's version identifier, or the service plugin's index key in the local repository. The parsing process needs to verify the existence and validity of the index identifier to ensure deterministic input when subsequently retrieving the storage reference address based on the index identifier. The association between the plugin addition instruction and the agent instance needs to be established through a unique identifier or its equivalent instance pointer field, ensuring that the parsing result is bound to a specific agent instance and avoids cross-instance writes.

[0064] The storage reference address of the service plugin is obtained based on the index identifier, which is reflected in the conversion of the logical index into accessible storage location information. The storage reference address points to the storage location of the runtime component of the service plugin, and its form can be a file path, object storage key value, database record address, or resolvable resource locator. The retrieval action includes performing a search in the plugin index table on the platform side or the local repository index structure, returning the storage reference address that matches the index identifier, and verifying the reachability of the storage reference address. Reachability verification is used to confirm that the storage reference address can be accessed by subsequent loading processes, such as verifying the existence of the path, the satisfaction of permissions, or the readability of the resource, thereby reducing the probability of loading phase failure. By mapping the index identifier to the storage reference address, the service plugin enters the executable loading layer from the abstract identifier level, giving the runtime component loading an operable entry point.

[0065] Based on the storage reference address, the unique identifier of the agent instance, and the initial configuration file, the runtime components of the service plugin are loaded into the agent instance. This is manifested in establishing a binding relationship between the executable part of the plugin and the instance's runtime context, forming a runnable plugin mounting state. The runtime component represents the callable parts of the service plugin at the execution layer. Its content may include the call entry point definition, tool call adaptation logic, parameter validation logic, and the runtime support structure corresponding to the configuration of the visual interaction components. Using the storage reference address means that the loading process uses the storage reference address as the resource reading entry point, performing resource reading, parsing, and loading, enabling the runtime component to enter a platform-side executable or callable state. Using the unique identifier of the agent instance means that the loading target is determined to a specific agent instance through the unique identifier, and the loading result completes the attribution binding at the instance level, preventing the runtime component from being loaded into the context of a non-target instance. Using the initial configuration file means that the loading process writes or merges the configuration related to the service plugin into the initial configuration file, so that the configuration carrying structure of the agent instance includes the service plugin's reference information, activation status information, and necessary runtime parameter information. The write or merge action may include appending the service plugin's index identifier, storage reference address, or runtime component identifier to the initial configuration file, and setting the enable flag field associated with the service plugin. This allows the agent instance to determine the set of loaded service plugins based on the initial configuration file when it starts or executes. Loading runtime components into the agent instance can be implemented by registering the runtime component handle in the instance's associated memory structure, registering the runtime component location in the instance's associated resource table, or registering the service plugin's call entry point in the instance's associated execution context. This enables the agent instance to call the capabilities provided by the service plugin during subsequent execution phases. The determination of whether the service plugin has been successfully loaded into the agent instance can be based on a combination of successful initial configuration file writing, successful runtime component registration, and successful plugin status update at the instance level, ensuring a verifiable closed-loop output for the loading action.

[0066] This embodiment creates an agent instance containing a unique identifier and an initial configuration file in the database of the agent platform. This gives the agent instance a persistent instance identifier and configuration carrying structure, thus providing a stable instance location and configuration landing point for subsequent plugin additions. By extracting the index identifier of the service plugin to be loaded from the plugin addition instruction and mapping it to obtain the storage reference address, the service plugin is transformed from a logical index into accessible storage location information, reducing the uncertainty of the loading entry point. By performing runtime component loading and configuration writing based on the storage reference address, unique identifier, and initial configuration file, the runtime component completes the ownership binding at the instance level and forms a traceable loading record at the configuration level. This supports the service plugin to form a callable loading state within the agent instance and facilitates subsequent management and reuse.

[0067] In one embodiment, step S60 includes: S601, responding to a tool selection interface trigger command through the intelligent agent platform, parsing the loaded service plugins and generating a tool selection list containing the names of each tool in the general tool set; S602, receiving a tool selection confirmation command for the tool selection list through the intelligent agent platform, identifying the tool metadata object of a specific tool from the general tool set according to the tool selection confirmation command, and setting the specific tool as the target tool; S603, extracting the functional description text and input parameter structure definition of the target tool through the intelligent agent platform, and integrating the functional description text and the input parameter structure definition into the configuration environment of the intelligent agent instance to complete the binding.

[0068] In this embodiment, the agent platform responds to tool selection instructions for service plugins by transforming the control input of "which tool to select" into "the result of determining the target tool" and "the binding result of the target tool with the agent instance," provided that the service plugin is already available and loaded into the agent instance. The tool selection instruction is a control instruction for service plugins, its target being the set of general tools associated with the service plugin, and its output being the target tool and its available configuration on the agent instance side. This response process needs to maintain a clear scope of instruction; the tool selection instruction is semantically limited to selection from the set of general tools and does not extend to other tool sources outside the set, thus ensuring the traceability of the target tool's origin and consistency with its association with the service plugin.

[0069] The intelligent agent platform responds to the tool selection interface trigger command, parses the loaded service plugins, and generates a tool selection list containing the names of various tools in the general toolset. This involves converting the general toolset information already contained within the service plugins into a selection carrier that can be used for interactive presentation and subsequent command references. The tool selection interface trigger command initiates the list generation process. Its input can include an interface opening event identifier, a service plugin identifier, or context information associated with the current intelligent agent instance, enabling the platform to generate the list within the correct service plugin scope. Parsing the loaded service plugins involves reading the structured information corresponding to the general toolset from the service plugin's internal data structure. This includes at least the names of each tool and corresponding index or reference fields, ensuring that the tool names are displayable and uniquely identifiable. The tool selection list is a platform-side data structure whose elements include at least a tool name field and a location information field bound to that tool name. The location information field can be a stable key-value pair for the tool name, a reference key-value pair for the tool metadata object, or an index position in the general toolset, allowing subsequent tool selection confirmation commands to pinpoint the specific tool in the general toolset through this location information field. The process of generating the tool selection list also requires deduplication and displayability processing of tool names. Deduplication is used to avoid selection ambiguity caused by tools with the same name, and displayability processing is used to encode or escape tool names according to interface constraints, so that tool names can be stably presented and maintain a consistent mapping relationship with the records inside the general tools set.

[0070] The intelligent agent platform receives a tool selection confirmation command for a tool selection list. Based on the command, it identifies the tool metadata object of a specific tool from a general toolset and sets that specific tool as the target tool. This is represented by mapping the user's or system's confirmation action to a unique tool selection result within the general toolset. The tool selection confirmation command is directed to the tool selection list, and its payload includes at least one selection location field. This field points to an item in the tool selection list or its corresponding location information field, enabling the platform to establish a deterministic mapping between the confirmation command and the elements of the tool selection list. Identifying the tool metadata object of a specific tool from the general toolset based on the command involves the platform performing a search and matching operation within the general toolset using the selection location field. This search and matching can be based on tool name matching, matching based on a combination of tool name and other constraint fields, or directly indexing the tool metadata object based on the location information field. The tool metadata object carries structured definition information related to the tool, including at least the tool name, functional description text, and input parameter structure definition. This allows the subsequent binding phase to directly extract the information to be integrated from the tool metadata object. Designating a specific tool as the target tool involves establishing the identified tool's metadata object as the unique selection result within the current request context, providing a clear reference source for subsequent extraction of functional description text and input parameter structure definitions. This establishment process can be accompanied by the generation or caching of the target tool identifier. For example, the tool name or its reference key-value pair can be written into a temporary context or state field associated with the agent instance, ensuring that the target tool is stably referenced during the binding phase without being affected by concurrent selection operations.

[0071] The intelligent agent platform extracts the functional description text and input parameter structure definition of the target tool and integrates them into the configuration environment of the intelligent agent instance to complete the binding. This is manifested in writing the understandable information and callable constraints of the target tool into the intelligent agent instance in configuration form, enabling the intelligent agent instance to use the target tool during runtime. The functional description text expresses the purpose boundaries, operational intent, and output semantics of the target tool, allowing the intelligent agent instance to form a clear tool selection basis when generating invocation intent. The input parameter structure definition expresses the set of input parameters of the target tool and its structural constraints. Structural constraints can include parameter names, parameter types, parameter hierarchy relationships, mandatory constraints, value range constraints, and default value constraints, enabling the intelligent agent instance to generate request parameters that meet the constraints when constructing invocation requests. The extraction action is manifested in reading the functional description text field and input parameter structure definition field from the tool metadata object corresponding to the target tool and performing necessary format normalization processing. Format normalization processing is used to convert the functional description text and input parameter structure definition into a serialized representation acceptable to the configuration environment, avoiding integration failures due to inconsistent field formats.

[0072] Integrating the functional description text and input parameter structure definition into the agent instance's configuration environment is manifested as creating a tool configuration entry corresponding to the target tool on the agent instance side. The configuration environment hosts the agent instance's runtime configuration set, which may include tool configuration areas, plugin configuration areas, or capability configuration areas. Logically, the integration action is equivalent to adding or updating a configuration entry bound to the target tool in the configuration environment. This configuration entry must include at least the target tool's tool name field, functional description text field, and input parameter structure definition field, ensuring the completeness and consistency of the target tool's description in the configuration environment. The integration action needs to handle overriding or versioning rules for target tools with the same name. Overriding rules determine the update method when a configuration entry with the same tool name already exists in the configuration environment, while versioning rules maintain configuration consistency when the input parameter structure definition changes. The binding is confirmed upon successful writing to the configuration environment and the formation of a searchable target tool configuration entry. This allows the agent platform to read the functional description text and input parameter structure definition corresponding to the target tool from the configuration environment during subsequent operation, and accordingly drive the agent instance to prepare for tool calls and construct call parameters.

[0073] This embodiment generates a list of available tools by responding to the tool selection interface trigger command and parsing the loaded service plugins. This makes the names of each tool in the general toolset an interactive selection entry point and establishes a traceable mapping with the internal records of the general toolset. By receiving the tool selection confirmation command and identifying the tool metadata object of the specific tool from the general toolset, the selection behavior is converged into a unique target tool and its metadata source is clarified. By extracting the functional description text and input parameter structure definition of the target tool and integrating them into the configuration environment of the agent instance, the semantics of the target tool's purpose and input constraints are solidified on the agent instance side in the form of configuration entries. This allows the agent instance to obtain the calling basis and parameter constraints that match the target tool and complete a stable binding.

[0074] In one embodiment, a context-based agent construction device is provided, which corresponds one-to-one with the context-based agent construction method described in the above embodiments. Referring to Figure 3, Figure 3 is a functional module diagram of a preferred embodiment of the context-based agent construction device of the present invention. The device comprises a connection management module 10, a tool encapsulation and registration module 20, a plugin import interaction module 30, a service plugin generation module 40, an agent instance assembly module 50, and a tool selection and binding module 60. Each functional module is described in detail below: The connection management module 10 is used to deploy a model context protocol server in the processing environment, read the connection configuration information of the target database through the model context protocol server, and establish a communication connection between the model context protocol server and the target database according to the connection configuration information; the tool encapsulation and registration module 20 is used to encapsulate operation instructions for the target database into a general toolset based on the model context protocol specification through the model context protocol server, and register the general toolset within the model context protocol server; the plugin import interaction module 30 is used to initiate a plugin import request to the model context protocol server through the agent platform, and... The system receives service description information containing general toolset information returned by the model context protocol server based on the plugin import request; a service plugin generation module 40 is used to generate service plugins based on the service description information through the agent platform; an agent instance assembly module 50 is used to generate agent instances in response to operation instructions for creating agent instances through the agent platform, and to load the service plugins into the agent instances in response to plugin addition instructions for the agent instances; a tool selection and binding module 60 is used to determine target tools from the general toolset in response to tool selection instructions for the service plugins through the agent platform, and to bind the target tools to the agent instances.

[0075] Specific limitations regarding the context protocol-based agent construction device can be found in the foregoing limitations of the context protocol-based agent construction method, and will not be repeated here. Each module in the aforementioned context protocol-based agent construction device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0076] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram is shown in Figure 4. The computer device includes a processor, memory, a network interface, and a database connected via a system bus. The processor of the computer device provides determination and control capabilities. The memory of the computer device includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a context-protocol-based intelligent agent construction method on the server side.

[0077] In one embodiment, a computer device is provided, which can be a client, and its internal structure diagram is shown in Figure 5. The computer device includes a processor, memory, network interface, display screen, and input device connected via a system bus. The processor of the computer device provides determination and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a context-protocol-based intelligent agent construction method on the client side.

[0078] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: deploying a Model Context Protocol (MGP) server in a processing environment; reading connection configuration information of a target database through the MGP server and establishing a communication connection between the MGP server and the target database based on the connection configuration information; encapsulating operation instructions for the target database into a general toolset through the MGP server based on the MGP specification, and registering the general toolset within the MGP server; initiating a plugin import request to the MGP server through an agent platform, and receiving service description information containing general toolset information returned by the MGP server based on the plugin import request; generating a service plugin through the agent platform based on the service description information; generating an agent instance through the agent platform in response to an operation instruction to create an agent instance, and loading the service plugin into the agent instance in response to a plugin addition instruction for the agent instance; and determining a target tool from the general toolset and binding the target tool to the agent instance through the agent platform in response to a tool selection instruction for the service plugin.

[0079] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon. When the computer program is executed by a processor, it performs the following steps: deploying a Model Context Protocol (MGP) server in a processing environment; reading connection configuration information of a target database through the MGP server and establishing a communication connection between the MGP server and the target database based on the connection configuration information; and encapsulating operation instructions for the target database into a general toolset through the MGP server based on the MGP specification, and registering the general toolset within the MGP server. Using a toolset; initiating a plugin import request to the Model Context Protocol (MCP) server via the agent platform, and receiving service description information containing general toolset information returned by the MCP server based on the plugin import request; generating a service plugin based on the service description information via the agent platform; generating an agent instance by responding to the operation instruction to create an agent instance via the agent platform, and loading the service plugin into the agent instance by responding to the plugin addition instruction for the agent instance; determining a target tool from the general toolset by responding to the tool selection instruction for the service plugin via the agent platform, and binding the target tool to the agent instance.

[0080] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0081] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0082] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

[0083] The user personal information involved in this application embodiment is all authorized (knowing and consenting) by the relevant parties or fully authorized by all parties, and the executing entity can obtain it through various open, legal and compliant means. The collection, storage, use, processing, transmission, provision and disclosure of the information, data and signals involved all comply with the relevant laws and regulations of the relevant countries and regions, and do not violate public order and good morals.

Claims

1. A method for constructing an intelligent agent based on a context protocol, characterized in that, Includes the following steps: Deploy a Model Context Protocol (MTP) server in the processing environment, read the connection configuration information of the target database through the MTP server, and establish a communication connection between the MTP server and the target database based on the connection configuration information. Based on the Model Context Protocol (MGP) specification, the MGP server encapsulates the operation instructions for the target database into a general toolset and registers the general toolset within the MGP server. The intelligent agent platform initiates a plugin import request to the model context protocol server and receives service description information containing general toolset information returned by the model context protocol server based on the plugin import request. The intelligent agent platform generates a service plugin based on the service description information; the intelligent agent platform responds to the operation instruction to create an intelligent agent instance, generates an intelligent agent instance, and responds to the plugin addition instruction for the intelligent agent instance to load the service plugin into the intelligent agent instance; the intelligent agent platform responds to the tool selection instruction for the service plugin, determines the target tool from the general tool set, and binds the target tool to the intelligent agent instance.

2. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, Deploying a Model Context Protocol (MGP) server in the processing environment, the MGP server reads the connection configuration information of the target database and establishes a communication connection between the MGP server and the target database based on the connection configuration information. This includes: starting a background process for the MGP server in the processing environment and configuring the MGP server to load the connection configuration information of the target database; reading the connection configuration information through the MGP server and parsing the host network address, service port number, access username, and authentication password from the connection configuration information; calling the database connection driver through the MGP server to initiate a transport layer network connection request to the target database based on the host network address and the service port number; after the transport layer network connection is established, performing authentication interaction with the target database through the MGP server using the access username and the authentication password, and generating a database session object that remains active as a communication connection after successful authentication.

3. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, Based on the Model Context Protocol (MGP) specifications, the MGP server encapsulates operation instructions for the target database into a general toolset and registers the general toolset within the MGP server. This includes: defining data query logic and metadata retrieval logic for the target database using the MGP server, and using these logics as operation instructions; constructing a tool metadata object for each operation instruction, including a tool name, function description text, and input parameter structure definition, following the MGP data definition specifications; configuring a backend execution function corresponding to each operation instruction using the MGP server, whereby the backend execution function receives request parameters conforming to the input parameter structure definition and converts the request parameters into executable statements for the target database; establishing an association mapping between the tool metadata object and the backend execution function using the MGP server, and combining multiple generated mapping objects to form the general toolset; and storing the general toolset in the MGP server's memory registry to complete the registration.

4. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, The process involves: initiating a plugin import request to the Model Context Protocol (MGP) server via the intelligent agent platform; and receiving service description information containing general toolset information returned by the MGP server based on the plugin import request. This includes: providing a plugin configuration interface through the intelligent agent platform and receiving the service network address of the MGP server input through the interface; constructing a plugin import request based on the service network address through the intelligent agent platform, the plugin import request encapsulating handshake data for protocol version negotiation with the MGP server; sending the plugin import request to the service network address through the intelligent agent platform to trigger the MGP server to retrieve the registered general toolset; and receiving a network response data packet returned by the MGP server through the intelligent agent platform and parsing the service description information from the network response data packet, the service description information containing metadata definitions for each tool in the general toolset.

5. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, The process of generating a service plugin based on the service description information using the intelligent agent platform includes: parsing the service description information using the intelligent agent platform to extract the names, functional description texts, and input parameter structure definitions of each tool in the general toolset contained in the service description information; assembling the names, functional description texts, and input parameter structure definitions of each tool into a tool list object; creating a unique plugin instance as a service plugin in a local repository using the intelligent agent platform; writing the tool list object into the internal data structure of the service plugin using the intelligent agent platform to establish a data association between the service plugin and the general toolset; generating a corresponding visual interactive component based on the input parameter structure definition contained in the tool list object using the intelligent agent platform; and marking the status of the service plugin as available.

6. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, The process involves the intelligent agent platform responding to an operation command to create an intelligent agent instance, generating an intelligent agent instance, and responding to a plugin addition command for the intelligent agent instance to load the service plugin into the intelligent agent instance. This includes: responding to the operation command to create an intelligent agent instance and creating an intelligent agent instance containing a unique identifier and an initial configuration file in the database of the intelligent agent platform; receiving and parsing the plugin addition command for the intelligent agent instance through the intelligent agent platform, extracting the index identifier of the service plugin to be loaded from the plugin addition command; obtaining the storage reference address of the service plugin based on the index identifier through the intelligent agent platform, and loading the runtime components of the service plugin into the intelligent agent instance based on the storage reference address, the unique identifier of the intelligent agent instance, and the initial configuration file, thereby completing the loading of the service plugin into the intelligent agent instance.

7. The method for constructing an intelligent agent based on a context protocol as described in claim 1, characterized in that, The process of responding to a tool selection instruction for the service plugin through the intelligent agent platform, determining a target tool from the general tool set, and binding the target tool to the intelligent agent instance includes: responding to a tool selection interface trigger instruction through the intelligent agent platform, parsing the loaded service plugin, and generating a tool selection list containing the names of various tools in the general tool set; receiving a tool selection confirmation instruction for the tool selection list through the intelligent agent platform, identifying the tool metadata object of a specific tool from the general tool set according to the tool selection confirmation instruction, and designating the specific tool as the target tool; extracting the functional description text and input parameter structure definition of the target tool through the intelligent agent platform, and integrating the functional description text and the input parameter structure definition into the configuration environment of the intelligent agent instance to complete the binding.

8. A smart agent construction device based on a context protocol, characterized in that, The context protocol-based agent construction device includes: a connection management module, used to deploy a Model Context Protocol (MGP) server in the processing environment, read connection configuration information of the target database through the MGP server, and establish a communication connection between the MGP server and the target database according to the connection configuration information; a tool encapsulation and registration module, used to encapsulate operation instructions for the target database into a general tool set based on the MGP specification through the MGP server, and register the general tool set within the MGP server; and a plugin import and interaction module, used to initiate plugin import to the MGP server through the agent platform. The system requests and receives service description information containing general toolset information returned by the model context protocol server based on the plugin import request; a service plugin generation module is used to generate service plugins based on the service description information through the agent platform; an agent instance assembly module is used to generate agent instances in response to operation instructions for creating agent instances through the agent platform, and load the service plugins into the agent instances in response to plugin addition instructions for the agent instances; a tool selection and binding module is used to determine target tools from the general toolset in response to tool selection instructions for the service plugins through the agent platform, and bind the target tools to the agent instances.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a context-protocol-based agent building program stored in the memory and executable on the processor. When executed by the processor, the context-protocol-based agent building program implements the steps of the context-protocol-based agent building method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores an agent construction program based on a context protocol, which, when executed by a processor, implements the steps of the agent construction method based on a context protocol as described in any one of claims 1-7.

Images