Large model context protocol implementation system and method based on enterprise bus

Abstract

The invention provides a large model context protocol implementation system and method based on an enterprise bus, belongs to the technical field of enterprise information system integration, and aims to solve the problems of non-uniform protocols, lack of context management, insufficient service governance and the like in large model integration. The system comprises an MCP protocol adaptation layer used for converting internal and external protocols; the unified service management module is used for service discovery and intelligent routing; the context management module is used for recovering and persisting the context before and after calling the service to realize stateful interaction; and the enterprise resource access module is used for packaging the knowledge base and the data center into standard services. The method comprises the steps of protocol conversion, context recovery, service routing, target service calling, context persistence, response conversion and the like. Uniform integration and stateful management of large models are realized, and a channel between the models and enterprise private knowledge data is opened.

Description

Technical Field

[0001] This application relates to the field of enterprise information system integration technology, and in particular to a method and system for implementing a large model context protocol based on an enterprise bus architecture. Background Technology

[0002] With the rise of large model technology, enterprises have an increasingly urgent need to integrate it into their existing application systems. However, enterprise applications typically require the integration of multiple large model services from different vendors, following different protocols, and using different data formats, which presents a significant challenge to the integration work.

[0003] Existing enterprise integration platforms, such as advanced enterprise service buses or data middleware architectures, can access multi-source heterogeneous data through middleware, convert different data formats through protocol adaptation units, and dynamically distribute and schedule services through intelligent routing units. They can even encapsulate models as services for deployment and management. However, these platforms are primarily designed for traditional, stateless service calls, revealing significant shortcomings in practice. First, they lack effective support for the context passing and streaming response mechanisms unique to large models. For example, in multi-turn dialogues or complex task decomposition scenarios, existing platforms cannot effectively maintain and pass dialogue history or intermediate states, preventing large models from engaging in logical, memory-based, continuous interactions and limiting their application depth in complex business scenarios. Second, traditional service governance technologies are mainly geared towards microservice architectures and lack consideration for the specific characteristics of large model services. For instance, large model services consume huge resources, exhibit significant performance fluctuations, and have version dependencies. Traditional governance strategies cannot effectively schedule resources, manage versions, and maintain state.

[0004] Therefore, the existing technology lacks a comprehensive platform that can treat large models as a "stateful" and special enterprise-level service, and perform unified protocol adaptation, context management, service governance and resource integration. This results in the application of large models in enterprises exhibiting pain points such as integration difficulties, chaotic management, low efficiency and insufficient security. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for implementing a large model context protocol based on an enterprise bus architecture. It aims to solve the technical problems caused by the lack of a unified middleware architecture that can understand and manage the characteristics of large models when integrating large models in an enterprise environment. These problems include inconsistent protocols, lack of context management, insufficient service governance capabilities, and difficulty in effectively utilizing internal enterprise resources by large models.

[0006] To achieve the above objectives, this application provides a Large Model Context Protocol (MCP) implementation system based on an Enterprise Bus (AMB) architecture, comprising: an AMB architecture serving as the backbone network for inter-service communication and integration; an MCP protocol adaptation layer deployed on the AMB architecture, used to receive external MCP requests, convert the requests into AMB message formats within the AMB, and convert responses within the AMB into MCP formats; a unified data standard module, used to define a standardized data exchange format based on JSON strings followed by inter-service communication within the AMB architecture; and a unified service governance module, used to receive data from the MCP protocol adaptation layer. The system transforms messages and provides a dynamic registration and discovery mechanism for AI services, as well as an intelligent routing strategy based on service load, to route the messages to the target service. A context management module is configured to restore the historical context state information associated with the message before the unified service governance module routes the message to the target service, and to persistently store the updated context state information after receiving a response from the target service. An enterprise resource access module, including a knowledge base MCP service module and a data center MCP service module, serves as the target service, encapsulating the enterprise's internal knowledge base and data center into standardized bus services for invocation.

[0007] Optionally, the context management module is configured to: restore the historical context state information associated with the request before routing the request to the target artificial intelligence model through the unified service governance module; and persistently store the updated context state information after receiving the response from the target artificial intelligence model.

[0008] Optionally, the knowledge base MCP service module is configured to receive and store the interface definition of an external knowledge base defined in a function call format.

[0009] Optionally, the knowledge base MCP service module is further configured to: perform vectorization processing on the knowledge content, and perform at least one of semantic retrieval, full-text retrieval, and hybrid retrieval based on the result of the vectorization processing.

[0010] Optionally, the unified service governance module is also configured to support version management and canary release of artificial intelligence services; and the system is configured to process messages containing encryption and signature attributes and conforming to the standardized data exchange format within the enterprise bus architecture.

[0011] This application also provides a method for implementing the Large Model Context Protocol (LAMP) based on an Enterprise Bus architecture, comprising the following steps: converting a received LAMP request into a standardized message based on a JSON string within the Enterprise Bus; restoring the historical context state information associated with the request before invoking the target AI model; determining and invoking the target service based on the dynamic registration information of the AI ​​service and a service load-based intelligent routing strategy, wherein, when the request requires access to enterprise resources, the target service is a Knowledge Base MCP service module or a Data Center MCP service module; persistently storing the updated context state information after receiving the response from the target service; and converting the response into the LAMP format and returning it.

[0012] Optionally, the step of restoring historical context state information specifically includes: retrieving corresponding context state information from persistent storage based on the associated task identifier of the request; the step of persistently storing the updated context state information specifically includes: associating the state that needs to be retained in the response with the associated task identifier and storing it in the persistent storage.

[0013] Optionally, when the target service is a knowledge base MCP service module, the method further includes: pre-registering the application programming interface (API) of the external knowledge base as an interface definition in function call format; the step of calling the target service specifically includes: receiving a function call request generated by an artificial intelligence model for the interface definition; and calling the API of the external knowledge base according to the function call request.

[0014] Optionally, when the request requires access to the knowledge base MCP service module, the step of calling the target service includes: if the request contains structured query content and unstructured query content, then performing full-text search and semantic search in parallel on the knowledge base; and merging the results of the full-text search and semantic search as the response of the target service.

[0015] This application also provides a method for implementing a large model context protocol based on an enterprise bus architecture, characterized by the following steps: when a request is marked as an asynchronous processing task, or when its estimated processing time exceeds a preset threshold, the request is converted into a first event and published to a message center; the background service subscribes to and asynchronously processes the first event to complete the task; and after the task is completed, a second event containing the task result is published.

[0016] Compared with the prior art, the technical solution provided in this application has the following beneficial effects: 1. Achieve unified integration and management: Through the enterprise bus architecture and MCP protocol adaptation layer, large model services with different protocols and scattered sources are standardized for access and unified management, solving the problem of chaotic integration.

[0017] 2. Support for stateful and complex interactions: Through an innovative context management module, persistent management of large-scale model interaction contexts is achieved, enabling traditional stateless enterprise buses to support stateful applications such as multi-turn dialogues and complex task flows.

[0018] 3. Enhance service governance efficiency and resilience: The unified service governance technology specifically designed for artificial intelligence services effectively addresses the performance fluctuations of large-scale model services through mechanisms such as intelligent routing and health checks, thereby improving the overall availability and performance of the services.

[0019] 4. Connecting large models with core enterprise assets: Through knowledge base and data center service modules, a secure and standardized channel is built, enabling large models to fully utilize the enterprise's internal private knowledge and data to generate greater business value, while ensuring data traceability and security.

[0020] 5. Enhanced system flexibility and scalability: The modular design and support for dynamic adaptation technologies such as function calls enable the system to flexibly and quickly integrate new large-scale model services or internal enterprise resources, exhibiting excellent scalability. Attached Figure Description

[0021] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This application provides a schematic diagram of the overall architecture of a large model context protocol implementation system based on an enterprise bus architecture, as shown in the embodiments of this application. Figure 2 A flowchart illustrating a method for implementing a large model context protocol based on an enterprise bus architecture, provided in this application embodiment; Figure 3 This is a timing diagram illustrating the signaling interaction between the modules in the embodiments of this application; Figure 4 This is a schematic diagram illustrating the principle of dynamic adaptation of the knowledge base in the embodiments of this application. Detailed Implementation

[0022] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0023] Example 1 This embodiment provides a system and its working method for implementing a large model context protocol based on an enterprise bus architecture. This embodiment aims to fully demonstrate how the system integrates and coordinates multiple heterogeneous artificial intelligence services to handle a complex end-to-end business process.

[0024] Figure 1 This is a schematic diagram of the overall architecture of a large model context protocol implementation system based on an enterprise bus architecture, provided for embodiments of this application. The system is built on an enterprise service bus 10. As the backbone network of the entire system, the enterprise service bus 10 provides a stable and reliable communication and integration foundation for the various service modules deployed on it. In physical implementation, the enterprise service bus 10 can consist of a cluster of high-performance servers running message middleware (e.g., Apache Kafka or RabbitMQ) and service mesh (e.g., Istio), and can be deployed in an enterprise's private cloud, public cloud, or hybrid cloud environment.

[0025] Specifically, the system includes multiple core functional modules mounted as independent services on the enterprise service bus 10, including: The MCP protocol adaptation layer 20 acts as a gateway for the system to interact with the external world. In an enterprise environment, there may be multiple external large model services 70 or calling applications from different sources and with different protocols. For example, one application may follow the OpenAI API specification protocol, while another may use a vendor's custom proprietary protocol. The core responsibility of the MCP protocol adaptation layer 20 is to shield these differences. It can receive these diverse Large Model Context Protocol (MCP) requests and uniformly convert them into the standardized Enterprise Bus message format within the Enterprise Bus. Correspondingly, after the internal service has completed its processing, the adaptation layer 20 is also responsible for converting the response message in the internal standard format back to the original MCP format expected by the calling party. This bidirectional conversion process ensures the "plug-and-play" capability of external services.

[0026] Unified Data Standards Module. It should be noted that the standards defined in this module are applied throughout the entire system, but... Figure 1The text is not marked as an independent box. This module defines a standardized data exchange format, named XInfo in this embodiment. XInfo is a structured data format based on JSON strings, and all messages flowing on the Enterprise Service Bus 10 follow this format. A typical XInfo message body contains not only business data payloads but also a system attribute object to carry metadata, such as the message's unique identifier, timestamp, source service, and destination service. As a preferred implementation, this system attribute object may also contain encryption and signature-related fields. Specifically, the system can be configured to process all messages containing sensitive information flowing within the bus. The sending service can encrypt the business data payload of the message using a pre-shared key or an asymmetric encryption algorithm, and indicate the algorithm and key identifier used in the encryption field. Simultaneously, the sender can calculate a digital signature for the entire message or its key parts, and place the signature value and signature algorithm in the signature field. Upon receiving the message, the receiving service first verifies the signature to ensure the message's integrity and source credibility, and then decrypts it using the corresponding key, thereby ensuring the security of data during internal flow.

[0027] The Unified Service Governance Technology Module 30 acts as a "traffic control center" to ensure the efficient and stable operation of numerous AI services (especially large model services) on the bus. This module provides a dynamic service registration and discovery mechanism. Upon startup, any AI service (such as large model inference service or vector retrieval service) registers its service name, version, network address, currently supported protocol types, and health status with this module 30. The Unified Service Governance Technology Module 30 maintains a real-time updated service registry. When a request needs to invoke a service, this module 30 can search the registry for all available service instances based on the requested service name. Furthermore, this module 30 implements intelligent routing strategies based on service load and performance. It continuously monitors performance metrics such as CPU / GPU utilization, memory consumption, request queue length, and response latency for each service instance. When routing requests, it selects the optimal service instance to handle the request based on preset strategies (such as round-robin, least connections, or weighted routing based on comprehensive performance scores), thereby achieving load balancing, preventing overload of a single instance, and improving the overall throughput and response speed of the system.

[0028] Context Management Module 40. As a core component designed in this application to solve the problem of "stateful" interactions in large models, Context Management Module 40 is specifically responsible for capturing, maintaining, and transmitting this context state information. Traditional enterprise service buses are inherently stateless, while large models heavily rely on historical interaction information, i.e., context, when handling scenarios such as multi-turn dialogues and complex task decomposition. This module is configured to check whether the current request requires historical context before the unified service governance technology module 30 routes the message to the target service. If so, it will recover the relevant context information from its managed persistent storage (such as a high-speed key-value database Redis or a document database MongoDB) based on the associated task identifier (such as session ID or process instance ID) carried in the request, and append it to the message to be sent to the target service. When the target service completes processing and returns a response, the response may contain updated context information that needs to be retained. At this time, Context Management Module 40 will intervene again, parse out these new contexts, associate them with the same associated task identifier, and store them in persistent storage for subsequent calls. Through this "recover before call, store after call" mechanism, the system endows the stateless bus architecture with the ability to maintain the state of long-term, complex tasks.

[0029] The enterprise resource access module consists of a knowledge base MCP service module 50 and a data center MCP service module 60. These two modules serve as standardized gateways connecting large models with the enterprise's core assets (i.e., knowledge and data). Enterprises often possess massive amounts of knowledge and data stored in various formats, such as technical documents on file servers, business data in databases, and analytical reports in data warehouses; these are collectively referred to as internal enterprise resources 80. The knowledge base MCP service module 50 is responsible for encapsulating unstructured or semi-structured knowledge resources (such as document libraries and work order systems) into standard services. The data center MCP service module 60 is responsible for encapsulating structured data resources (such as databases from data platforms and business systems) into standard data services. When external applications or other large internal models need to access these private enterprise resources, they do not need to concern themselves with the physical location, storage format, or access protocol of the underlying resources; they only need to call the standardized services provided by these two modules through the enterprise service bus 10. This approach greatly simplifies the complexity of the call and facilitates unified access control, access auditing, and traffic monitoring.

[0030] Below, we will combine Figure 2 The method shown in the flowchart and Figure 3 The signaling interaction timing diagram shown illustrates the working method of the system in this embodiment using a specific application scenario of a cold rolling production line in the steel industry.

[0031] The goal of this scenario is to achieve automated detection of surface defects in steel plates and intelligent optimization of production processes. The system integrates two external large-scale model services 70, each provided by different manufacturers: a "quality inspection intelligent agent" (based on computer vision) and a "process optimization intelligent agent" (based on expert knowledge and data analysis). Simultaneously, the enterprise's "production database" is connected to the system through the data center MCP service module 60.

[0032] The entire processing flow begins with step S101: receiving an MCP request. When a camera on the production line captures an image of a new steel plate, the edge computing device or the host computer triggers a call to the "quality inspection agent." This call request is sent to the system's unified entry point, i.e., the MCP protocol adaptation layer 20, in a private MCP protocol format supported by the "quality inspection agent" (e.g., an HTTP POST request containing image data and metadata). Figure 3 As shown, this corresponds to the first message 1. query() sent by the external application to the MCP adaptation layer.

[0033] Subsequently, in step S102, the MCP protocol adaptation layer 20 performs protocol conversion. Upon receiving the request, it parses the private HTTP request according to the pre-configured adapter plugin, extracting key information such as image data, steel plate batch number, and production time. Then, following the aforementioned XInfo data standard, it assembles this information into a standardized JSON message. This process corresponds to... Figure 3 The internal action 2. to_xinfo(). For example, the generated XInfo message can be shown as: { "header": { "message_id": "uuid-1234-abcd", "timestamp": "2023-10-27T10:00:00Z", "target_service": "quality_inspection_agent" }, "payload": { "batch_id": "BATCH-20231027-001", "image_data": "base64_encoded_image_string..." }, "system_attributes": { "encryption": { "enabled": false}, "signature": { "enabled": false} } } After message standardization, step S103, or context recovery, is executed. The MCP protocol adaptation layer 20 publishes the standardized XInfo message to the Enterprise Service Bus 10. As a processor in the message flow path, the context management module 40 intercepts this message. It parses the message payload, finds it contains a batch_id, and uses this batch_id as the associated task identifier to query its persistent storage for historical context related to this batch of steel plates. For example, the previous process may have performed a preliminary thickness check on this batch of steel plates, and the result is stored as context. If a relevant context is found (e.g., {"thickness": "2.05mm"}), the context management module 40 merges this context information into the payload of the XInfo message. This corresponds to... Figure 3 The interactions in the code are 3. get_context() and 4. context_data.

[0034] The process then proceeds to step S104: Service Routing. An XInfo message carrying the possible context is passed to the unified service governance technology module 30. This module parses the `target_service` field in the message header and learns that the `quality_inspection_agent` service needs to be called. It immediately queries the service registry and finds that two instances of this service are currently running. By querying real-time monitoring data, it finds that instance A's GPU utilization has reached 95%, while instance B's utilization is only 30%. Based on the "lowest load first" routing strategy, module 30 decides to route the request to instance B and returns the network address of instance B. This corresponds to... Figure 3 The interactions in the code are 5. find_service() and 6. service_endpoint.

[0035] Subsequently, in step S105, the target service is invoked. The MCP protocol adaptation layer 20 (or a routing component on the bus) forwards the XInfo message to instance B of the "quality inspection agent" based on the address returned by the governance module. Before sending, a protocol conversion may be required to convert the XInfo format back to a proprietary format that the agent can understand. Agent B receives the request, completes the analysis of the steel plate image, and discovers a "surface scratch" type defect. It then generates analysis results containing the defect type, location coordinates, and severity level.

[0036] After the analysis results are returned, step S106 is executed: context persistence. The results are first converted into XInfo format and transmitted on the bus. The context management module 40 intercepts this message again, identifies it as an intermediate result of the BATCH-20231027-001 task, and associates the new information "surface scratches" with the batch_id, updating it in the persistent storage. This corresponds to... Figure 3 The message in Message 11. save_context().

[0037] In this scenario, the business process is not yet complete. After detecting a defect, the "quality inspection agent" internally determines that it needs to trigger the "process optimization agent" to provide adjustment suggestions. Therefore, it initiates a new service call request via the bus, targeting the `process_optimization_agent`. The payload of this new `XInfo` request will contain the defect information that was just detected.

[0038] The system executes steps S104 and S105 again. The Unified Service Governance Technology Module 30 finds an available "Process Optimization Agent" instance and invokes it. To provide accurate suggestions, the "Process Optimization Agent," upon receiving the request, needs to query the real-time operating parameters of the current cold rolling production line (such as rolling force, speed, tension, etc.). To do this, it initiates a call request to the Enterprise Service Bus 10 with the target service being datacenter_service, specifying the parameters to be queried and the steel plate batch number.

[0039] The data center MCP service module 60 receives this request. Acting as a data service gateway, it translates the request into one or more SQL queries against the backend "production database." After executing the queries, it obtains real-time process parameters and returns them to the "process optimization agent" in XInfo format.

[0040] After obtaining defect information and real-time process parameters, the "process optimization agent" runs its internal optimization algorithm and finally generates a process adjustment suggestion, such as "increase the tension of No. 5 mill by 5%".

[0041] Finally, the process proceeds to steps S107 and S108: response transformation and response return. This final process recommendation is transmitted on the bus as a response message and may eventually be sent to the factory's Manufacturing Execution System (MES). The MCP protocol adaptation layer 20 captures this final response and, based on the adapter configured for the MES system, converts it into a format that the MES can receive (e.g., a specific XML or SOAP message), and then sends it out through the appropriate interface, completing the entire loop.

[0042] In this embodiment, the system successfully integrates two AI agents with different protocols, an enterprise database, and a production execution system seamlessly. Through the context management module 40, the automatic and stateful flow from quality inspection results to process optimization decisions is achieved, ensuring the timeliness and accuracy of the decisions. The entire process is scheduled and monitored by the unified service governance technology module 30, ensuring service stability and efficiency, fully demonstrating the application value of this solution in complex industrial scenarios.

[0043] Example 2 This embodiment highlights the system's flexibility and scalability in knowledge management, specifically illustrating how the knowledge base MCP service module 50 utilizes function call technology to achieve "zero-code" dynamic access to newly added knowledge bases.

[0044] Figure 4 This is a schematic diagram illustrating the principle of dynamic adaptation of the knowledge base in this embodiment. The core of this principle lies in the fact that the knowledge base MCP service module 50 internally maintains a function description registry 51. This registry can be a database table, a configuration file, or an in-memory hash table, storing metadata descriptions of all APIs connected to the knowledge base. These descriptions are not code, but rather natural language and structured descriptions of function functionalities following a specific JSON format.

[0045] In this embodiment, a company has built an intelligent question-and-answer application based on the system described in this application. Initially, the application only integrated the company's internal technical document library, and its API (internal document library API 52) has been registered in the function description registry 51. Now, the company wants to also use shared documents from the external "Kingsoft Cloud Documents" platform as knowledge sources for the question-and-answer system, and hopes to complete the integration in the fastest and simplest way.

[0046] The specific workflow is as follows: First, the administrator registers the function. The administrator does not need to write any adaptation code; they only need to log in to the system's management backend interface and find the configuration page for the Knowledge Base MCP service module 50. On this page, they create a new function description for the "Kingsoft Cloud Documents" search API. This operation corresponds to... Figure 4 The interaction "1. Register Function" is described as a JSON object, as shown in the example below: { "function_name": "search_kingsoft_docs", "description": "Search for relevant content in Kingsoft Cloud's enterprise shared documents. Suitable for finding the latest product manuals, installation guides, and project solutions." "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "The keywords or questions you need to search for, such as 'XX model server installation guide'" }, "limit": { "type": "integer", "description": "Maximum number of document fragments returned, defaults to 3" } }, "required": ["query"] } } After the administrator submits the JSON object, the system will save it in the function description registry 51. At the same time, the administrator also needs to associate the search_kingsoft_docs function name with the URL, authentication token, and other information required to actually call the Kingsoft Cloud Document API (Kingsoft Cloud Document API 53) in another security configuration area.

[0047] Then, when a user asks a question, the Large Model (LLM) identifies and decides to invoke the function. An employee asks the front-end interface of the intelligent question-answering system: "How do I configure the latest XX model server? Please refer to the installation guide on Kingsoft Cloud." This request, through modules such as the MCP protocol adaptation layer 20, is ultimately routed to a Large Model service 70, which serves as the core of the question-answering process. When invoking this Large Model, the system not only sends the user's original question but also automatically retrieves all registered function descriptions (including the newly registered `search_kingsoft_docs`) from the function description registry 51 and sends these descriptions as part of the request to the Large Model. This operation corresponds to... Figure 4 The interaction "2. Query Available Functions" in the code. Upon receiving the request, the large model simultaneously understands the user's intent and its available "tools" (i.e., a list of functions). It analyzes the phrase "...refer to the installation guide on Kingsoft Cloud" in the user's question and compares it with the description of `search_kingsoft_docs`: "Search in Kingsoft Cloud Enterprise Shared Documents...", thus determining that the `search_kingsoft_docs` function must be called to answer the question. Therefore, the large model does not directly generate an answer but instead generates a JSON object requesting a function call to instruct the system to execute the specified function. This operation corresponds to... Figure 4The interaction "3. Generate function call request" in the code can be exemplified as follows: { "tool_calls": [{ "type": "function", "function": { "name": "search_kingsoft_docs", "arguments": "{\"query\": \"XX Model Server Installation Guide\"} } }] } Next, the system executes the function call. This JSON object containing the function call instructions is returned to the system as the "response" of the large model. The Knowledge Base MCP Service Module 50 (or MCP Protocol Adaptation Layer 20) captures and parses this special response. When it detects the `tool_calls` field, it knows that this is not the final answer, but an execution instruction. Module 50 extracts the function name `search_kingsoft_docs` and the parameter `{"query": "XX Model Server Installation Guide"}`, and finds the URL and authentication information of the corresponding Kingsoft Cloud Documentation API 53 in its internal configuration based on the function name, thereby constructing a real HTTP request to call Kingsoft Cloud's search API. This operation corresponds to... Figure 4 The interaction in the document is "4. Execute API calls".

[0048] Finally, the results are returned and a final answer is generated. The Kingsoft Cloud Document API returns search results, such as several of the most relevant document excerpts. The Knowledge Base MCP service module 50 organizes this document content and constructs a new request to call the core model again. This request is roughly as follows: "This is the user's question: '…', and this is the result returned by the search_kingsoft_docs function you requested: '…[document content]…'. Now, please answer the user's question based on this information." Upon receiving this request containing contextual information (the original question and the retrieved knowledge), the core model can synthesize all the information and generate a detailed and accurate answer, such as: "To configure the latest XX model server, according to the installation guide on Kingsoft Cloud, you need to perform the following steps: 1. … 2. …". This final answer is returned via the bus and ultimately presented to the user.

[0049] In this embodiment, the system successfully integrates a new external knowledge base into the intelligent application through simple backend configuration without modifying its own code or developing and deploying any adapters for the new knowledge source. This greatly enhances the system's flexibility and scalability, reduces operational costs, and enables enterprises to quickly respond to business changes and integrate more valuable knowledge resources.

[0050] Example 3 This embodiment aims to illustrate an optional implementation method for processing time-consuming asynchronous tasks. By introducing an event-driven architecture pattern, it achieves decoupling between services and improves user experience and overall system throughput.

[0051] In many enterprise scenarios, tasks involving large models cannot be completed instantaneously. For example, generating a "quarterly sales data analysis report" may involve extracting large amounts of raw data from databases of multiple business systems (such as CRM and ERP), cleaning and analyzing the data, calling large model services to generate natural language summaries, and finally integrating them into a report file. The entire process may take several minutes or even longer. If a traditional synchronous request / response model is used, users must wait for a long time after clicking "Generate Report" on the front-end interface, which not only leads to a poor user experience but also consumes front-end and back-end connection resources for an extended period.

[0052] As an optional implementation, the system provided in this embodiment optimizes this process by combining message center technology and event management technology. Here, "message center" can be considered a specific implementation or a core component of the Enterprise Service Bus 10, providing the ability to publish / subscribe to messages.

[0053] The asynchronous processing flow may include the following steps: First, submit the task and publish the first event. After setting the report generation parameters in the web frontend or client application, the user clicks the "Generate Report" button. The frontend service (or API gateway) receiving the request determines that the task type is marked as asynchronous, or estimates that its processing time will exceed a preset threshold (e.g., 30 seconds) based on the task parameters. At this time, the frontend service does not need to wait for the task to complete and can immediately return an instant response to the user that "the task has been submitted and is being processed," allowing the user to close the page and continue with other work. Simultaneously, the frontend service constructs a "first event" (a JSON-formatted message) describing the task and publishes it to a specific topic in the message center, such as `report.generation.request`. This event message contains all the information needed to complete the task, such as: { "event_id": "evt-uuid-5678", "event_type": "ReportGenerationRequested", "timestamp": "2023-10-27T11:00:00Z", "payload": { "user_id": "user-007", "report_type": "QUARTERLY_SALES_ANALYSIS", "params": { "quarter": "Q3", "year": 2023, "region": "East China" } } } Second, background services subscribe to and process events asynchronously. One or more dedicated "report generation service" instances are deployed in the system. These services, acting as background workers, subscribe to the `report.generation.request` topic from the message center upon startup. When the aforementioned first event is published, the message center pushes it to an idle "report generation service" instance. Upon receiving the event message, this service instance asynchronously executes the specific logic for report generation in the background. This process fully utilizes other modules provided by the system: the "report generation service" securely retrieves data from multiple data sources by calling the data center MCP service module 60 via the Enterprise Service Bus 10 based on the event parameters; after completing local data processing and analysis, it constructs a request to call the large model service 70 to generate a text summary. Because these steps are all executed in the background, they do not block any user-facing services.

[0054] Third, the task is completed and a second event is published. After several minutes of processing, the large model returns the generated text summary. The "Report Generation Service" combines the data, charts, and text summary into a complete PDF report file, uploads it to the internal file storage system, and provides a download link. At this point, the core part of the task is complete. The service then constructs a "second event" (i.e., the task completion event) and publishes it to another topic in the message center, such as `report.generation.complete`. This event message contains information about the task's results: { "event_id": "evt-uuid-9101", "event_type": "ReportGenerationCompleted", "timestamp": "2023-10-27T11:05:00Z", "payload": { "user_id": "user-007", "original_event_id": "evt-uuid-5678", "status": "SUCCESS", "result": { "report_name": "2023 Third Quarter East China Sales Analysis Report.pdf", "download_url": "https: / / internal-storage / path / to / report.pdf" } } } Fourth, result notification. The system also includes a lightweight notification service that subscribes to the `report.generation.complete` topic. Upon receiving the second event mentioned above, it parses the user information and report download link, then sends a notification to the user via email, enterprise instant messaging tools, or mobile app push notifications, informing them that the report has been generated and providing a link.

[0055] By employing this asynchronous event-driven model, the system successfully decouples time-consuming background tasks from front-end user interaction, providing users with immediate responses and significantly improving their experience. Simultaneously, the system achieves loose coupling between services through a message center; for example, the "report generation service" and "notification service" are independent of each other, allowing for independent scaling, deployment, and maintenance. This architecture makes the system more robust, better able to handle sudden surges in high-concurrency requests, and improves overall resource utilization and processing efficiency.

[0056] Example 4 This embodiment focuses on the advanced functions of the knowledge base MCP service module 50, and elaborates on how the system improves the accuracy and comprehensiveness of knowledge retrieval through hybrid retrieval technology, and achieves accurate tracing of answer sources in conjunction with the context management module 40, thereby providing highly reliable information for decision support in professional fields.

[0057] The scenario is set as follows: an equipment maintenance engineer is using a Retrieval Enhancement Generation (RAG) agent built based on the system described in this application to troubleshoot a complex equipment fault. The enterprise's knowledge base contains both a structured "equipment fault code library" (stored in a relational database) and a large number of unstructured "historical maintenance work orders" (stored in text document format).

[0058] Its workflow may include the following steps, and can be referenced. Figure 3 The general interaction sequence is as follows: First, the engineer initiates a complex hybrid query. The engineer enters the question in the agent's dialog box: "What does device alarm code E-1023 mean? Also, could you please check how this problem was resolved last time it occurred?" This request is sent to the system and ultimately passed to the knowledge base MCP service module 50.

[0059] Second, a hybrid retrieval mode is initiated. The query parser inside the knowledge base MCP service module 50 analyzes the question and identifies that it contains two subqueries with different intentions: an exact search request for "E-1023" (a typical structured data query), and a fuzzy, semantically related search request for "how was it solved last time" (a typical unstructured information retrieval). Based on this analysis, module 50 decides to initiate a "hybrid retrieval" mode, executing the two different types of retrieval in parallel.

[0060] Third, perform a precise full-text search or database query. For the first subquery, "What does alarm code E-1023 mean?", the system routes it to a retrieval path that processes structured data. This path directly accesses the "Equipment Fault Code Library" encapsulated by the data center MCP service module 60 and executes a query similar to SELECT description FROM fault_codes WHERE code = 'E-1023'. This precise match query targeting a specific field can be considered a special type of full-text search, and it quickly returns the result: "Main hydraulic pump pressure sensor signal abnormality".

[0061] Fourth, perform parallel semantic retrieval. For the second subquery, "How was this problem solved last time?", the system routes it to a semantic retrieval path that processes unstructured data. Understandably, for semantic retrieval, the knowledge base MCP service module 50 has pre-processed all "historical maintenance work order" documents. Specifically, it intelligently segments the text content of each work order (especially the fault description and solution sections), uses a text embedding model to convert each text block into a high-dimensional mathematical vector, and stores these vectors in a dedicated vector database. Now, for retrieval, the system first needs to understand the semantics of the query. Here, the context management module 40 plays a crucial role. Although it's the same user request, semantic retrieval needs to know what "this problem" specifically refers to. Through interaction with the context management module 40, the system learns that the context of the current session is "E-1023" and its corresponding "main hydraulic pump pressure sensor signal abnormality". Therefore, the core query content of the semantic retrieval is determined to be "solution to the main hydraulic pump pressure sensor signal abnormality". The knowledge base MCP service module 50 uses the same text embedding model to convert the core query content into a query vector. This query vector is then used to perform a similarity search in the vector database to find the semantically closest historical work order text blocks. For example, if the search result matches a repair record with work order number "WX20230815-002", the relevant text fragment is: "...the pressure sensor of the main hydraulic pump (part number S-9527) was replaced, and the system was recalibrated. Fault alarm E-1023 was cleared...".

[0062] Fifth, result merging and information synthesis. At this point, the knowledge base MCP service module 50 has obtained results from two parallel retrieval paths: one is a precise fault description from the database, and the other is semantically relevant historical solution text from vector retrieval. The system merges these two pieces of information as a response to the target service. The merged information is constructed into a rich context, ready to be submitted to the large model for final answer generation. This process is also coordinated by the context management module 40 to ensure that the large model knows that both pieces of information originate from the same user's same initial question.

[0063] Sixth, generate a traceable answer. The merged information, along with the original question, is sent to a large model service 70. The request can be summarized as: "User asks: 'What does equipment alarm code E-1023 mean? How was this problem resolved last time?' According to the internal knowledge base, we know: 1. The standard definition of E-1023 is 'abnormal signal from the main hydraulic pump pressure sensor.' 2. A relevant historical maintenance record (source: work order WX20230815-002) shows that the solution was 'replace the sensor and recalibrate it.' Based on the above information, please generate a clear and actionable answer for the engineer." After receiving this clearly structured and information-rich prompt, the large model service 70 can easily generate a high-quality answer while retaining the source metadata of the information.

[0064] Finally, the answer returned to the engineer via MCP protocol adapter layer 20 can be exemplified as follows: "Equipment alarm code E-1023 represents 'Main hydraulic pump pressure sensor signal abnormality.' According to historical maintenance records (work order number: WX20230815-002), the last time this problem occurred, technicians resolved it by replacing the pressure sensor and recalibrating it. We recommend that you: 1. Check if the electrical connection of the current pressure sensor is secure. 2. If the connection is normal, consider replacing the pressure sensor." In this example, the "Work Order Number: WX20230815-002" in the answer can be rendered as a clickable hyperlink on the front-end interface. When the engineer clicks this link, the system can directly invoke the corresponding service and open the original repair work order details page for more comprehensive information. This achieves precise traceability of the answer, greatly enhancing the credibility of the information provided by the intelligent agent.

[0065] This embodiment leverages a hybrid retrieval strategy, fully utilizing the strengths of both structured and unstructured data within an enterprise, to provide far more comprehensive and accurate knowledge support than a single retrieval mode. Combined with context management and source tracing mechanisms, it ensures that the final answer is not only accurate but also reliable and verifiable, providing robust support for complex decision-making and problem-solving in specialized fields.

[0066] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0067] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A large model context protocol implementation system based on an enterprise bus architecture, characterized in that, include: Enterprise bus architecture serves as the backbone network for inter-service communication and integration; The MCP protocol adaptation layer, deployed on the enterprise bus architecture, is used to receive external large model context protocol requests, convert the requests into the enterprise bus message format inside the enterprise bus, and convert the responses inside the enterprise bus into the large model context protocol format. The unified data standard module is used to define a standardized data exchange format based on JSON strings for inter-service communication within the enterprise bus architecture. The unified service governance module is used to receive messages converted by the MCP protocol adaptation layer, and to provide a dynamic registration and discovery mechanism for artificial intelligence services, as well as an intelligent routing strategy based on service load, to route the messages to the target service. The context management module is configured to restore the historical context state information associated with the message before the unified service governance module routes the message to the target service, and to persistently store the updated context state information after receiving the response from the target service. The enterprise resource access module includes a knowledge base MCP service module and a data center MCP service module. As the target service, it is used to encapsulate the enterprise's internal knowledge base and data center into standardized bus services for invocation.

2. The system according to claim 1, characterized in that, The context management module is configured as follows: Before routing the request to the target AI model through the unified service governance module, restore the historical context state information associated with the request; and After receiving the response from the target AI model, the updated context state information is persistently stored.

3. The system according to claim 1, characterized in that, The knowledge base MCP service module is configured as follows: Receives and stores the interface definition of an external knowledge base defined in function call format.

4. The system according to claim 1, characterized in that, The knowledge base MCP service module is also configured as follows: The knowledge content is vectorized, and at least one of semantic retrieval, full-text retrieval, and hybrid retrieval is performed based on the results of the vectorization.

5. The system according to claim 1, characterized in that, The unified service governance module is also configured to support version management and canary releases of artificial intelligence services; and... The system is configured to process messages that contain encryption and signature attributes and conform to the standardized data exchange format within the enterprise bus architecture.

6. A method for implementing a large model context protocol based on an enterprise bus architecture, characterized in that, The system based on claim 1 includes the following steps: The received large model context protocol request is converted into a standardized message based on JSON strings within the enterprise bus. Before invoking the target AI model, restore the historical context state information associated with the request; Based on the dynamic registration information of the artificial intelligence service and the intelligent routing strategy based on service load, the target service is determined and invoked. When the request requires access to enterprise resources, the target service is the knowledge base MCP service module or the data center MCP service module. Upon receiving the response from the target service, the updated context state information is persistently stored. The response is converted to the Large Model Context Protocol format and returned.

7. The method according to claim 6, characterized in that, The step of restoring historical context state information specifically includes: retrieving the corresponding context state information from persistent storage based on the associated task identifier of the request; The step of persistently storing the updated context state information specifically includes: associating the state that needs to be retained in the response with the associated task identifier and storing it in the persistent storage.

8. The method according to claim 6, characterized in that, When the target service is a knowledge base MCP service module, the method further includes: The application programming interface (API) of the external knowledge base is pre-registered as an interface definition in function call format; The steps of invoking the target service specifically include: receiving a function call request generated by an artificial intelligence model for the interface definition; and invoking the API of the external knowledge base according to the function call request.

9. The method according to claim 6, characterized in that, When the request requires access to the knowledge base MCP service module, the steps of invoking the target service include: If the request contains both structured and unstructured query content, then full-text search and semantic search are performed in parallel on the knowledge base; and The results of full-text search and semantic search are combined and used as the response to the target service.

10. A method for implementing a large model context protocol based on an enterprise bus architecture, characterized in that, The system based on claim 1 includes the following steps: When a request is marked as an asynchronous processing task, or when its estimated processing time exceeds a preset threshold, the request is converted into a first event and published to the message center. The first event is subscribed to and processed asynchronously by a background service to complete the task; and After the task is completed, publish a second event containing the task results.

Images