A multi-source data knowledge base and intelligent agent system supporting real-time synchronization

Abstract

The application relates to the technical field of knowledge graph real-time synchronization, and discloses a multi-source data knowledge base supporting real-time synchronization and an intelligent agent system. The system comprises an event access module, a content deconstruction module, an entity matching module, a data anchoring module, a synchronization decision module and a network execution module. The system receives multi-source event streams in real time, deconstructs semantics, data and identifiers, and matches or creates entities and relationships in a dynamic entity relationship network. By anchoring data versions to entities and intelligently generating synchronization decision instructions according to data sources and operation types, the network topology is driven to be reconstructed and updated in real time. The system realizes millisecond-level real-time evolution of the knowledge base, guarantees the logical consistency of multi-source data fusion through strategic synchronization coordination, and improves the real-time performance and reliability of knowledge support.

Description

Technical Field

[0001] This invention relates to the field of real-time synchronization technology of knowledge graphs, specifically to a multi-source data knowledge base and intelligent agent system that supports real-time synchronization. Background Technology

[0002] In existing technologies, integrating multi-source heterogeneous data generally adopts a method based on batch ETL processes to construct static knowledge graphs. This method requires pre-defining a complete schema and periodically executing data extraction, transformation, and loading tasks to ultimately form a knowledge base with a fixed structure. This process results in a significant delay between data generation and knowledge availability, with the knowledge base state lagging behind the actual changes in the data source, failing to meet the real-time application scenarios with strict requirements for data timeliness.

[0003] When dealing with multi-source data updates and conflicts, existing solutions typically rely on timestamp-based "last write first" rules or simple predefined merging logic. These methods treat different data sources as homogeneous information providers, ignoring the fundamental differences in business authority, credibility, and event operation intent among them. This easily leads to data states that violate business logic during concurrent writes or operation conflicts, damaging the overall consistency and reliability of the knowledge base and making it difficult to support intelligent decision-making based on accurate and consistent knowledge.

[0004] A technical solution is needed to transform a knowledge base from static storage to a dynamic, real-time evolving system. This solution should be able to continuously receive event streams and instantly reconstruct the internal knowledge network, while intelligently making decisions based on data source identity and operation type to ensure logical consistency of multi-source data during high-speed synchronization. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-source data knowledge base and intelligent agent system that supports real-time synchronization, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a multi-source data intelligent agent system supporting real-time synchronization, the system comprising:

[0007] The event access module receives raw event streams containing timestamps from multiple heterogeneous data access terminals. The raw event streams carry data source identifiers and event operation types.

[0008] The content deconstruction module deconstructs the original event stream, separating semantic description fields, structured data bodies, and a set of associated identifiers.

[0009] The entity matching module matches or creates entity nodes and relationship edges in a dynamic entity relationship network based on semantic description fields and a set of associated identifiers. The dynamic entity relationship network is the core data topology maintained during system operation.

[0010] The data anchoring module integrates the structured data body and timestamp into a versioned attribute block and anchors it to the corresponding entity node;

[0011] The synchronization decision module generates synchronization decision instructions based on the data source identifier and event operation type. These instructions are used to drive the state transitions of entity nodes and relationship edges in the dynamic entity relationship network.

[0012] The network execution module executes synchronous decision instructions, completes the topology reconstruction and attribute update of the dynamic entity relationship network, and outputs a network state snapshot to the agent decision unit.

[0013] Preferably, the specific implementation of content deconstruction of the original event stream includes:

[0014] The predefined event pattern rule set is invoked to filter the original event stream and select candidate events related to the preset entity model;

[0015] The original payloads of candidate events are expanded using a nested structure, and key-value pairs of all leaf levels are extracted recursively.

[0016] Key-value pairs are grouped according to namespaces to form a set of structured data subjects. The keys of the structured data subjects contain domain, entity type and attribute name information.

[0017] The semantic description field is parsed from the metadata header of the candidate event. The semantic description field includes the event summary text, causal chain identifier, and operation intent encoding.

[0018] Extract the associated identifier set from the reference field of the candidate event. The associated identifier set includes at least the main entity identifier, the list of related entity identifiers, and the context session identifier.

[0019] Preferably, the step of matching or creating entity nodes and relationship edges in a dynamic entity relationship network based on semantic description fields and a set of associated identifiers specifically includes:

[0020] Compare the main entity identifier in the associated identifier set with the unique identifiers of all existing entity nodes in the dynamic entity relationship network;

[0021] If the comparison is successful, the entity node is identified as the main node of the current operation;

[0022] If the comparison fails, an entity node with a new unique identifier is created in the dynamic entity relationship network based on the domain and entity type information in the semantic description field, and the new entity node is set as the main node.

[0023] Iterate through the list of related entity identifiers in the set of associated identifiers, perform a comparison and creation process for each identifier in the list, and obtain a list of related object nodes;

[0024] Based on the operation intent encoding and event summary text in the semantic description field, define or update a directed relation edge from the subject node to each object node in the dynamic entity relation network.

[0025] The type, strength weight, and creation or update time information of the directed relation edge are bound as attributes to the directed relation edge.

[0026] Preferably, the step of integrating the structured data body and timestamp into a versioned attribute block and anchoring it to the corresponding entity node includes:

[0027] Generate a globally unique version sequence number for each candidate event;

[0028] Extract event timestamps accurate to milliseconds from the raw event stream;

[0029] The event timestamp, version sequence number, and the structured data body corresponding to the candidate event are packaged and encapsulated to form a versioned attribute block;

[0030] Versioned attribute blocks are immutable; once generated, their contents cannot be modified.

[0031] Determine the main node of the current operation, and append the generated versioned attribute block to the attribute history chain of the main node.

[0032] The attribute history chain is a linked list arranged in strictly ascending order of version serial number, used to completely record the entire change history of entity node attributes.

[0033] Preferably, the step of generating a synchronization decision instruction based on the data source identifier and the event operation type specifically includes:

[0034] Maintain a data source reputation table, which records the historical accuracy, data freshness level, and weight coefficient for each data source identifier;

[0035] Maintain an operation type influence matrix, which defines the influence weights of different event operation types on different elements in the dynamic entity relationship network;

[0036] Query the data source reputation table to obtain the data freshness level and weight coefficient corresponding to the current data source identifier;

[0037] Query the operation type influence matrix to obtain the influence weight of the current event operation type on the main node, directed relation edges, and attribute history chain;

[0038] Based on the data freshness level, data source weight coefficient, and operation impact weight, the comprehensive synchronization priority score of the current candidate event is calculated.

[0039] The overall synchronization priority score is compared with multiple preset score threshold ranges to determine the synchronization decision mode to be adopted.

[0040] Based on the selected synchronization decision mode, and combined with the information of the current subject node, object node list, directed relation edges, and versioned attribute blocks, a synchronization decision instruction containing the specific operation object, operation action, and execution parameters is generated.

[0041] Preferably, the synchronization decision-making mode includes: instant strong synchronization mode, delayed asynchronous synchronization mode, and conflict arbitration mode;

[0042] When the overall synchronization priority score is in the highest threshold range, the instant strong synchronization mode is adopted. The generated synchronization decision instruction requires the relevant entity node to be locked immediately and the attribute update and relationship edge creation to be performed in an exclusive manner. Other operation requests to the relevant node and relationship edge are blocked before the execution is completed.

[0043] When the overall synchronization priority score falls within the middle threshold range, a delayed asynchronous synchronization mode is adopted. The generated synchronization decision instruction encapsulates the relevant operation into an asynchronous task, places it in the priority task queue for scheduling and execution, and immediately returns the response that the operation has received.

[0044] When the overall synchronization priority score is in the lowest threshold range or a version conflict is detected for attribute updates to the same entity node, the conflict arbitration mode is adopted.

[0045] The specific sub-steps for generating synchronized decision instructions under the conflict arbitration model include:

[0046] Extract the structured data body, data source identifier, timestamp, and version sequence number from each candidate event that has a conflict;

[0047] Sort the data sources of the conflicting parties according to the data source reputation table;

[0048] Prioritize the adoption of the event versioned property block corresponding to the highest-ranked data source;

[0049] If the highest data source reputation is the same, the event versioned attribute block with the latest timestamp will be adopted;

[0050] If the timestamps are also the same, the event versioning attribute block with the larger version sequence number will be adopted;

[0051] Generate a clear arbitration result instruction that anchors the adopted versioned attribute block to the main node and records the arbitration log.

[0052] Preferably, the step of executing synchronous decision instructions to complete the topology reconstruction and attribute update of the dynamic entity relationship network includes:

[0053] Parse synchronous decision instructions to obtain the instruction type, list of operation objects, and execution parameters;

[0054] If the instruction type is immediate strong synchronization mode, then immediately apply a write lock to the entity node specified in the list of operation objects, append the versioned attribute block to the attribute history chain of the node according to the operation action in the instruction, and create or update the specified directed relation edge, and release the write lock after completion.

[0055] If the instruction type is delayed asynchronous synchronous mode, the instruction, the related versioned attribute block and the network state context are packaged into an asynchronous task unit and inserted into the corresponding position in the priority task queue according to the overall synchronization priority score of the task.

[0056] An independent asynchronous execution thread continuously monitors the priority task queue, retrieves asynchronous task units in sequence, and executes the operations within them. No node locks are applied during the execution process, but the consistency of the node state must be verified before and after the operation.

[0057] If the instruction type is conflict arbitration mode, the arbitration result instruction is applied directly, the adopted versioned attribute block is linked to the attribute history chain of the main node, and the state of the relevant directed relation edges is updated.

[0058] After completing any type of instruction operation, the system will traverse the modified entity node and its directly associated directed edges, recalculate the local consistency hash value of the network element, and store the local consistency hash value in association with the network global version number.

[0059] Preferably, the step of outputting a network state snapshot to the agent decision-making unit includes:

[0060] After the global network version number is updated, the snapshot generation process is triggered;

[0061] Extract all entity nodes and directed relation edges whose states have changed since the last snapshot from the dynamic entity relation network;

[0062] For each changed entity node, generate its simplified representation, including the unique identifier of the entity node, the key content summary of the latest version of the attribute block, and the type and target node identifier of all directed relation edges directly connected to it;

[0063] For each changed directed relation edge, generate its simplified representation, including the start and end node identifiers, edge type, current strength weight, and update time of the directed relation edge;

[0064] A simplified representation of all changed elements, along with the current global network version number and the snapshot generation timestamp, is encapsulated into a network state snapshot message;

[0065] Network status snapshot messages are proactively pushed to subscribed agent decision-making units via network communication interfaces.

[0066] Preferably, when the asynchronous execution thread retrieves an asynchronous task unit from the priority task queue for execution, if the verification finds that the current state of the relevant entity node is inconsistent with the network state context stored in the asynchronous task unit, a rollback and retry mechanism is executed. Specific sub-steps include:

[0067] Immediately suspend the execution of the current asynchronous task unit and mark the asynchronous task unit as invalid;

[0068] Record relevant information about the failed task unit, including its operational objectives, original synchronization decision instructions, and reasons for failure, into the abnormal task log.

[0069] Based on the data source identifier and event operation type saved in the failed task unit, recalculate its current comprehensive synchronization priority score;

[0070] Based on the newly calculated comprehensive synchronization priority score, a new asynchronous task unit is created, which includes context extracted from the latest network state.

[0071] The new asynchronous task unit is reinserted into the priority task queue, and its position is determined by the new overall synchronization priority score.

[0072] If the same original event repeatedly triggers the rollback and retry mechanism within the preset number of retries, the system will forcibly increase its next comprehensive synchronization priority score, causing it to enter the immediate strong synchronization mode for processing, in order to ensure eventual consistency.

[0073] Preferably, the present invention also includes a multi-source data knowledge base that supports real-time synchronization, applied to the multi-source data intelligent agent system that supports real-time synchronization as described above. The knowledge base includes a dynamic entity relationship network built and maintained at runtime and all its versioned attribute blocks, and stores a data source reputation table, an operation type influence matrix, a priority task queue, and all network state snapshot history, providing a structured data storage foundation for data synchronization and agent decision-making in the multi-source data intelligent agent system that supports real-time synchronization.

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

[0075] By constructing and maintaining a dynamic entity relationship network as the core data topology for system operation, the network's topology reconstruction and attribute updates are immediately driven upon event access. The network structure and content can continuously and adaptively evolve with the source event flow, achieving millisecond-level synchronization between knowledge representation and real-world state. This eliminates the information lag caused by the traditional periodic snapshot update mode, enabling downstream intelligent agents or decision-making systems to always operate based on the latest and most complete relational view, fundamentally improving response speed and real-time context awareness.

[0076] Synchronization decision instructions are generated based on data source identifiers and event operation types, defining differentiated fusion strategies for data changes from different sources and of different natures. The weight, credibility, or business role of the data source, as well as the specific operational semantics of the event, jointly determine the final state migration path of entity nodes and relation edges. This mechanism transforms multi-source synchronization from a simple time or numerical comparison into a strategically manageable intelligent coordination process, thereby ensuring the logical consistency and decision reliability of the core knowledge topology in scenarios with frequent data conflicts and interweaving. Attached Figure Description

[0077] Figure 1 This is a schematic diagram illustrating the working principle of the multi-source data intelligent agent system supporting real-time synchronization as described in this invention.

[0078] Figure 2 A flowchart illustrating the work of the content deconstruction module;

[0079] Figure 3 A flowchart illustrating how the data anchoring module works;

[0080] Figure 4 A heatmap showing the weighted impact of operation type on elements in a dynamic entity relationship network.

[0081] Figure 5 The distribution of the number of tasks in the synchronous decision-making mode at different time periods. Detailed Implementation

[0082] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0083] Please see Figure 1This invention provides a multi-source data intelligent agent system supporting real-time synchronization. The system includes: receiving raw event streams carrying data source identifiers and event operation types from multiple heterogeneous data access terminals via an event access module; the raw event streams are passed to a content deconstruction module, which processes the event streams, separating semantic description fields, structured data subjects, and a set of associated identifiers; an entity matching module, based on the deconstructed semantic description fields and the set of associated identifiers, performing entity-relationship matching or creation operations within a dynamic entity relationship network maintained during system operation; a data anchoring module integrating the structured data subjects and event timestamps into versioned attribute blocks and anchoring them to the corresponding entity nodes in the network; a synchronization decision module generating synchronization decision instructions that drive state migration in the dynamic entity relationship network based on the data source identifier and event operation type; and a network execution module ultimately executing these instructions, completing network topology reconstruction and attribute updates, and outputting a network state snapshot to the agent decision unit.

[0084] In one embodiment of the present invention, see [reference] Figure 2 The system filters and selects candidate events related to a predefined event pattern rule set by invoking the continuously flowing raw event stream to obtain candidate events. For the raw payload of each candidate event, a nested structure expansion operation is performed to recursively extract key-value pairs at all leaf levels. The extracted key-value pairs are grouped according to their namespaces to form a set of structured data subjects, where the key of each structured data subject contains domain, entity type, and attribute name information. From the metadata header of the candidate events, semantic description fields, including event summary text, causal chain identifiers, and operation intent encoding, are parsed. From the reference fields of the candidate events, a set of association identifiers, containing at least the main entity identifier, a list of related entity identifiers, and a context session identifier, is extracted.

[0085] The process involves comparing the main entity identifier in the associated identifier set with the unique identifiers of all existing entity nodes in the dynamic entity relationship network. If a match is successful, the entity node is designated as the main node for the current operation. If the match fails, an entity node with a new unique identifier is created in the dynamic entity relationship network based on the domain and entity type information parsed from the semantic description field, and this new entity node is set as the main node. The process iterates through the list of related entity identifiers in the associated identifier set, performing the same comparison and creation process for each identifier in the list to obtain the corresponding list of object nodes. Based on the operation intent encoding and event summary text in the semantic description field, a directed relation edge is defined or updated in the dynamic entity relationship network, pointing from the main node to each object node. The type, strength weight, and creation or update time information of the directed relation edge are bound as attributes to this directed relation edge.

[0086] In practical implementation, when the content deconstruction module deconstructs the original event stream, it calls a predefined event pattern rule set to filter the original event stream. The event pattern rule set contains a series of pattern conditions based on data source identifiers and event operation type characteristics. The system matches each event in the original event stream with the event pattern rule set, filtering out candidate events whose event payload structure or metadata information is related to the preset entity model. For the original payload of each candidate event, the system performs a nested structure expansion operation. This process recursively traverses the tree or graph structure of the payload until the leaf level, thereby extracting all key-value pairs at the leaf level. The extracted key-value pairs are then grouped according to their namespaces. Each group of key-value pairs forms a structured data body. The keys of the structured data body are composed of domain, entity type, and attribute name information.

[0087] In some embodiments, a semantic description field is parsed from the metadata header of the candidate event. This semantic description field includes an event summary text, a causal chain identifier, and an operation intent code. The event summary text is a natural language description of the core content of the event. The causal chain identifier is used to associate consecutive events with causal logic. The operation intent code is a predefined enumeration value used to identify operation intents such as creating, updating, associating, or deassociating the event. Simultaneously, a set of association identifiers is extracted from the reference field of the candidate event. This set of association identifiers includes at least a main entity identifier, a list of related entity identifiers, and a context session identifier. The main entity identifier is a unique identifier of the target entity directly operated on by the event. The list of related entity identifiers contains other entity identifiers associated with the event. The context session identifier is used to associate multiple consecutive events within the same session.

[0088] It can be understood that the entity matching module performs matching or creation operations in the dynamic entity relationship network based on the semantic description field and the set of associated identifiers. The entity matching module compares the main entity identifier in the set of associated identifiers with the unique identifiers of all existing entity nodes in the dynamic entity relationship network one by one. If the comparison is successful, the system identifies the entity node corresponding to that unique identifier as the main node for the current operation. If the comparison fails, the entity matching module creates a new entity node in the dynamic entity relationship network based on the domain and entity type information in the semantic description field. The new entity node has a new unique identifier, and the system sets this new entity node as the main node.

[0089] Optionally, the entity matching module iterates through the list of related entity identifiers in the associated identifier set, repeatedly performing the comparison and creation process for each identifier in the list. For an identifier in the list of related entity identifiers, the system compares it with the unique identifiers of all existing entity nodes in the dynamic entity relationship network. If the comparison is successful, the entity node corresponding to the unique identifier is added to the object node list. If the comparison fails, the system infers another new entity node in the dynamic entity relationship network based on the domain information and entity type in the current event semantic description field, and adds this new entity node to the object node list.

[0090] In some embodiments, based on the operation intent encoding and event summary text in the semantic description field, the entity matching module defines or updates a directed relation edge from the subject node to each object node in the dynamic entity relationship network. The type of the directed relation edge is determined by the keywords in the operation intent encoding and event summary text. The strength weight, creation time, or update time information of the directed relation edge are bound to this directed relation edge as attributes. The initial value of the strength weight can be preset based on the event type, and its update logic is managed by the subsequent synchronization decision module. In specific implementations, when there are multiple related entity identifiers in the set of associated identifiers, the entity matching module may use a matching degree calculation formula to assist in deciding whether to create a new relation edge, the formula being expressed as:

[0091] ;

[0092] in: Indicates the overall matching degree. This represents the semantic similarity score based on the semantic description field. This represents the graph association score based on the existing topology of a dynamic entity relationship network. and These are preset weighting coefficients used to balance the influence of semantic and structural information. Overall matching degree. It compares with a preset threshold to determine whether to create a new directed relation edge or update the properties of an existing directed relation edge.

[0093] In one embodiment of the present invention, see [reference] Figure 3For each candidate event after content deconstruction, a globally unique version sequence number is generated. Event timestamps accurate to milliseconds are extracted from the original event stream. The event timestamp, version sequence number, and the corresponding structured data body of the candidate event are packaged and encapsulated into a versioned attribute block, which has the characteristic of immutable content. The subject node of the current operation is determined, and the generated versioned attribute block is appended to the attribute history chain of that subject node. The attribute history chain is a linked list arranged in strictly ascending order of version sequence numbers, used to completely record the entire change history of entity node attributes.

[0094] In practical implementation, the data anchoring module generates a globally unique version sequence number for each candidate event processed by the content deconstruction module. The generation of the version sequence number relies on a high-precision distributed sequence generator, ensuring the global uniqueness and strict incrementality of the sequence number in the system cluster environment. Millisecond-precise event timestamps are extracted from the original event stream carrying the candidate events. These timestamps record the precise moment the original event occurred or was perceived at the data source. The data anchoring module packages the event timestamp, version sequence number, and the corresponding structured data body of the candidate event into a versioned attribute block. This versioned attribute block has the characteristic of immutable content; its internal data is locked once generated, disallowing any subsequent modifications. The encapsulation format of the versioned attribute block adopts a structure containing a header and a payload area. The header stores the event timestamp and version sequence number, while the payload area stores the structured data body.

[0095] In some embodiments, the data anchoring module needs to determine the principal node corresponding to the current operation. This determination process is based on the output of the entity matching module. In a specific implementation, after processing candidate events, the entity matching module outputs a clear principal node reference. The data anchoring module receives this reference to locate the specific entity node in the dynamic entity relationship network. After determining the principal node, the data anchoring module appends the generated versioned attribute blocks to the attribute history chain data structure of the principal node. The attribute history chain is a linked list data structure arranged in strictly ascending order of version sequence numbers. Each node in the linked list stores a versioned attribute block and a pointer to the next versioned attribute block.

[0096] Optionally, the attribute history chain maintenance mechanism ensures a complete record of all changes to entity node attributes. When a new versioned attribute block is appended to the end of the attribute history chain, the system updates a metadata pointer of the main node, making it point to the versioned attribute block with the largest version sequence number in the attribute history chain. This versioned attribute block represents the latest state of the entity node. In specific implementations, when querying the current attribute of an entity node, the system quickly accesses the latest versioned attribute block through this metadata pointer. When it is necessary to trace historical states, the system starts from the latest block and traverses backwards along the attribute history chain. In some embodiments, the version sequence number... The generation logic can be formally described by the following process:

[0097] ;

[0098] in: This indicates the current time window number, calculated from the beginning of a certain epoch. Indicates within the time window The local sequence values ​​assigned by the sequence generator are monotonically increasing. Indicates the fixed number of bits used for left shift. It is a bitmask used to ensure The value is within the specified bit width. Indicates bitwise OR operation. Indicates a bitwise AND operation. This indicates a left shift operation. This formula ensures that the version serial number remains constant within a single time window. With local sequence values Incrementing, while version serial numbers generated in different time windows Also numbered according to the time window The sequence increases with the incrementing sequence, thus globally guaranteeing the monotonically increasing nature of the sequence. The sequence generator is responsible for managing... and The collaboration, and in When overflow is imminent, safely advance to the next time window.

[0099] It is understandable that anchoring versioned attribute blocks to entity nodes is the core operation for building a temporally sequential and traceable knowledge base. Each anchoring operation creates a new, immutable state record point in the attribute history chain. After completing the anchoring operation, the data anchoring module sends a completion notification to the synchronization decision-making module, containing the main node identifier, a summary of the newly added versioned attribute block, and the version sequence number, for the synchronization decision-making module to make subsequent synchronization decisions. The structural design of the attribute history chain supports efficient range queries and snapshot readings, providing a data foundation for the agent decision-making unit to reason based on historical states.

[0100] In one embodiment of the present invention, the system maintains a data source reputation table, which records the historical accuracy, data freshness level, and weight coefficient corresponding to each data source identifier. The system also maintains an operation type influence matrix, which defines the influence weights of different event operation types on different elements in the dynamic entity relationship network. When generating an instruction, the system queries the data source reputation table to obtain the data freshness level and weight coefficient corresponding to the current data source identifier. It then queries the operation type influence matrix to obtain the influence weights of the current event operation type on the subject node, directed relation edges, and attribute history chains. Based on the obtained data freshness level, data source weight coefficient, and operation influence weights, the system calculates the comprehensive synchronization priority score of the current candidate event. The calculated comprehensive synchronization priority score is compared with multiple preset score threshold intervals to determine the appropriate synchronization decision mode. Based on the selected synchronization decision mode, and combined with the current subject node, object node list, directed relation edges, and versioned attribute block information, a synchronization decision instruction containing the specific operation object, operation action, and execution parameters is generated.

[0101] Synchronization decision-making modes include immediate strong synchronization mode, delayed asynchronous synchronization mode, and conflict arbitration mode. When the overall synchronization priority score is in the highest threshold range, immediate strong synchronization mode is used, and the generated synchronization decision instruction requires immediate locking of the relevant entity node and exclusive execution of the update operation. When the overall synchronization priority score is in the middle threshold range, delayed asynchronous synchronization mode is used, and the generated synchronization decision instruction encapsulates the operation as an asynchronous task and places it in the priority task queue. When the overall synchronization priority score is in the lowest threshold range or a version conflict is detected for attribute updates to the same entity node, conflict arbitration mode is used. The sub-steps for generating synchronization decision instructions in conflict arbitration mode include: extracting the structured data body, data source identifier, timestamp, and version sequence number from each candidate event in the conflict; sorting the data sources of the conflicting parties according to the data source reputation table; prioritizing the adoption of the event versioned attribute block corresponding to the highest-ranked data source; if multiple data sources have the same reputation ranking, adopting the event versioned attribute block with the latest timestamp; if the timestamps are also the same, adopting the event versioned attribute block with the larger version sequence number. Finally, a clear arbitration result instruction is generated, which anchors the adopted versioned attribute block to the main node and records the arbitration log.

[0102] In implementation, the synchronization decision module generates synchronization decision instructions based on the data source identifier and event operation type. The system maintains a data source reputation table, which records the historical accuracy, data freshness level, and weight coefficient corresponding to each data source identifier. The historical accuracy is calculated based on the proportion of correct submissions from the data source after arbitration or verification. The data freshness level reflects the timeliness of events generated by the data source, and the weight coefficient is a static adjustment parameter assigned by the system administrator based on the importance of the data source. The system also maintains an operation type influence matrix, which defines the influence weight of different event operation types on different elements in the dynamic entity relationship network. The influence weight quantifies the potential impact of different operation types on node attributes, relationship edges, or changes in network topology. When generating a synchronization decision instruction, the synchronization decision module queries the data source reputation table to obtain the data freshness level and weight coefficient corresponding to the data source identifier carried by the current candidate event. The synchronization decision module also queries the operation type influence matrix to obtain the influence weight of the event operation type of the current candidate event on the main node, directed relationship edges, and attribute history chain.

[0103] In some embodiments, the synchronization decision module calculates a comprehensive synchronization priority score for the current candidate event based on the acquired data freshness level, data source weight coefficient, and operation impact weight. The calculation process employs a weighted aggregation function to calculate the comprehensive synchronization priority score. Calculated using the following formula:

[0104] ;

[0105] in: It is a numerical value mapped to the data freshness level. It is the weighting coefficient in the data source reputation table. It is the sum of influence weights obtained from the operation type influence matrix. , and These are preset normalization coefficients used to balance the contributions of different dimensions and to synchronize the overall priority score. The score falls within a preset numerical range. This can be understood as the synchronization decision module comparing the calculated overall synchronization priority score with multiple preset score threshold intervals. These threshold intervals divide consecutive scores into discrete levels, each corresponding to a synchronization decision mode. Based on the threshold interval where the score falls, the system determines the appropriate synchronization decision mode. Based on the selected synchronization decision mode, and combined with the current subject node, object node list, directed relation edges, and versioned attribute block information provided by the entity matching module and data anchoring module, the synchronization decision module generates a synchronization decision instruction containing the specific operation object, operation action, and execution parameters.

[0106] In practical implementation, the synchronization decision-making modes include immediate strong synchronization mode, delayed asynchronous synchronization mode, and conflict arbitration mode. When the overall synchronization priority score is in the highest threshold range, the system adopts immediate strong synchronization mode. The generated synchronization decision instruction requires immediate locking of the relevant entity node and exclusive execution of attribute updates and relation edge creation, blocking other operation requests to the relevant node and relation edge before completion. When the overall synchronization priority score is in the middle threshold range, the system adopts delayed asynchronous synchronization mode. The generated synchronization decision instruction encapsulates the relevant operations into asynchronous tasks, places them in the priority task queue for scheduling execution, and immediately returns the received response. When the overall synchronization priority score is in the lowest threshold range or the system detects a version conflict in attribute updates for the same entity node, the system adopts conflict arbitration mode. Optionally, the method for detecting version conflicts is to compare the version sequence number of the versioned attribute block to be anchored with the version sequence number of the latest versioned attribute block in the attribute history chain, and combine this with the data source identifier to determine whether a conflict exists.

[0107] Optionally, the specific sub-steps for generating a synchronization decision instruction in the conflict arbitration mode include: extracting the structured data body, data source identifier, timestamp, and version sequence number from each candidate event in the conflict. The synchronization decision module sorts the data sources of the conflicting parties according to the data source reputation table, with the sorting based on a comprehensive judgment of historical accuracy and data freshness level recorded in the data source reputation table. The system prioritizes adopting the versioned attribute block corresponding to the event of the highest-ranked data source. If multiple conflicting data sources have the same highest reputation level in the ranking, the versioned attribute block of the event with the latest timestamp is adopted. If multiple data sources have the same reputation level and the same event timestamp, the versioned attribute block of the event with the larger version sequence number is adopted. In some embodiments, the arbitration logic ultimately generates a clear arbitration result instruction, which includes the operation of anchoring the adopted versioned attribute block to the subject node and instructing the system to record an arbitration log containing information about the conflicting parties and the arbitration basis. It can be understood that the conflict arbitration mode ensures that when there are disagreements among multi-source data, the system makes a deterministic decision based on credibility and timeliness, maintaining the consistency state of the dynamic entity relationship network.

[0108] In one embodiment of the present invention, the step of the network execution module executing a synchronization decision instruction includes: parsing the received synchronization decision instruction to obtain its instruction type, list of operation objects, and execution parameters. If the instruction type is an immediate strong synchronization mode, a write lock is immediately applied to the entity node specified in the list of operation objects, the versioned attribute block is appended to the attribute history chain of the node according to the operation action in the instruction, and the specified directed relation edge is created or updated. After completion, the write lock is released. If the instruction type is a delayed asynchronous synchronization mode, the instruction, the related versioned attribute block, and the current network state context are packaged into an asynchronous task unit, and inserted into the corresponding position of the priority task queue according to the comprehensive synchronization priority score of the task. An independent asynchronous execution thread continuously monitors the priority task queue, retrieves the asynchronous task unit in sequence, and executes the operation in it. No node lock is applied during the execution process, but the consistency of the node state needs to be verified before and after the operation. If the instruction type is a conflict arbitration mode, the arbitration result instruction is directly applied, the adopted versioned attribute block is linked to the attribute history chain of the main node, and the state of the related directed relation edge is updated. After completing any type of instruction operation, the system traverses the modified entity nodes and their directly associated directed edges, recalculates the local consistency hash value of these network elements, and stores the hash value in association with the network's global version number.

[0109] The steps for outputting a network state snapshot to the agent decision-making unit include: triggering the snapshot generation process after the network global version number is updated; extracting all entity nodes and directed edges whose state has changed since the last snapshot from the dynamic entity relationship network; generating a simplified representation for each changed entity node, including the node's unique identifier, a summary of the key content of its latest versioned attribute block, and the type and target node identifier of all directly connected directed edges; generating a simplified representation for each changed directed edge, including the edge's start and end node identifiers, edge type, current strength weight, and update time; encapsulating the simplified representations of all changed elements, along with the current network global version number and snapshot generation timestamp, into a network state snapshot message; and proactively pushing the network state snapshot message to the subscribed agent decision-making units through the network communication interface.

[0110] In practice, the network execution module executes synchronization decision instructions and completes the topology reconstruction and attribute update of the dynamic entity relationship network. The network execution module parses the received synchronization decision instructions to obtain the instruction type, the list of operands, and execution parameters. If the instruction type is an immediate strong synchronization mode, the network execution module immediately applies a write lock to the entity nodes specified in the list of operands. The write lock ensures that during the lock holding period, other threads or processes cannot modify the attribute history chain of the locked entity node and its associated directed relation edges. Following the operations in the synchronization decision instructions, the network execution module appends versioned attribute blocks to the attribute history chain of the entity nodes and creates or updates the directed relation edges specified in the synchronization decision instructions. After completing all operations, the network execution module releases the applied write lock.

[0111] If the instruction type is a delayed asynchronous synchronous mode, the network execution module packages the synchronous decision instruction, the related versioned attribute block, and the current network state context into an asynchronous task unit. The network state context includes the current version sequence number of the relevant entity node at the time of packaging and the state identifiers of adjacent directed edges. Based on the comprehensive synchronization priority score corresponding to this asynchronous task unit, the network execution module inserts it into the corresponding position in the priority task queue. The priority task queue is a queue data structure sorted by score, with asynchronous task units of higher scores located near the head of the queue. An independent asynchronous execution thread continuously monitors the priority task queue, retrieves asynchronous task units from the head of the queue in sequence, and executes the operations encapsulated within them. No node locks are applied to the entity nodes during execution, but the consistency of the entity node's state must be verified before and after the operation, i.e., whether the current version sequence number of the entity node matches the version sequence number recorded in the network state context stored in the asynchronous task unit.

[0112] Understandably, if the instruction type is in conflict arbitration mode, the network execution module directly applies the arbitration result instruction, links the adopted versioned attribute block in the arbitration result instruction to the attribute history chain of the principal node, and updates the state attributes of the relevant directed relation edges according to the arbitration result instruction. After completing any instruction type operation, the system traverses the modified entity nodes and their directly associated directed relation edges, recalculating the local consistency hash values ​​of these network elements. The calculation of the local consistency hash value takes the unique identifier of the entity node, the hash digest of the latest versioned attribute block, and the state information of the associated directed relation edges as input. The network execution module associates the calculated local consistency hash value with the current network global version number and stores it in a distributed version mapping table.

[0113] In some embodiments, the step of outputting a network state snapshot to the agent decision unit is triggered by the network execution module after detecting an update to the network global version number. The network execution module extracts all entity nodes and directed edges whose states have changed since the last snapshot was generated from the dynamic entity relationship network. For each changed entity node, the network execution module generates a simplified representation, which includes the entity node's unique identifier, a key content summary of the entity node's latest versioned attribute block, and the types and target node identifiers of all directed edges directly connected to this entity node. For each changed directed edge, the network execution module generates a simplified representation, which includes the origin and destination node identifiers of the directed edge, the type of the directed edge, the current strength weight of the directed edge, and the update time of the directed edge.

[0114] In practice, the network execution module encapsulates a simplified representation of all changed elements, along with the current global network version number and the snapshot generation timestamp, into a network status snapshot message. The network status snapshot message has a fixed frame structure: the header contains the global network version number and the snapshot generation timestamp, and the payload contains a list of changes. Through the network communication interface, the network execution module proactively pushes the network status snapshot message to subscribed agent decision units. Upon receiving the network status snapshot message, the agent decision unit can decide, based on its internal strategy, whether to incrementally merge the changed content or reconstruct a partial view based on the snapshot.

[0115] Optionally, when asynchronous execution threads process asynchronous task units, no node locks are applied during their execution. Therefore, the design of the priority task queue is crucial for scheduling efficiency. The priority task queue is not only sorted according to the comprehensive synchronization priority score, but may also contain sub-queues based on operation type. Refer to Table 1, which shows a schematic diagram of a priority task queue structure.

[0116] Table 1: Schematic diagram of priority task queue structure

[0117]

[0118] In some embodiments, locally consistent hash values The calculation uses the following formula:

[0119] ;

[0120] in: This represents the calculated locally consistent hash value. A sequence of bytes representing the unique identifier of an entity node. This represents the version sequence number of the latest versioned attribute block in the entity node attribute history chain. This represents the standard hash value calculated for the entire content of the latest version of the attribute block. This represents the standard hash value calculated from the set of state information of all directly associated directed edges of this entity node. (Symbol) This indicates a bitwise XOR operation. This represents a function that merges two hash values ​​into an intermediate value. This represents the final cryptographic hash function. It can be understood that this calculation method ensures that any minor change to an entity node or its associated edges will result in a locally consistent hash value. Significant changes have been made to this, thus effectively supporting consistency checks and the generation of incremental snapshots.

[0121] See Figure 4 In the synchronous decision-making module of the multi-source data intelligent agent system, the quantitative presentation of the operation type influence matrix relies on this heatmap. Specifically, the matrix's row dimension represents the event operation type (including attribute update, relationship creation, relationship update, attribute deletion, and relationship deletion), and the column dimension represents the core elements of the dynamic entity relationship network (including main nodes, relationship edges, and attribute history chains). The color depth in the heatmap corresponds to the influence weight of the element (range 0.2-0.9). The heatmap shows that the influence weight of relationship creation and relationship deletion operations on "relationship edges" is 0.9, making them key triggering operations for network topology reconstruction; the influence weight of attribute update on "attribute history chains" is 0.9, and the influence weight of attribute deletion on "attribute history chains" is 0.8, making them core operations driving the versioning update of entity node attributes; while the influence weights of relationship operations (creation and deletion) on "attribute history chains" and attribute operations (update and deletion) on "relationship edges" are generally lower than 0.4, reflecting the specific association between operations and network elements. At the parameter level, the weight values ​​of this matrix are one of the core inputs for the synchronization decision module to calculate the comprehensive synchronization priority score. The differences in their values ​​directly determine the priority judgment logic of different operations in the synchronization process.

[0122] In one embodiment of the present invention, when an asynchronous execution thread retrieves an asynchronous task unit from the priority task queue for execution, if the verification finds that the current state of the relevant entity node is inconsistent with the network state context stored in the asynchronous task unit, a rollback and retry mechanism is executed. Specific sub-steps include: immediately suspending the execution of the current asynchronous task unit and marking it as invalid; recording relevant information of the invalid task unit, including its operation target, original synchronization decision instruction, and failure reason, in the exception task log; recalculating its current comprehensive synchronization priority score based on the data source identifier and event operation type stored in the invalid task unit; creating a new asynchronous task unit based on the newly calculated comprehensive synchronization priority score, which includes the context extracted from the latest network state; and re-inserting the new asynchronous task unit into the priority task queue, its insertion position determined by the new comprehensive synchronization priority score. If the same original event repeatedly triggers the rollback and retry mechanism within a preset number of retries, the system will forcibly increase its next calculated comprehensive synchronization priority score, causing it to enter an immediate strong synchronization mode for processing.

[0123] In practice, when the asynchronous execution thread retrieves an asynchronous task unit from the priority task queue, it checks the consistency between the current state of the relevant entity node and the network state context saved in the asynchronous task unit before and after execution. The network state context includes the version sequence number of the relevant entity node and a snapshot of the relationship edge state when the asynchronous task unit was created. If the check finds that the current version sequence number of the entity node is inconsistent with the version sequence number saved in the asynchronous task unit, or that the state of the associated relationship edge has changed unexpectedly, it is determined to be a state inconsistency and the rollback and retry mechanism is immediately triggered. The asynchronous execution thread immediately suspends the execution flow of the current asynchronous task unit and marks this asynchronous task unit as invalid. The invalidation status is recorded in the internal state field of the asynchronous task unit.

[0124] In some embodiments, the asynchronous execution thread records relevant information about the failed task unit in the exception task log. The recorded information includes the target entity node identifier of the failed task unit, the original synchronization decision instruction content of the failed task unit, and the specific reason for the state inconsistency. Based on the data source identifier and event operation type stored in the failed task unit, the system recalculates the current comprehensive synchronization priority score corresponding to the failed task unit. The recalculation process queries the latest data source reputation table and operation type influence matrix again, and applies the same weighted aggregation logic as the initial calculation to generate a new comprehensive synchronization priority score. Based on the newly calculated comprehensive synchronization priority score, the system creates a new asynchronous task unit. The new asynchronous task unit contains context information extracted from the latest network state, namely, the latest version sequence number and relational edge state of the relevant entity node at the current moment. It can be understood that the core operation instructions of the new asynchronous task unit are consistent with the original synchronization decision instructions, but the execution context has been updated.

[0125] In practice, the asynchronous execution thread re-inserts the new asynchronous task unit into the priority task queue. The insertion position of the new asynchronous task unit in the priority task queue is determined by the new comprehensive synchronization priority score. The system maintains a retry counter to track the number of retries of asynchronous task units triggered by the same original event. If the same original event repeatedly triggers the rollback and retry mechanism within a preset number of retries, the system will forcibly increase its calculated comprehensive synchronization priority score when processing this event next time, so that its score reaches the highest threshold range corresponding to the immediate strong synchronization mode. Events whose priority is forcibly increased will no longer enter the asynchronous process, but will instead generate a synchronization decision instruction requiring immediate strong synchronization to ensure that the update operation corresponding to the event can ultimately be executed in the dynamic entity relationship network.

[0126] Optionally, the calculation of the forced priority increase score can be expressed as:

[0127] ;

[0128] in: This represents the overall synchronization priority score after a forced increase. This indicates the original score, recalculated based on the data source's reputation and the type of operation. This indicates the system's preset maximum allowed number of retries threshold. This indicates the current number of retries. It is a positive penalty coefficient. When near hour, The value will increase significantly, thus making It will inevitably fall into the score range corresponding to the immediate strong synchronization mode. The verification operations performed by the asynchronous execution thread before executing any asynchronous task unit, including comparing the entity node version number and checking the relationship edge status flag, are the only condition for triggering the rollback and retry mechanism. The retry mechanism works together with the final forced synchronous upgrade mechanism to handle data race conditions caused by asynchronous execution delays and maintain the consistency state of the dynamic entity relationship network in the final sense.

[0129] See Figure 5 In the operation of the multi-source data intelligent agent system, the task quantity distribution characteristics of three synchronization decision-making modes were presented in different time periods. Specifically, the tasks in each time period consisted of three categories: immediate strong synchronization (red segment), delayed asynchronous synchronization (blue segment), and conflict arbitration mode (orange segment), which intuitively reflected the differences in the proportion of synchronization strategies in different time periods: the delayed asynchronous synchronization mode accounted for the majority of the task quantity in each time period (e.g., 45 items in time period 1 and 41 items in time period 8), which is consistent with its positioning as a medium-priority event handling method; the task quantity of the immediate strong synchronization mode reached its peak in time period 6 (25 items), indicating that the proportion of high-priority events increased significantly in this period; the task quantity of the conflict arbitration mode remained at a low level overall (the highest being 12 items in time period 2), reflecting that the triggering frequency of the system's conflict arbitration mechanism was relatively controllable. This distribution data can serve as a core basis for evaluating the adaptability of the system's synchronization decision-making strategy and help to further optimize the parameter configuration of the data source reputation table and operation type influence matrix.

[0130] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0131] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-source data intelligent agent system supporting real-time synchronization, characterized in that, It includes the following processing steps: The event access module receives raw event streams containing timestamps from multiple heterogeneous data access terminals. The raw event streams carry data source identifiers and event operation types. The content deconstruction module deconstructs the original event stream, separating semantic description fields, structured data subjects, and a set of associated identifiers; The entity matching module matches or creates entity nodes and relationship edges in a dynamic entity relationship network based on semantic description fields and a set of associated identifiers. The dynamic entity relationship network is the core data topology maintained during system operation. The data anchoring module integrates the structured data body and timestamp into a versioned attribute block and anchors it to the corresponding entity node; The synchronization decision module determines the synchronization decision mode to be adopted based on the data source identifier and event operation type, and generates synchronization decision instructions. The synchronization decision instructions are used to drive the state transition of entity nodes and relationship edges in the dynamic entity relationship network. The network execution module executes synchronous decision instructions, completes the topology reconstruction and attribute update of the dynamic entity relationship network, and outputs a network state snapshot to the agent decision unit. The synchronization decision-making modes include: instant strong synchronization mode, delayed asynchronous synchronization mode, and conflict arbitration mode. When the overall synchronization priority score is in the highest threshold range, the instant strong synchronization mode is adopted. The generated synchronization decision instruction requires the relevant entity node to be locked immediately and the attribute update and relationship edge creation to be performed in an exclusive manner. Other operation requests to the relevant node and relationship edge are blocked before the execution is completed. When the overall synchronization priority score falls within the middle threshold range, a delayed asynchronous synchronization mode is adopted. The generated synchronization decision instruction encapsulates the relevant operation into an asynchronous task, places it in the priority task queue for scheduling and execution, and immediately returns the response that the operation has received. When the overall synchronization priority score is in the lowest threshold range or a version conflict is detected for attribute updates to the same entity node, the conflict arbitration mode is adopted. The specific sub-steps for generating synchronized decision instructions under the conflict arbitration model include: Extract the structured data body, data source identifier, timestamp, and version sequence number from each candidate event that has a conflict; Sort the data sources of the conflicting parties according to the data source reputation table; Prioritize the adoption of the event versioned property block corresponding to the highest-ranked data source; If the highest data source reputation is the same, the event versioned attribute block with the latest timestamp will be adopted; If the timestamps are also the same, the event versioning attribute block with the larger version sequence number will be adopted; Generate a clear arbitration result instruction that anchors the adopted versioned attribute block to the main node and records the arbitration log.

2. The intelligent agent system for multi-source data supporting real-time synchronization according to claim 1, characterized in that, The specific implementation of content deconstruction of the original event stream includes: The predefined event pattern rule set is invoked to filter the original event stream and select candidate events related to the preset entity model; The original payloads of candidate events are expanded using a nested structure, and key-value pairs of all leaf levels are extracted recursively. Key-value pairs are grouped according to namespaces to form a set of structured data subjects. The keys of the structured data subjects contain domain, entity type and attribute name information. The semantic description field is parsed from the metadata header of the candidate event. The semantic description field includes the event summary text, causal chain identifier, and operation intent encoding. Extract the associated identifier set from the reference field of the candidate event. The associated identifier set includes at least the main entity identifier, the list of related entity identifiers, and the context session identifier.

3. The multi-source data intelligent agent system supporting real-time synchronization according to claim 2, characterized in that, The steps for matching or creating entity nodes and relationship edges in a dynamic entity relationship network based on semantic description fields and a set of associated identifiers specifically include: Compare the main entity identifier in the associated identifier set with the unique identifiers of all existing entity nodes in the dynamic entity relationship network; If the comparison is successful, the entity node is identified as the main node of the current operation; If the comparison fails, an entity node with a new unique identifier is created in the dynamic entity relationship network based on the domain and entity type information in the semantic description field, and the new entity node is set as the main node. Iterate through the list of related entity identifiers in the set of associated identifiers, perform a comparison and creation process for each identifier in the list, and obtain a list of related object nodes; Based on the operation intent encoding and event summary text in the semantic description field, define or update a directed relation edge from the subject node to each object node in the dynamic entity relation network. The type, strength weight, and creation or update time information of the directed relation edge are bound as attributes to the directed relation edge.

4. The multi-source data intelligent agent system supporting real-time synchronization according to claim 3, characterized in that, The step of integrating the structured data body and timestamp into a versioned attribute block and anchoring it to the corresponding entity node includes: Generate a globally unique version sequence number for each candidate event; Extract event timestamps accurate to milliseconds from the raw event stream; The event timestamp, version sequence number, and the structured data body corresponding to the candidate event are packaged and encapsulated to form a versioned attribute block; Versioned attribute blocks are immutable; once generated, their contents cannot be modified. Determine the main node of the current operation, and append the generated versioned attribute block to the attribute history chain of the main node. The attribute history chain is a linked list arranged in strictly ascending order of version serial number, used to completely record the entire change history of entity node attributes.

5. A multi-source data intelligent agent system supporting real-time synchronization according to claim 4, characterized in that, The step of generating synchronization decision instructions based on data source identifier and event operation type specifically includes: Maintain a data source reputation table, which records the historical accuracy, data freshness level, and weight coefficient for each data source identifier; Maintain an operation type influence matrix, which defines the influence weights of different event operation types on different elements in the dynamic entity relationship network; Query the data source reputation table to obtain the data freshness level and data source weight coefficient corresponding to the current data source identifier; Query the operation type influence matrix to obtain the operation influence weight of the current event operation type on the main node, directed relation edges, and attribute history chain; Based on the data freshness level, data source weight coefficient, and operation impact weight, the comprehensive synchronization priority score of the current candidate event is calculated. The overall synchronization priority score is compared with multiple preset score threshold ranges to determine the synchronization decision mode to be adopted. Based on the selected synchronization decision mode, and combined with the information of the current subject node, object node list, directed relation edges, and versioned attribute blocks, a synchronization decision instruction containing the specific operation object, operation action, and execution parameters is generated.

6. The multi-source data intelligent agent system supporting real-time synchronization according to claim 5, characterized in that, The steps of executing synchronous decision instructions to complete the topology reconstruction and attribute update of the dynamic entity relationship network include: Parse synchronous decision instructions to obtain the instruction type, list of operation objects, and execution parameters; If the instruction type is immediate strong synchronization mode, then immediately apply a write lock to the entity node specified in the list of operation objects, append the versioned attribute block to the attribute history chain of the node according to the operation action in the instruction, and create or update the specified directed relation edge, and release the write lock after completion. If the instruction type is delayed asynchronous synchronous mode, the instruction, the related versioned attribute block and the network state context are packaged into an asynchronous task unit and inserted into the corresponding position in the priority task queue according to the overall synchronization priority score of the task. An independent asynchronous execution thread continuously monitors the priority task queue, retrieves asynchronous task units in sequence, and executes the operations within them. No node locks are applied during the execution process, but the consistency of the node state must be verified before and after the operation. If the instruction type is conflict arbitration mode, the arbitration result instruction is applied directly, the adopted versioned attribute block is linked to the attribute history chain of the main node, and the state of the relevant directed relation edges is updated. After completing any type of instruction operation, the system will traverse the modified entity node and its directly associated directed edges, recalculate the local consistency hash value of the network element, and store the local consistency hash value in association with the network global version number.

7. A multi-source data intelligent agent system supporting real-time synchronization according to claim 6, characterized in that, The step of outputting a network state snapshot to the agent decision-making unit includes: After the global network version number is updated, the snapshot generation process is triggered; Extract all entity nodes and directed relation edges whose states have changed since the last snapshot from the dynamic entity relation network; For each changed entity node, generate its simplified representation, including the unique identifier of the entity node, the key content summary of the latest version of the attribute block, and the type and target node identifier of all directed relation edges directly connected to it; For each changed directed relation edge, generate its simplified representation, including the start and end node identifiers, edge type, current strength weight, and update time of the directed relation edge; A simplified representation of all changed elements, along with the current global network version number and the snapshot generation timestamp, is encapsulated into a network state snapshot message; Network status snapshot messages are proactively pushed to subscribed agent decision-making units via network communication interfaces.

8. A multi-source data intelligent agent system supporting real-time synchronization according to claim 7, characterized in that, When the asynchronous execution thread retrieves an asynchronous task unit from the priority task queue for execution, if the verification finds that the current state of the relevant entity node is inconsistent with the network state context stored in the asynchronous task unit, a rollback and retry mechanism is executed. Specific sub-steps include: Immediately suspend the execution of the current asynchronous task unit and mark the asynchronous task unit as invalid; Record relevant information about the failed task unit, including its operational objectives, original synchronization decision instructions, and reasons for failure, into the abnormal task log. Based on the data source identifier and event operation type saved in the failed task unit, recalculate its current comprehensive synchronization priority score; Based on the newly calculated comprehensive synchronization priority score, a new asynchronous task unit is created, which includes context extracted from the latest network state. The new asynchronous task unit is reinserted into the priority task queue, and its position is determined by the new overall synchronization priority score. If the same original event repeatedly triggers the rollback and retry mechanism within the preset number of retries, the system will forcibly increase its next comprehensive synchronization priority score, causing it to enter the immediate strong synchronization mode for processing, in order to ensure eventual consistency.

9. A multi-source data knowledge base supporting real-time synchronization, applied to a multi-source data intelligent agent system supporting real-time synchronization as described in any one of claims 1 to 8, characterized in that, The knowledge base includes a dynamic entity relationship network built and maintained at runtime, along with all its versioned attribute blocks. It also stores a data source reputation table, an operation type influence matrix, a priority task queue, and all network state snapshot history, providing a structured data storage foundation for data synchronization and agent decision-making in the aforementioned multi-source data intelligent agent system that supports real-time synchronization.

Images