Private domain knowledge dynamic updating method and system for MCP protocol

Abstract

The invention relates to the technical field of private domain knowledge updating, and discloses an MCP protocol-oriented private domain knowledge dynamic updating method and system, which monitor the change of a private domain knowledge source in real time through an updating agent component, and calculate a hierarchical hash abstract to efficiently detect a change event. Once the change is found, the change is compared with the root hash which is successfully notified last time, and if the change is different from the root hash which is successfully notified last time, an update notification is sent to a knowledge update service component through an MCP protocol. And after confirming the root hash difference, the receiving end requests the increment message to obtain the specific change content. And then, the updating agent component accurately locates the changed knowledge unit, extracts an incremental data packet and transmits the incremental data packet to the knowledge updating service component for application through an MCP protocol. Therefore, not only are unnecessary network bandwidth and computing resource consumption greatly reduced, but also the real-time performance and accuracy of data updating are remarkably improved, and powerful support is provided for efficient decision making of enterprises.

Description

Technical Field

[0001] The present application relates to the technical field of private domain knowledge update, and more specifically, to a method and system for dynamically updating private domain knowledge for the MCP protocol. Background Art

[0002] With the rapid development of information technology and the explosive growth of data, various industries are placing increasingly stringent demands on the management and utilization of private knowledge. As core assets of enterprises or specific organizations, private knowledge bases contain crucial information such as business rules, technical specifications, and case studies. Their timeliness and accuracy directly impact decision-making efficiency and operational quality. However, traditional knowledge base maintenance and update mechanisms have exposed numerous limitations and shortcomings in the face of an increasingly dynamic knowledge environment.

[0003] Currently, most knowledge base updates, unless manual intervention is required, often employ a full synchronization strategy. This means that even minor changes to the knowledge base require the entire knowledge system to be retransmitted, parsed, and even replaced. This full synchronization model results in significant resource consumption in scenarios with large knowledge bases and frequent changes. First, a vast amount of network bandwidth is occupied by unnecessary data transmission, significantly increasing system response latency. Second, the receiving end must devote significant computing resources to processing and storing this duplicate data, increasing server load and reducing overall system efficiency. More critically, frequent full synchronization operations not only waste precious computing and storage resources but can also result in excessively long data update windows, making them incapable of meeting the requirements of business scenarios with high real-time requirements, thereby impacting decision-making based on the latest knowledge. Summary of the Invention

[0004] In order to solve the above technical problems, the present application is proposed. The embodiments of the present application propose a method and system for dynamically updating private domain knowledge for the MCP protocol.

[0005] According to one aspect of the present application, a method for dynamically updating private domain knowledge based on the MCP protocol is provided, comprising: after an update agent component detects a change event of a private domain knowledge source, calculating an updated private domain knowledge source hierarchical hash digest and outputting a real-time change event stream; the update agent component compares the new root hash in the updated private domain knowledge source hierarchical hash digest with the root hash of the last successful notification to the knowledge update service component, and if they are different, sending an update available notification to the knowledge update service component through the MCP protocol; after receiving the update available notification, the knowledge update service component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash digest it currently holds, and if they are different, sending a request increment message to the update agent component through the MCP protocol; after receiving the request increment message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts an incremental data packet from it, and then sends a knowledge increment message to the knowledge update service component through the MCP protocol; after receiving the knowledge base increment message, the knowledge update service component extracts the incremental data packet from the knowledge increment message and applies it to the private domain knowledge base.

[0006] In one possible implementation, after the update agent component detects a change event of the private domain knowledge source, it calculates the updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream, including: the update agent component captures the change event of the private domain knowledge source through the file system event monitoring mechanism of the operating system; or, the update agent component captures the change event of the private domain knowledge source through the CDC mechanism of the database.

[0007] In one possible implementation, after the update agent component detects a change event of the private domain knowledge source, it calculates the updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream, including: based on the change event, locating the corresponding leaf node in the private domain knowledge source hierarchical hash summary, and calculating the hash of the leaf node; when tracing back to the root of the tree along the leaf node, calculating the hash of each intermediate node on the path to obtain the updated private domain knowledge source hierarchical hash summary.

[0008] In one possible implementation, after receiving the request increment message, the update proxy component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet therefrom, including: locating the specific knowledge unit that has changed based on a comparison between the private domain knowledge source hierarchical hash digest currently held in the request increment message and the updated private domain knowledge source hierarchical hash digest; and extracting the incremental data packet from the specific knowledge unit that has changed.

[0009] In one possible implementation, based on the comparison between the currently held private domain knowledge source hierarchical hash digest in the request incremental message and the updated private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is located, including: comparing the currently held private domain knowledge source hierarchical hash digest with the root hash in the updated private domain knowledge source hierarchical hash digest; if the root hash is different, comparing the sub-directory hash in the currently held private domain knowledge source hierarchical hash digest with the updated private domain knowledge source hierarchical hash digest; if the sub-directory hash is different, comparing the file hash in the currently held private domain knowledge source hierarchical hash digest with the updated private domain knowledge source hierarchical hash digest to obtain a positioning result, and the positioning result is the specific knowledge unit that has changed.

[0010] In one possible implementation, if the sub-directory hashes are different, a downward comparison is made between the file hash in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest to obtain a positioning result, including: if the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is marked as modified to obtain a change unit operation identifier; if it exists in the currently held private domain knowledge source hierarchical hash digest but does not exist in the updated private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is marked as deleted to obtain a change unit operation identifier; if it exists in the updated private domain knowledge source hierarchical hash digest but does not exist in the currently held private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is marked as newly added to obtain a change unit operation identifier.

[0011] In one possible implementation, if the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is marked as modified to obtain a change unit operation identifier, including: calculating a first existence probability that the file hash exists in the currently held private domain knowledge source hierarchical hash digest; calculating a second existence probability that the file hash exists in the updated private domain knowledge source hierarchical hash digest; calculating the joint correspondence cardinality of the first existence probability and the second existence probability relative to each other to obtain a first joint correspondence cardinality and a second joint correspondence cardinality; based on the first joint correspondence cardinality and The second joint correspondence cardinality is used to construct a joint cardinality cross-linking value; based on the first joint correspondence cardinality and the joint cardinality cross-linking value, the first existence probability is closely associated and optimized to obtain an optimized first existence probability; based on the second joint correspondence cardinality and the joint cardinality cross-linking value, the second existence probability is closely associated and optimized to obtain an optimized second existence probability; the existence probability difference between the optimized first existence probability and the optimized second existence probability is calculated, and it is determined whether the existence probability difference is within a preset range. If so, it is determined that the file hash exists in both the currently held private domain knowledge source hierarchical hash summary and the updated private domain knowledge source hierarchical hash summary.

[0012] In one possible implementation, after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base, including: extracting the change unit operation identifier from the knowledge base incremental message; generating a knowledge base change operation verification result based on a comparison between the real-time change event stream and the change unit operation identifier; in response to the knowledge base change operation verification result being a passed verification, extracting the incremental data packet from the knowledge incremental message, and performing format and integrity verification on the incremental data packet to obtain a content verification result; in response to the content verification result being a passed verification, applying the incremental data packet to the private domain knowledge base in combination with the change unit operation identifier.

[0013] According to another aspect of the present application, a private domain knowledge dynamic update system for the MCP protocol is provided, which is used to execute the above-mentioned private domain knowledge dynamic update method for the MCP protocol, including: a private domain knowledge change flow processing module, which is used to calculate the updated private domain knowledge source hierarchical hash summary and output a real-time change event stream after the update agent component detects the change event of the private domain knowledge source; a root hash comparison notification module, which is used for the update agent component to compare the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification of the knowledge update service component, and if they are different, send an update available notification to the knowledge update service component through the MCP protocol; a root hash comparison and update triggering module, which is used to receive the updated private domain knowledge source hierarchical hash summary and output a real-time change event stream; After receiving the update available notification, the knowledge update service component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash summary it currently holds. If they are different, a request increment message is sent to the update proxy component through the MCP protocol; an incremental data extraction module is used for, after receiving the request increment message, the update proxy component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet from it, and then sends the knowledge increment message to the knowledge update service component through the MCP protocol; a knowledge base incremental update processing module is used for, after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base.

[0014] Compared with the prior art, the method and system for dynamically updating private domain knowledge for the MCP protocol provided by this application monitors changes in the private domain knowledge source in real time through the update proxy component, and calculates the hierarchical hash digest to efficiently detect change events. Once a change is found, it is compared with the root hash of the last successful notification. If it is different, an update notification is sent to the knowledge update service component through the MCP protocol. After confirming the root hash difference, the receiving end requests an incremental message to obtain the specific change content. Subsequently, the update proxy component accurately locates the knowledge unit that has changed, extracts the incremental data packet, and passes it to the knowledge update service component through the MCP protocol for application. In this way, not only is unnecessary network bandwidth and computing resource consumption greatly reduced, but the real-time and accuracy of data updates are also significantly improved, providing strong support for efficient decision-making of enterprises. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other purposes, features, and advantages of the present application will become more apparent through a more detailed description of the embodiments of the present application in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0016] Figure 1The figure illustrates a schematic flow chart of a method for dynamically updating private domain knowledge based on the MCP protocol according to an embodiment of the present application.

[0017] Figure 2 The figure illustrates a schematic flow chart of step S4 in the method for dynamically updating private domain knowledge for the MCP protocol according to an embodiment of the present application.

[0018] Figure 3 The figure illustrates a schematic flow chart of step S41 in the method for dynamically updating private domain knowledge for the MCP protocol according to an embodiment of the present application.

[0019] Figure 4 The figure illustrates a schematic flow chart of step S5 in the method for dynamically updating private domain knowledge for the MCP protocol according to an embodiment of the present application.

[0020] Figure 5 The figure shows a schematic block diagram of a private domain knowledge dynamic update system for the MCP protocol according to an embodiment of the present application. DETAILED DESCRIPTION

[0021] Below, the exemplary embodiments according to the present application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application, and it should be understood that the present application is not limited to the exemplary embodiments described herein.

[0022] Figure 1 FIG2 shows a schematic flow chart of a method for dynamically updating private domain knowledge based on the MCP protocol according to an embodiment of the present application. Figure 1 As shown, the present application provides a private domain knowledge dynamic update method for the MCP protocol, including: S1: after the update agent component detects a change event of the private domain knowledge source, it calculates the updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream; S2: the update agent component compares the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification to the knowledge update service component. If they are different, an update available notification is sent to the knowledge update service component through the MCP protocol; S3: after receiving the update available notification, the knowledge update service component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash summary it currently holds. If they are different, a request increment message is sent to the update agent component through the MCP protocol; S4: after receiving the request increment message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet from it, and then sends a knowledge increment message to the knowledge update service component through the MCP protocol; S5: after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base.

[0023] Exemplarily, in step S1, after the update agent component detects a change event of the private domain knowledge source, it calculates the updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream. It should be understood that in traditional private domain knowledge update methods, there are often core drawbacks such as inefficiency, waste of resources and update delays. For example, some systems may use a periodic full scan method to detect changes in the knowledge base. This method not only consumes a lot of computing resources and I / O bandwidth, but also cannot provide real-time change perception capabilities due to the existence of the scanning cycle, resulting in the knowledge base being unable to reflect the latest status of the private domain knowledge source in a timely manner. Even if other systems try to perform partial incremental updates, they often have to perform coarse-grained data synchronization due to the lack of an accurate change detection mechanism, such as replacing an entire file or an entire database table, which also causes a large amount of unnecessary data transmission and processing load.

[0024] Based on this, the present application introduces a hierarchical hash summary and a real-time change event stream mechanism to overcome the above-mentioned defects. It provides an efficient, accurate and resource-friendly change detection and propagation paradigm. By updating the real-time capture of change events by the agent component, it is possible to be informed at the first moment of the slightest change in the knowledge source without the need for passive periodic detection. This active notification mechanism greatly improves the response speed of the update process. More importantly, combined with the calculation of the hierarchical hash summary, it is no longer necessary to compare the entire knowledge base byte by byte or record by record to find differences. Instead, by comparing the hierarchical hash values, the specific knowledge units that have changed can be quickly located, which lays the foundation for subsequent incremental data extraction and significantly reduces the amount of data processed by the system and the network transmission burden. Outputting the real-time change event stream ensures that relevant information can be delivered to the knowledge update service component in a timely and structured manner, driving subsequent incremental requests and update operations.

[0025] In one embodiment, after the update agent component detects a change event of a private domain knowledge source, it calculates an updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream, including: the update agent component captures the change event of the private domain knowledge source through the file system event monitoring mechanism of the operating system; or, the update agent component captures the change event of the private domain knowledge source through the CDC (Change Data Capture) mechanism of the database.

[0026] Specifically, the operating system file system event monitoring mechanism means that when private domain knowledge is stored in the file system in the form of files or directories, the update agent component will use the native event monitoring API provided by the operating system. For example, in Linux systems, you can use the inotify mechanism; in Windows systems, you can use the File System Watcher class; in macOS or BSD systems, you can use FSEvents. These APIs allow applications to register to monitor events such as modification, deletion, creation, and movement of specific directories or files. Once these operations occur in the file system, the operating system will immediately notify the registered listeners. After receiving such notifications, the update agent component can immediately identify changes in the knowledge source, thereby triggering the subsequent hash summary calculation process. This The database CDC mechanism applies when private domain knowledge is stored in a relational database, making file system listeners ineffective. In this case, the update agent component utilizes the database's CDC mechanism to capture changes. CDC is a software technology used to identify, capture, and communicate changes to data in a database. Its implementation varies. Specifically, the database CDC mechanism includes: Transaction log analysis: Many database systems (such as SQL Server CDC, Oracle LogMiner, PostgreSQL WALs, or MySQL Binlog) write data modifications to transaction logs. The update agent component can be configured to continuously read and parse these logs to capture insert, update, and delete operations. This approach is minimally invasive and provides high data consistency. Trigger-based: Triggers are set for database table addition, deletion, and modification operations. When data changes, the triggers automatically execute predefined actions, such as writing the change data to a separate change log table. The update agent component can read change information from this log table periodically or in real time. Built-in database CDC functionality: Some modern database systems provide built-in CDC functionality, such as MongoDB's Change Streams, which directly output changes in data streams. Through the CDC mechanism, the update agent component can accurately obtain the changes of each knowledge unit in the database and generate a corresponding real-time change event stream.

[0027] After capturing a change event, the core task of the update agent component is to accurately update the hierarchical hash digest of the private knowledge source and reflect it on the new root hash. This is similar to maintaining a Merkle tree, assuming that the private knowledge source is organized into a tree structure, such as directories and files in a file system, or a hierarchy of tables and records in a database. Each file or database record (or smaller knowledge unit) is considered a leaf node of the tree, and its hash value is calculated directly from its content. The hash value of an intermediate node such as a directory or table is calculated by combining the hash values of all its child nodes (including subdirectories / subtables and files / records). The top level of the tree is the root node, whose hash value (i.e., the root hash) represents the current state of the entire private knowledge source.

[0028] In one embodiment, after the update agent component detects a change event of the private domain knowledge source, it calculates an updated private domain knowledge source hierarchical hash summary and outputs a real-time change event stream, including: based on the change event, locating the corresponding leaf node in the private domain knowledge source hierarchical hash summary, and calculating the hash of the leaf node; when tracing back to the root of the tree along the leaf node, calculating the hash of each intermediate node on the path to obtain the updated private domain knowledge source hierarchical hash summary.

[0029] Specifically, when a change event is captured, the update proxy component first locates the corresponding leaf node in the private knowledge source's hierarchical hash summary based on the information provided by the event (such as the file path or database record ID). For a file change, if path / to / specific / file.txt is modified, the update proxy component reads the latest content of file.txt and calculates its new hash value (for example, using the SHA256 algorithm). If a new file.txt is created, its hash value is calculated and used as the new leaf node. If the old file.txt is deleted, the corresponding leaf node is marked as invalid or deleted. For a database record change, if a record (Record ID DXYZ) in a specific table is updated, the update proxy component reads the latest content of the record from the database and calculates its new hash value. If the record is newly added, its hash value is calculated and a new leaf node is created. If the record is deleted, the corresponding leaf node is marked as removed.

[0030] Next, we trace back upward and recalculate the hashes of intermediate nodes. It should be understood that whenever the hash of a leaf node changes (or is added or deleted), this change must be reflected back to the root of the tree. For example, if the hash of path / to / specific / file.txt changes, the hash of the directory specific containing file.txt must first be recalculated because it now contains a child node with a changed hash value. The hash of the specific directory is recalculated by combining the hashes of all its child files and subdirectories. Next, the hash of the `to` directory containing the specific directory is recalculated based on the change in the hash of the specific directory. This process continues upward along the unique path from the changed leaf node to the root of the tree. The hash of each intermediate node along the path (e.g., a parent directory or logical grouping) is recalculated based on the updated hash values of its child nodes, until the root hash is recalculated.

[0031] Through the above-mentioned layer-by-layer hash recalculation, the final new root hash fully reflects the latest state of the private knowledge source. This newly calculated updated private knowledge source hierarchical hash summary will be output along with the relevant real-time change event stream (including information such as change type and affected knowledge unit identifiers).

[0032] Exemplarily, in step S2, the update agent component compares the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification to the knowledge update service component. If they are different, an update availability notification is sent to the knowledge update service component through the MCP protocol. It should be understood that changes to private domain knowledge sources may be very frequent, and many times they are subtle, temporary, or the final result does not lead to a fundamental change in the overall state. For example, a file may be restored to its original state immediately after being briefly modified, or a series of operations may eventually cause the overall content hash value of the knowledge source to return to a previous state. If the update agent component immediately and unconditionally notifies the knowledge update service component every time an atomic change event in the file system or database is detected, a large amount of invalid communication will be generated. This invalid communication will not only take up valuable network bandwidth, but also impose unnecessary processing burden on the knowledge update service component, causing it to be frequently awakened to process notifications that may not represent actual valid knowledge updates. By comparing the new root hash with the root hash of the last successful notification, the system can effectively filter out these noises and send notifications to the knowledge update service component only when the overall logical state of the private domain knowledge source (uniquely identified by the root hash) changes substantially.

[0033] The root hash can be thought of as a digital fingerprint or snapshot ID of the private knowledge source at a specific point in time. It succinctly represents the current content and structure of the entire knowledge base. By comparing the proxy component's last successfully notified root hash with the current, most recent root hash, the proxy component confirms whether any noteworthy changes have occurred in the knowledge source since the service component was last notified of a specific state. If the root hashes are identical, this means there are no unsynchronized, substantive differences between the private knowledge source summary currently held by the service component and the latest state known to the proxy component (ignoring any recent transitional changes within the proxy component that have not yet been reflected in the root hash. Alternatively, if the root hash remains unchanged, the last notified state is still the current valid state). This explicit state comparison mechanism lays a solid foundation for subsequent incremental requests and data transfers, ensuring the logical rigor of the update process.

[0034] In order to ensure the efficiency and reliability of the knowledge update process, this application designs a notification mechanism based on root hash comparison. Among them, the root hash of the last successful notification to the knowledge update service component is the key state information in the mechanism, which must be persistently stored and accurately managed to prevent state loss when the proxy component restarts or fails. Usually, this value can be stored through a local configuration file, a database (such as SQLite or a remote configuration database), or a high-availability cache with persistence capabilities. It is particularly important to note that the root hash of the last successful notification is not an instantaneous snapshot of the local hash summary of the proxy component, but a state value that will only be updated after confirming that the update availability notification has been successfully sent to the knowledge update service component through the MCP protocol. This mechanism ensures the semantic stability of the state and avoids logical errors caused by transient network anomalies or service components failing to receive messages correctly.

[0035] Whenever the private domain knowledge source changes, the update agent component recalculates the hierarchical hash digest of the entire knowledge source and obtains the latest root hash value. It then compares the new root hash with the root hash of the last successful notification previously recorded. If the two are different, it means that the overall state of the knowledge source has changed. At this time, the agent component will construct a lightweight update available notification message and send it to the knowledge update service component through the MCP protocol. The MCP protocol can be a mature message queue protocol (such as AMQP, Kafka, MQTT), or an application layer communication mechanism encapsulated based on HTTP / 2, gRPC or a custom TCP protocol. Its core function is to provide reliable and asynchronous inter-component communication capabilities. The notification message typically includes fields such as message type, sender identifier, new root hash, timestamp, and optional change metadata to convey necessary update information to the service component.

[0036] Regarding the sending mechanism, the update agent calls the API provided by the MCP protocol to serialize and transmit the message, while waiting for the protocol layer to confirm that the message has been successfully sent (for example, entering the network transmission queue or being received by the TCP buffer). Only after confirming that the message has been successfully sent will the agent update the internally stored root hash of the last successful notification to the current new root hash value.

[0037] Exemplarily, in step S3, after receiving the update available notification, the knowledge update service component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash summary it currently holds. If they are different, a request increment message is sent to the update proxy component through the MCP protocol. It should be understood that in a distributed system, the uncertainty of information transmission and the independence of component status are the norm. Although the update proxy component has diligently issued the update available notification, this does not mean that when the knowledge update service component receives the notification, the state of the private domain knowledge base managed by it will be completely inconsistent with the new root hash described in the notification. There are various scenarios that require service components to perform secondary confirmation of their own status: First, network transmission may cause notification delays, disorder or duplication, and the service component may receive multiple update notifications for the same or different stages; Second, the knowledge update service component itself may update its private domain knowledge base to the same state as the new root hash in the notification, or even surpass that state, through other mechanisms (for example, manual import by the administrator, or private completion of a round of updates before the proxy component notification); Third, the hash synchronization mechanism between the proxy component and the service component requires a mutually confirmed reference point, that is, the service component must initiate a valid request based on the data it currently lacks, avoiding invalid data pulling, thereby further saving valuable network bandwidth and processing resources.

[0038] Specifically, when the knowledge update service component receives an update availability notification from the update proxy component through the MCP protocol, its internal monitoring module will immediately parse the notification and extract the new root hash contained therein. Assume that this root hash is called the notified new root hash in the notification. After extracting the notified new root hash, the service component will query its own current root hash, called the service current root hash. This service current root hash represents the actual hash state of the service component's current private domain knowledge base. Subsequently, a simple comparison operation will be performed: to determine whether the notified new root hash is not equal to the service current roothash.

[0039] If the two are equal, that is, notified new root hash == service current root hash, this indicates that the private knowledge base state held by the knowledge update service component is already consistent with the latest state notified by the update proxy component, or that the notification is a duplicate and has already been processed. In this case, the service component does not need to perform any action because the current knowledge base is already up to date or will soon reach the latest state. This effectively avoids unnecessary requests and subsequent processing.

[0040] If the two are not equal, that is, if the notified new root hash != the service current root hash, this indicates that the service component's private knowledge base state differs from the latest state notified by the proxy component and requires an update. At this point, the knowledge update service component immediately constructs and sends a request for incremental data to the update proxy component. This request for incremental data is crucial; it's more than just a simple request signal; it carries a clear context. The message must include the service component's own service current root hash. Only with a clear starting hash can the proxy component accurately calculate and extract the required incremental data packet by comparing the hierarchical hash digests between the two. For example, if the proxy component records its latest state (RootHash Z) and its last notified state (RootHash Y), and the service component's current hash is RootHash X (because the service component failed to update to RootHash Y in a timely manner or its own state lags behind RootHash Y for some reason), the service component's request will include RootHash X. Upon receiving this request, the proxy component compares RootHash X with RootHash Z and then identifies and provides the incremental data between RootHash X and RootHash Z. This starting hash-based request method ensures the accuracy and efficiency of subsequent incremental data extraction.

[0041] Information transmission continues via the MCP protocol. The MCP protocol serves as the cornerstone of reliable communication, ensuring that request delta messages are correctly serialized, transmitted, and ultimately received and parsed by the update proxy component. This can be achieved through a specific API endpoint exposed by the proxy component or through a message queue mechanism, ensuring asynchronous and decoupled processing of requests.

[0042] Exemplarily, in step S4, after receiving the request increment message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet from it, and then sends the knowledge increment message to the knowledge update service component through the MCP protocol. It should be understood that traditional knowledge base synchronization strategies often require the system to transmit a complete copy of the entire knowledge base, no matter how small the actual changes within the knowledge source are. As mentioned above, this flood-like approach will cause unacceptable waste of network bandwidth, idle server computing resources, and data synchronization delays in the modern information environment where data volumes are increasing and change events are becoming more frequent. For example, for a private domain knowledge base of several GB or even several TB, even if only one character in a file is modified, full transmission means that several GB of data need to be retransmitted, which is undoubtedly a huge bottleneck for systems with limited bandwidth or that require real-time response. The request increment message mechanism introduced in this application gives the update agent component the ability to locate and extract incremental data packets, so that the agent component can accurately identify and transmit only those knowledge units that have actually been added, modified, or deleted according to the actual needs of the knowledge update service component. This precise drip-irrigation update model reduces the amount of data transmission to a minimum, significantly reduces the load on the network and server, and transforms the update of the private domain knowledge base from cumbersome and sluggish to lightweight and real-time.

[0043] In one embodiment, Figure 2 As shown, after receiving the request incremental message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet therefrom, including: S41: locating the specific knowledge unit that has changed based on the comparison between the private domain knowledge source hierarchical hash digest currently held in the request incremental message and the updated private domain knowledge source hierarchical hash digest; S42: extracting the incremental data packet from the specific knowledge unit that has changed.

[0044] In one embodiment, Figure 3 As shown, based on the comparison between the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest in the request incremental message, the specific knowledge unit that has changed is located, including: S411: comparing the root hash in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest; S412: if the root hash is different, comparing the sub-directory hash in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest; S413: if the sub-directory hash is different, comparing the file hash in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest to obtain a positioning result, and the positioning result is the specific knowledge unit that has changed.

[0045] First, the proxy component performs a preliminary root hash check. It compares the root hash in the currently held private knowledge source hierarchical hash digest with the root hash in the updated private knowledge source hierarchical hash digest. If the two are the same, theoretically, this means that the service component has reached the latest state, or that the latest state known to the proxy component is the same as the state requested by the service component. In this case, no incremental message is usually sent, or only an empty message is sent for confirmation, avoiding unnecessary subsequent processing. However, in most cases, if the service component issues a request, it usually means that the two root hashes must be different, so the proxy component will continue to perform a deeper comparison.

[0046] Secondly, if the root hash is confirmed to be different, the comparison process will recursively proceed downward to the next level of the hierarchical hash tree, specifically comparing the subdirectory hashes in the currently held private knowledge source hierarchical hash digest with the updated private knowledge source hierarchical hash digest. Specifically, the proxy component compares the hash values of all direct subdirectories (or logically first-level subnodes, such as a specific table group or module in a database) in the currently held private knowledge source hierarchical hash digest with the hash values of the corresponding subdirectories under the same path in the updated private knowledge source hierarchical hash digest. Here, the hash value of each subdirectory is a comprehensive reflection of the hash values of all files or smaller-granularity knowledge units within it. If the hash value of a subdirectory changes, or a subdirectory is added or deleted between the old and new states, this indicates a change within that subdirectory, and the subdirectory's contents will be further explored downward. This design avoids blindly traversing the entire tree structure and can quickly focus on the branch where the change occurred.

[0047] Finally, when the comparison goes deep into the directory level and finds that the hash value of a sub-directory is different, it will continue to go down and compare the current private domain knowledge source level hash summary with the file hash in the updated private domain knowledge source level hash summary to obtain the positioning result, which is the specific knowledge unit that has changed.

[0048] In one embodiment, if the sub-directory hash is different, a downward comparison is made between the file hash in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest to obtain a positioning result, including: if the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, the changed specific knowledge unit is marked as modified to obtain a changed unit operation identifier; if it exists in the currently held private domain knowledge source hierarchical hash digest but does not exist in the updated private domain knowledge source hierarchical hash digest, the changed specific knowledge unit is marked as deleted to obtain a changed unit operation identifier; if it exists in the updated private domain knowledge source hierarchical hash digest but does not exist in the currently held private domain knowledge source hierarchical hash digest, the changed specific knowledge unit is marked as newly added to obtain a changed unit operation identifier.

[0049] In this application, when determining whether a file hash exists in the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, the determination can be based on the probability of the hash strings being identical after comparison. For example, the probability of the identical is based on the intersection-over-union ratio after binary conversion of the hash strings. Therefore, it is assumed that the probability of the file hash existing in the currently held private domain knowledge source hierarchical hash digest is the first probability of existence. The probability that the file hash exists in the updated private domain knowledge source level hash summary is the second existence probability , can be directly based on and The existence of the condition is determined by comparing with a predetermined threshold value, and the predetermined threshold value can be set based on experience, such as 0.99. Of course, this is only an example.

[0050] But in practical applications, the probability value based on the existence judgment and They are not independent of each other, but have a collaborative relationship with each other, that is, based on a specific probability parameter setting mode, the comparison of the file hash relative to the currently held private domain knowledge source level hash summary and the updated private domain knowledge source level hash summary is also bound by the preset mode, so that the obtained probability value and In essence, they have an integrated collaborative relationship and are subject to the same probability parameter setting rules. Therefore, considering the probability value and Perform joint optimization.

[0051] Based on this, in another embodiment of the present application, if the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, the specific knowledge unit that has changed is marked as modified to obtain a change unit operation identifier, including: calculating a first existence probability of the file hash in the currently held private domain knowledge source hierarchical hash digest, and calculating a second existence probability of the file hash in the updated private domain knowledge source hierarchical hash digest.

[0052] Then, the simultaneous correspondence bases of the first existence probability and the second existence probability relative to each other are calculated to obtain a first simultaneous correspondence base and a second simultaneous correspondence base, namely: ;in, represents the first simultaneous correspondence cardinality, Represents the second simultaneous correspondence cardinality.

[0053] This can be considered as a basic logical inference, that is, the correspondence with the single-order probability form is achieved by determining the joint cardinality of the non-homogeneous single-order difference probability.

[0054] Then, in addition to the basic logical inference, an auxiliary logical inference is added, that is, based on the first simultaneous correspondence cardinality and the second simultaneous correspondence cardinality, a joint cardinality cross-linking value is calculated, namely: ;in, Indicates the joint cardinality crosslink value.

[0055] That is, on the basis of the natural derivation of basic logical inference, the interactive derivation compensation of the joint corresponding cardinalities is realized, thereby constructing the joint cardinal cross-linking value calculation.

[0056] Therefore, the probability value can be and That is, based on the first simultaneous correspondence cardinality and the joint cardinality cross-linking value, the first existence probability is closely associated with the optimization to obtain an optimized first existence probability, and based on the second simultaneous correspondence cardinality and the joint cardinality cross-linking value, the second existence probability is closely associated with the optimization to obtain an optimized second existence probability, that is: ;in and is the amplitude modulation parameter, which is introduced into the probability value and While maintaining the correlation between the two, it also avoids the amplitude from significantly deviating from the original probability value. represents the first probability after optimization, Represents the second probability after optimization.

[0057] Therefore, by introducing basic logical inference and auxiliary logical inference, and introducing interactive derivative compensation on the basis of non-homogeneous single-order difference probability joint cardinality to realize the combined action of association representation, the probability value under the same probability parameter setting rule mode can be improved. and , thereby improving the accuracy of its associated values.

[0058] Finally, the existence probability difference between the optimized first existence probability and the optimized second existence probability is calculated, and it is determined whether the existence probability difference is within a preset range. If so, it is determined that the file hash exists in both the currently held private domain knowledge source hierarchical hash summary and the updated private domain knowledge source hierarchical hash summary.

[0059] Once all specific knowledge units that have changed and their change types have been located and identified, the incremental data packets are extracted from these specific knowledge units. For knowledge units marked as newly added or modified, the update proxy component reads the latest content of these knowledge units from the private knowledge repository (the source of the actual file or database data). For example, if a file has been modified, the proxy component reads the latest complete binary content of the file; if a new database record has been added, the proxy component queries the database and retrieves all the latest field data for that record. This content is packaged into a logical incremental data packet along with its corresponding change unit operation identifier (including the knowledge unit path / ID and operation type). For knowledge units marked as deleted, the incremental data packet only contains the change unit operation identifier and its path / ID, without the actual data content, to reduce transmission overhead. After extracting and packaging all incremental data packets, the update proxy component constructs a complete knowledge delta message. This message contains all identified incremental data packets with operation identifiers.

[0060] Exemplarily, in step S5, after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base. It should be understood that in a distributed system, uncertainty in data transmission is the norm, and network congestion, data packet loss or damage, transmission errors, etc. often occur. If the knowledge update service component directly applies the incremental knowledge message to the private domain knowledge base without verification after receiving it, then once a data anomaly occurs during the transmission process, it may cause errors in the knowledge base content at best, affecting knowledge-based decision-making and applications; at worst, it may cause data structure damage, leading to the collapse of the knowledge base and causing immeasurable losses to the business. Therefore, the introduction of the integrity verification mechanism has become the first and most solid line of defense against potential data risks. It ensures that only incremental data packets that are confirmed to be lossless, authentic and reliable will be written into the private domain knowledge base, thereby fundamentally maintaining the data quality of the knowledge base and the stability of the system.

[0061] In one embodiment, Figure 4 As shown, after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base, including: S51: extracting the change unit operation identifier from the knowledge base incremental message; S52: generating a knowledge base change operation verification result based on the comparison between the real-time change event stream and the change unit operation identifier; S53: in response to the knowledge base change operation verification result being a passed verification, extracting the incremental data packet from the knowledge incremental message, and performing format and integrity verification on the incremental data packet to obtain a content verification result; S54: in response to the content verification result being a passed verification, applying the incremental data packet to the private domain knowledge base in combination with the change unit operation identifier.

[0062] Specifically, first, the knowledge update service component parses the knowledge increment message and extracts all nested incremental data packets from it. Each incremental data packet clearly contains at least three core pieces of information: the unique identifier of the knowledge unit in the private domain knowledge base (for example, a file path, a database record ID, or a key for structured data), a change unit operation identifier (usually a predefined enumeration value such as ADD, MODIFY, or DELETE), and for ADD and MODIFY operations, the actual content data of the knowledge unit. Most importantly, in order to achieve integrity verification, each incremental data packet or the entire knowledge increment message itself will be accompanied by a checksum or hash value calculated by the update agent component before sending. For example, this can be a fingerprint generated by the MD5 or SHA-256 algorithm, or a CRC32 cyclic redundancy check code.

[0063] After extracting these incremental data packets, the knowledge update service component does not immediately apply them to the private domain knowledge base. First, it performs an independent integrity check on each incremental data packet. In specific implementation, the service component recalculates its checksum or hash value based on the actual content of the received incremental data packet. Then, it accurately compares the value it calculated with the checksum or hash value pre-encapsulated in the incremental data packet. If the two are exactly the same, it means that the incremental data packet has not been tampered with or damaged during transmission, its integrity has been confirmed, and the check has passed. Conversely, if the calculated checksum does not match the received checksum, it means that the incremental data packet has been tampered with or damaged, and the integrity check has failed.

[0064] After the integrity check passes, the knowledge update service component will perform the corresponding knowledge base operation based on the "change unit operation identifier" indicated in each data packet. This is a highly transaction-oriented process that ensures the consistency and atomicity of the knowledge base when applying increments. That is, all changes will either succeed or fail and be rolled back.

[0065] For incremental data packets marked as ADD and that pass verification, the knowledge update service component will insert the accompanying knowledge content data as a new knowledge unit into the corresponding location of its private domain knowledge base based on the path or ID specified in the data packet. For example, if it is a newly added file, the service component will create a new file in the specified directory and write the received binary content; if it is a newly added database record, it will execute an SQL INSERT operation to insert the data into the corresponding table.

[0066] For incremental data packages that are marked as MODIFY and pass verification, the knowledge update service component will first locate the corresponding existing knowledge unit in the private domain knowledge base based on the knowledge unit identifier provided in the data package. It will then overwrite or update the content of the existing knowledge unit with the latest content data provided in the incremental data package. For example, for a modified file, the service component will open the file and replace the old content with the new content; for an update to a database record, an SQL UPDATE operation will be executed. When performing such updates, special attention should be paid to data integrity verification and version management to ensure a smooth transition of the update process and the ability to restore to the previous stable state in the event of an exception.

[0067] For incremental data packets marked as DELETE and that pass verification, the knowledge update service component accurately locates the knowledge unit to be deleted in the private knowledge base based on the knowledge unit identifier provided in the data packet. It then performs the corresponding deletion operation to remove the knowledge unit from the private knowledge base. For example, deleting a file or executing a SQL DELETE operation to remove a database record. This also requires careful consideration of the atomicity of the deletion to ensure that related indexes and metadata are also cleaned up synchronously.

[0068] If an incremental data packet fails the integrity check, the knowledge update service component will not apply it to the private domain knowledge base. At this point, the appropriate error handling mechanism is triggered. This can include logging the anomaly, alerting the system administrator, or, based on a pre-set policy, sending a negative confirmation message to the update agent component requesting the retransmission of the damaged incremental data packet. In some extreme cases, to avoid inconsistencies in the overall knowledge base due to partial data corruption, the entire update transaction may even be rolled back to ensure that the knowledge base is always in a known, complete, and reliable state.

[0069] After all integrity-verified incremental data packets have been successfully applied to the private knowledge base, the knowledge update service component must update the current root hash in its internally maintained private knowledge source-level hash digest. This current root hash is updated to the new root hash received in the update availability notification, which serves as the target state for this update. This operation is crucial, as it indicates that the knowledge update service component's local knowledge base state has successfully reached the latest state reflected by the update proxy component. This updated root hash will serve as the current hash baseline when the knowledge update service component initiates incremental message requests during the next update cycle, thus forming an accurate and reliable update loop. The entire application process, from receipt and verification to actual writing and finally updating the root hash, is typically wrapped in a database transaction or a set of atomic file operations, ensuring that even if a failure occurs during the application process, a rollback to the previous stable state can be achieved, thereby maintaining the data integrity of the knowledge base.

[0070] In summary, the private domain knowledge dynamic update method for the MCP protocol provided by this application monitors the changes in the private domain knowledge source in real time through the update agent component, and calculates the hierarchical hash summary to efficiently detect change events. Once a change is found, it is compared with the root hash of the last successful notification. If it is different, an update notification is sent to the knowledge update service component through the MCP protocol. After confirming the root hash difference, the receiving end requests an incremental message to obtain the specific change content. Subsequently, the update agent component accurately locates the knowledge unit that has changed, extracts the incremental data packet, and passes it to the knowledge update service component through the MCP protocol for application. In this way, not only is unnecessary network bandwidth and computing resource consumption greatly reduced, but the real-time and accuracy of data updates are also significantly improved, providing strong support for efficient decision-making of enterprises.

[0071] This application also provides a private domain knowledge dynamic update system for the MCP protocol, which is used to execute the above-mentioned private domain knowledge dynamic update method for the MCP protocol, such as Figure 5 As shown, the private domain knowledge dynamic update system 500 for the MCP protocol includes: a private domain knowledge change flow processing module 501, which is used to calculate the updated private domain knowledge source hierarchical hash summary and output a real-time change event stream after the update agent component detects the change event of the private domain knowledge source; a root hash comparison notification module 502, which is used for the update agent component to compare the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification of the knowledge update service component. If they are different, an update available notification is sent to the knowledge update service component through the MCP protocol; a root hash comparison and update triggering module 503, which is used to trigger the knowledge update service component to update the updated private domain knowledge source hierarchical hash summary after receiving the update available notification. The component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash summary it currently holds. If they are different, a request increment message is sent to the update proxy component through the MCP protocol; the incremental data extraction module 504 is used for, after receiving the request increment message, the update proxy component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet from it, and then sends the knowledge increment message to the knowledge update service component through the MCP protocol; the knowledge base incremental update processing module 505 is used for, after receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base.

[0072] The basic principles of the present application have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this application are merely illustrative and not restrictive, and it should not be assumed that these advantages, strengths, and effects are required of each embodiment of this application. In addition, the specific details disclosed above are merely illustrative and facilitating understanding, and are not restrictive. The above details do not limit this application to necessarily being implemented using the above specific details.

[0073] The flowcharts of the methods involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the flowcharts. As will be appreciated by those skilled in the art, these devices, apparatuses, equipment, and systems may be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and may be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and may be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and may be used interchangeably therewith.

[0074] It should also be noted that in the method of the present application, each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0075] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0076] The above description has been provided for the purpose of illustration and description. Furthermore, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A method for dynamically updating private domain knowledge based on the MCP protocol, characterized in that: include: After the update agent component detects a change event of the private domain knowledge source, it calculates the updated private domain knowledge source hierarchical hash digest and outputs a real-time change event stream; The update agent component compares the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification to the knowledge update service component. If they are different, the update agent component sends an update available notification to the knowledge update service component through the MCP protocol. After receiving the update available notification, the knowledge update service component compares the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash digest it currently holds, and if they are different, sends a request increment message to the update proxy component through the MCP protocol; After receiving the request increment message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data packet from it, and then sends the knowledge increment message to the knowledge update service component through the MCP protocol; After receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base.

2. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 1, characterized in that: After the update agent component detects a change event in the private knowledge source, it calculates the updated private knowledge source hierarchical hash digest and outputs a real-time change event stream, including: The update agent component captures the change event of the private domain knowledge source through the file system event monitoring mechanism of the operating system; or, the update agent component captures the change event of the private domain knowledge source through the CDC mechanism of the database.

3. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 2, characterized in that: After the update agent component detects a change event in the private knowledge source, it calculates the updated private knowledge source hierarchical hash digest and outputs a real-time change event stream, including: Based on the change event, locate the corresponding leaf node in the private domain knowledge source hierarchical hash summary, and calculate the hash of the leaf node; When tracing back to the tree root along the leaf node, the hash of each intermediate node on the path is calculated to obtain the updated private domain knowledge source level hash summary.

4. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 1, characterized in that: After receiving the incremental request message, the update agent component locates the specific knowledge unit that has changed from the private domain knowledge base and extracts the incremental data package therefrom, including: Locating the specific knowledge unit that has changed based on a comparison between the private domain knowledge source hierarchical hash digest currently held in the request increment message and the updated private domain knowledge source hierarchical hash digest; The incremental data packet is extracted from the specific knowledge unit that has changed.

5. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 4, characterized in that: Locating the specific knowledge unit that has changed based on a comparison between the private domain knowledge source hierarchical hash digest currently held in the request increment message and the updated private domain knowledge source hierarchical hash digest, including: Comparing the currently held private domain knowledge source hierarchical hash digest with the root hash in the updated private domain knowledge source hierarchical hash digest; If the root hash is different, compare the sub-directory hash in the currently held private domain knowledge source level hash digest with the updated private domain knowledge source level hash digest; If the sub-directory hashes are different, the file hashes in the currently held private knowledge source level hash summary and the updated private knowledge source level hash summary are compared to obtain a positioning result, which is the specific knowledge unit that has changed.

6. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 5, characterized in that: If the subdirectory hashes are different, compare the file hashes in the currently held private knowledge source level hash digest with the updated private knowledge source level hash digest to obtain a positioning result, including: If the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, marking the changed specific knowledge unit as modified to obtain a changed unit operation identifier; If the changed specific knowledge unit exists in the currently held private domain knowledge source hierarchical hash digest but does not exist in the updated private domain knowledge source hierarchical hash digest, marking the changed specific knowledge unit as deleted to obtain a changed unit operation identifier; If the changed specific knowledge unit exists in the updated private domain knowledge source hierarchical hash digest but does not exist in the currently held private domain knowledge source hierarchical hash digest, the changed specific knowledge unit is marked as newly added to obtain a changed unit operation identifier.

7. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 6, characterized in that: If the file hash exists in both the currently held private domain knowledge source hierarchical hash digest and the updated private domain knowledge source hierarchical hash digest, marking the changed specific knowledge unit as modified to obtain a changed unit operation identifier, including: Calculating a first existence probability that the file hash exists in the currently held private domain knowledge source-level hash summary; Calculating a second existence probability of the file hash in the updated private-domain knowledge source-level hash summary; calculating a simultaneous correspondence cardinality of the first existence probability and the second existence probability with respect to each other to obtain a first simultaneous correspondence cardinality and a second simultaneous correspondence cardinality; constructing a joint cardinality crosslink value based on the first simultaneous correspondence cardinality and the second simultaneous correspondence cardinality; Based on the first simultaneous correspondence cardinality and the joint cardinality crosslink value, performing close association optimization on the first existence probability to obtain an optimized first existence probability; Based on the second simultaneous correspondence cardinality and the joint cardinality crosslink value, performing close association optimization on the second existence probability to obtain an optimized second existence probability; Calculate the existence probability difference between the optimized first existence probability and the optimized second existence probability, and determine whether the existence probability difference is within a preset range. If so, determine that the file hash exists in both the currently held private domain knowledge source hierarchical hash summary and the updated private domain knowledge source hierarchical hash summary.

8. The method for dynamically updating private domain knowledge based on the MCP protocol according to claim 1, characterized in that: After receiving the knowledge base incremental message, the knowledge update service component extracts the incremental data packet from the knowledge incremental message and applies it to the private domain knowledge base, including: Extracting a change unit operation identifier from the knowledge base incremental message; generating a knowledge base change operation verification result based on a comparison between the real-time change event stream and the change unit operation identifier; In response to a verification result of the knowledge base change operation being a passed verification, extracting the incremental data packet from the incremental knowledge message, and performing a format and integrity verification on the incremental data packet to obtain a content verification result; In response to the content verification result being a passed verification, the incremental data packet is applied to the private domain knowledge base in combination with the change unit operation identifier.

9. A private domain knowledge dynamic update system for MCP protocol, characterized by: include: The private domain knowledge change stream processing module is used to calculate the updated private domain knowledge source hierarchical hash summary and output a real-time change event stream after the update agent component detects a change event of the private domain knowledge source; A root hash comparison notification module is used for the update agent component to compare the new root hash in the updated private domain knowledge source hierarchical hash summary with the root hash of the last successful notification to the knowledge update service component. If they are different, an update available notification is sent to the knowledge update service component through the MCP protocol; A root hash comparison and update triggering module is configured to, upon receiving the update available notification, cause the knowledge update service component to compare the new root hash in the update available notification with the current root hash in the private domain knowledge source hierarchical hash summary it currently holds, and if they are different, send a request increment message to the update proxy component via the MCP protocol; The incremental data extraction module is used to, after receiving the request incremental message, update the proxy component to locate the specific knowledge unit that has changed from the private domain knowledge base and extract the incremental data packet from it, and then send the knowledge incremental message to the knowledge update service component through the MCP protocol; The knowledge base incremental update processing module is used to extract the incremental data packet from the knowledge incremental message and apply it to the private domain knowledge base after receiving the knowledge base incremental message.

Images