A recall state synchronization and derivative memory incremental recalculation method and system for multi-agent memory conflict isolation

Abstract

The application discloses a recall state synchronization and derivative memory incremental recalculation method and system for multi-agent memory conflict isolation, and relates to the technical field of multi-agent memory management. The method comprises the following steps: generating an evidence anchoring memory node; performing typed conflict detection, creating a conflict group and calculating a normal recall permission when a conflict occurs; synchronously projecting a recall control state and the normal recall permission to a vector index, a keyword index and a graph index, comparing the indexes with a main library version before recall, and performing post-filtering when the version is behind or synchronization fails; in response to upstream memory state changes, locating affected derivative memories along a memory dependency graph, calculating an effective and reliable evidence support rate, and making a hierarchical judgment; for those meeting the recalculation conditions, only incremental recalculation is performed based on the remaining effective evidence, a new version is generated, and downstream reevaluation and index synchronization are driven through a version replacement event. The application can avoid conflict memory from polluting normal recall, prevent invalid information from being spread through derivative memories, and reduce recalculation overhead.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, specifically to long-term memory management technology for multi-agent systems, and more particularly to a method and system for synchronizing recall states and recalculating derived memory increments by isolating memory conflicts among multi-agent systems. Background Technology

[0002] With the development of large-scale models and agent technologies, enterprise-level agent systems are gradually evolving from single-agent question-and-answer systems to multi-agent collaborative execution. A user request may be broken down into multiple sub-tasks by the main agent, and then completed by different agents calling knowledge bases, memory, tools, workflows, sandboxes, or external interfaces respectively. To support continuous service across sessions, the system typically writes information such as user statements, task execution results, tool call experience, dialogue summaries, user profiles, preferences, and policy experience into long-term memory, and retrieves it in subsequent tasks through vector retrieval, keyword retrieval, or graph retrieval.

[0003] In multi-agent memory-sharing scenarios, memory is no longer merely a temporary context within a single session, but is jointly written, read, and reprocessed by multiple agents. Different agents may write to memory at different times, with different tool results, different permission ranges, or with different evidence quality. The same user, resource, or task strategy may experience factual, temporal, preference, policy, or permission conflicts. If the system only adopts the approach of "new memory overwrites old memory" or "deletes old memory after conflict," the original chain of evidence will be broken. If the system only records abnormal states in the database without synchronously controlling vector indexes, keyword indexes, and graph indexes, conflicting memories may still be recalled by ordinary tasks and continue to enter the agent's prompt or planning context.

[0004] On the other hand, many long-term memories in an agent system are not directly input by the user, but rather derived memories formed by processing upstream evidence. For example, multi-turn dialogue summaries are generated from several conversation fragments, user profiles are generated from multiple preference memories and behavioral memories, policy memories are obtained by summarizing historical task execution results and tool call results, and team shared knowledge is synthesized from the summary of phased tasks of multiple agents. When an upstream evidence memory is logically deleted, frozen, isolated, downweighted, summed up, or judged as unreliable, if downstream derived memories still participate in ordinary recall with their original weights, the invalid or unreliable information will continue to spread in the form of summaries, profiles, preferences, or policies.

[0005] The existing technology has the following main drawbacks: 1. Conflict handling can easily lead to a break in the chain of evidence. When existing memory processing schemes detect a conflict between old and new memories, they often choose to delete the old memory, overwrite the old memory, or directly write the new memory. They fail to adequately preserve the evidence anchors, generated agents, versions, and reasons for the conflict between the conflicting parties, making it impossible to audit which memory came from which source of evidence.

[0006] 2. Conflicting memories can easily continue to contaminate general recall. Even if existing solutions label memories as abnormal, expired, or low-confidence, they often fail to synchronize this state to vector indexes, inverted indexes, and graph retrieval indexes. As a result, labeled conflicting memories can still be recalled by retrieval enhancement generation modules, agent planning modules, or preference generation modules.

[0007] 3. Multi-agent write scenarios lack conflict grouping and arbitration entry points. If conflict memories written by different agents are only stored as single records, the system finds it difficult to aggregate conflicts by the same user, the same fact object, the same permission domain, or the same policy object, and it also finds it difficult to provide a complete conflict context to the verification agent, audit module, or human arbitration module.

[0008] 4. Derived memories lack a mechanism for simultaneous processing as upstream evidence becomes invalid. Existing memory systems focus more on the creation, updating, and retrieval of original memories, and record less about which upstream evidence derivative memories such as summaries, profiles, preferences, and strategy memories rely on. As a result, downstream derived memories remain valid even after upstream evidence becomes invalid.

[0009] 5. Cascaded processing is either too coarse or too costly. If all downstream memories are deleted directly after upstream evidence is found to be invalid, useful information that is still supported by other valid evidence will be lost. If all summaries, profiles and policy memories are fully recalculated for each state change, the computational cost is high, the latency is large, and it is also easy to affect the execution of online tasks.

[0010] Therefore, in multi-agent shared long-term memory systems, how to prevent conflicting or invalid memories from continuing to participate in ordinary task recall without simply overwriting old memories or breaking the chain of evidence, and how to simultaneously process downstream derived memories generated based on these memories, while avoiding the excessive cost of full recalculation, is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0011] The purpose of this invention is to provide a method and system for synchronizing recall states and incrementally recalculating derived memories with memory conflict isolation in multi-agent systems. This addresses the following technical problems in existing multi-agent shared long-term memory systems: conflict handling using deletion or overwriting methods leads to breaks in the original evidence chain; memory conflicts or invalid states are only recorded in the main database and not synchronized to the vector index, keyword index, and graph index, causing conflicted memories to continue to be recalled by ordinary tasks; conflicted memories written by multiple agents are stored in a scattered manner, lacking grouping and arbitration entry points based on conflict objects; after upstream evidence memories become invalid, downstream derived memories such as summaries, profiles, preferences, and strategies lack a synchronization mechanism, causing invalid information to continue to propagate in the form of derived conclusions; cascading processing either directly deletes all downstream memories, losing information still supported by other valid evidence, or performs a full recalculation, resulting in excessive computational costs and online latency. This invention aims to prevent conflicted or invalid memories from participating in ordinary task recalls without breaking the evidence chain, and to enable downstream derived memories to receive processing commensurate with the degree of impact as the upstream evidence state changes, thereby improving the consistency, auditability, and operational efficiency of multi-agent shared long-term memory systems.

[0012] To achieve the above objectives, the first aspect of this invention provides a method for synchronizing recall states and recalculating derived memory increments while isolating memory conflicts among multiple agents. This method is applied to a multi-agent shared long-term memory system comprising a main memory bank, vector indexes, keyword indexes, graph indexes, and memory dependency graphs. The method is characterized by the following steps: (1) In response to the multi-agent memory write request, generate evidence anchor memory nodes in the main memory bank and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. (2) Filter candidate existing memories from the main memory, and perform typed conflict detection on the memory to be written and the candidate existing memories based on structured field rules, permission rules, time rules or semantic models; if the preset conflict conditions are not met, set the memory to be written to the valid state and add it to each retrieval index, and update the memory dependency graph at the same time; if the preset conflict conditions are met, create or reuse a conflict group, associate the memory to be written with the conflicting existing memories to the same conflict group identifier, retain the evidence anchor point and version identifier of each party in the conflict, and calculate the ordinary recall permission of the members in the conflict group according to the verification status and permission risk of each party in the conflict. (3) Generate an index state synchronization event carrying the node-level state version, and project the recall control state and ordinary recall permission to the vector index, keyword index and graph index used by ordinary task recall, respectively, so as to suppress the participation of unpermitted conflicting memories in ordinary task recall through index state projection. (4) Before the ordinary recall service returns the candidate results, compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory. When the index synchronization version lags behind the node-level status version or the index synchronization fails, perform at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering to remove unauthorized candidate memories. (5) In response to any state versioning change event in the upstream memory node, such as lifecycle failure, isolation or freezing, setting the recalculation evidence usage strategy to unavailable, permission not visible, confidence decrease, or arbitration result write-back, after deduplication according to the state change event identifier and node-level state version, locate the affected downstream derived memory subgraph along the memory dependency graph, and process the affected nodes in the topological order, first process the directly dependent nodes and then process the more downstream dependent nodes. The failed derived memory is regarded as failed evidence in the calculation of its more downstream nodes. (6) For the affected downstream derived memories, calculate the effective and credible evidence support rate based on the main memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence level, and combine the counterexample effectiveness rate, core evidence group rules and permission rules to determine the graded status of downstream derived memories as invalid, expired, downgraded, pending verification or recalculation. (7) In response to the downstream derived memory meeting the recalculation conditions, incremental recalculation is performed only based on the remaining valid evidence that the state is valid and the permissions are visible in its upstream dependencies, generating a new version of the derived memory, marking the old version of the derived memory as a historical version and retaining the audit association, and generating a version replacement event to continue to trigger the re-evaluation of the downstream derived memory and the state synchronization of each retrieval index.

[0013] Furthermore, in the evidence anchoring memory node, the memory state is decoupled into mutually orthogonal fields, including: lifecycle state, recall control state, verification state, version relationship state, ordinary recall permission projection, and recalculation evidence usage strategy; ordinary task recall performs candidate filtering based on the combination of lifecycle state, recall control state, verification state, permission domain, and ordinary recall permission projection; derived memory recalculation distinguishes between valid evidence, low-confidence reference evidence, and unusable evidence based on the recalculation evidence usage strategy, wherein memories in the pending verification state are considered low-confidence reference evidence and are not included in the valid evidence set of the valid credible evidence support rate.

[0014] Furthermore, each conflict group records two pairs of conflict edges, and each conflict edge records the source memory identifier, target memory identifier, conflict type, conflict score, triggering rule, and edge status. Ordinary recall permissions are first suppressed according to the default strategy of the conflict group, and then partially released according to the confirmed members and conflict edges.

[0015] Furthermore, the typed conflict detection in step (2) includes: Detect at least one of the following: factual conflict, temporal conflict, preference conflict, policy conflict, and permission conflict; According to the conflict score formula Calculate the conflict score, where , , , , , These are, respectively, the sub-scores for factual conflict, temporal conflict, preference conflict, strategy conflict, permission conflict, and semantic conflict. To correspond to the weight, each sub-score takes a value between 0 and 1; When the conflict score is greater than or equal to the preset conflict threshold, or when any of the hard conflict rules among enumeration value mutual exclusion, time interval conflict, permission out-of-bounds, security policy mutual exclusion, and core evidence mutual exclusion are triggered, the conflict condition is determined to be met.

[0016] Furthermore, the calculation of ordinary recall permission in step (2) includes: ordinary recall permission for conflict memories that have not been fully arbitrated within the conflict group is set to prohibited by default; members within the conflict group who have been confirmed by manual verification, high-credibility tool evidence or compliance permission proof, under the condition that the permission rules are met and they do not return at the same time as other valid conflict edge members in the same ordinary recall result set, are restored to ordinary recall permission; conflict memories involving permission overstepping or mutual exclusion of security policies are frozen.

[0017] Furthermore, in step (3): each vector entry of the vector index is written with a memory identifier, node-level status version, index synchronization version, recall control status, ordinary recall permission, conflict group identifier and version identifier. During ordinary vector retrieval, entries with ordinary recall permission as prohibited are excluded in the retrieval filtering conditions, and a weighting coefficient is applied to expired status entries. Keyword indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, tenant identifiers, and permission domains. During normal keyword recall, candidates are filtered according to normal recall permissions, tenant identifiers, and permission domains. Nodes or edges of graph indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, conflict group identifiers, and version identifiers. During normal graph traversal, nodes or edges with prohibited normal recall permissions are skipped. Graph traversal verification or auditing accesses complete conflict subgraphs according to conflict group identifiers.

[0018] Furthermore, the index status synchronization event generated in step (3) carries a synchronization event identifier, memory identifier, node-level status version, target index type, recall control status, ordinary recall permission, conflict group identifier, version identifier, and retry count; each retrieval index side deduplicates according to the synchronization event identifier, and only updates the index status projection when the node-level status version carried by the index status synchronization event is not lower than the index synchronization version already recorded by the index side, and sets the index synchronization version to the corresponding node-level status version after the update is completed.

[0019] Furthermore, in step (4), when the index update fails, the corresponding memory is added to the ordinary recall blacklist. Before the ordinary recall service returns the candidate results, it performs secondary filtering according to the ordinary recall blacklist and the main memory status. After the index status is successfully synchronized, the corresponding memory is removed from the ordinary recall blacklist.

[0020] Furthermore, the memory dependency graph is logically divided into two isolated views: a normal recall graph and a dependency propagation graph. The normal recall graph is filtered by normal recall permissions, permission domains, and index synchronization versions and is used for normal task recall. The dependency propagation graph retains memory nodes and their dependency edges that are isolated, frozen, in historical versions, or in audit tombstone record states and is used for state propagation, derivation recalculation, and audit tracing.

[0021] Furthermore, in step (6): Derived memory Valid and credible evidence support rate Calculate using the following formula:

[0022] in, Let be the sequence number of the upstream positive support dependency edge of the derived memory. For the first The dependency weight of the upstream positive support dependency edge and , For the first The validity coefficient of the upstream memory in the current permission evaluation context, with a value ranging from 0 to 1. For the first The confidence normalization coefficient of the upstream memory is between 0 and 1, and the denominator is the sum of all positive support dependency weights of the derived memory. The upstream memory in a valid state is calculated jointly by the memory lifecycle state, recall control state, recalculation evidence usage strategy, and access visibility. A value of 1 indicates an upstream memory that is in an isolated, frozen, invalid, or deleted state. A value of 0 indicates that the upstream memory is in an expired state. Take a weighted value between 0 and 1; If a derived memory lacks positive supporting evidence or the sum of the positive supporting dependence weights is zero, then the derived memory is marked as invalid, pending verification, or a conservative version requiring supplementary evidence is generated. For counterexamples or negative constraint evidence in upstream dependencies, the numerator of positive support is not included, and the counterexample validity rate is calculated separately. ,in This refers to the dependency edge number of the counterexample evidence or negative constraint evidence. For the corresponding dependency weights, For the corresponding effective coefficients, The corresponding confidence level normalization coefficient is used; when the counterexample validity rate exceeds the preset counterexample threshold, the downstream derived memory is marked as pending verification, incremental recalculation is triggered, or the weight of ordinary recall is reduced.

[0023] Furthermore, the hierarchical state determination setting in step (6) satisfies Failure threshold and expiration threshold Furthermore, the judgment order follows a hard rule, taking precedence over the support rate threshold: Core evidence is managed as core evidence groups. Each core evidence group is configured with rules that all evidence must be valid and any valid evidence can support or replace the evidence group. When a core evidence group does not meet its validity rules, or when core evidence enters an isolated, frozen, invalid, or deleted state, it directly triggers recalculation, pending verification, or invalidation processing if the valid and credible evidence support rate threshold is exceeded. Assuming the risk of core evidence is excluded, when Furthermore, when the decline originates from global evidence invalidation, logical deletion, arbitration rejection, or when the evidence recalculation usage strategy is set to unavailable, downstream derived memories will be marked as invalid and removed from the ordinary recall index. when When downstream derived memories are marked as expired, the weight of ordinary recall is reduced, and the recalculation priority is determined according to the survival rate of dependent evidence, recall frequency, permission risk or user impact before being added to the recalculation queue. when However, when there are changes in core evidence, the effectiveness of counterexamples exceeds the preset counterexample threshold, or the proportion of evidence not visible in the permission domain exceeds the preset ratio, the downstream derived memory will be marked as pending verification, incremental recalculation will be triggered, or context-level restrictions will be generated. when If there is no decrease and no changes in core evidence, valid counterexamples, or permission risks, only the change in dependency state is recorded, and no recalculation is performed.

[0024] Furthermore, step (7) of performing incremental recalculation based solely on the remaining valid evidence includes: Obtain the upstream dependency set of downstream derived memories from the memory dependency graph; Filter out upstream memories that have been logically deleted, frozen, isolated, marked as invalid, have invisible permissions, or have been set to unusable by the evidence usage strategy after recalculation. Remove upstream memories in the state to be verified as low-credibility reference evidence from the set of valid evidence and record them separately. The remaining valid evidence is sorted by dependency weight, evidence type, time range, and confidence level. Select the corresponding recalculation template based on the type of downstream derived memory to generate a new derived memory version; Establish evidence anchors, version relationships, and dependency edges for the new derived memory version, and mark the version status of the old version as replaced while retaining the audit association; When the remaining valid evidence is insufficient to support the original derived conclusion, a conservative version, an empty version, or a supplementary evidence task is generated, and no strong conclusion is output.

[0025] Furthermore, in step (5), when locating the affected downstream derived memory subgraph along the memory dependency graph, it is subject to at least one of the following constraints: preset maximum propagation depth, preset maximum number of processing nodes, memory type filtering rules, and tenant permission boundaries; for derived memories that are not located in the affected subgraph or whose validity has not changed in the positive supporting evidence and core evidence group, no recalculation task is created.

[0026] Furthermore, it also includes: The memory recall is divided into ordinary task recall, verification recall, audit recall and recalculation recall. Ordinary task recall is prohibited for memories in the isolated, pending verification, frozen and invalid states. Degraded recall is set for memories in the expired state. Controlled access is set for verification recall and audit recall. In response to concurrent writes by multiple agents to mutually exclusive memories targeting the same principal object, the same attribute predicate, and overlapping effective time ranges, conflict merge keys are generated according to tenant, principal object, attribute predicate, effective time range, permission domain, and memory type. When the merge keys of conflict groups created by multiple write transactions overlap with the conflict participating nodes, multiple conflict groups are merged into the same target conflict group, and the ordinary recall permission and index state synchronization events are recalculated with the latest node-level state version. In response to receiving a manual or automatic arbitration result, the arbitration result is written back to the main memory, and the normal recall index state synchronization and downstream dependency propagation are triggered again through the updated node-level state version.

[0027] A second aspect of this invention provides a multi-agent memory conflict isolation recall state synchronization and derived memory incremental recalculation system, applied to a multi-agent shared long-term memory system including a main memory bank, vector index, keyword index, graph index, and memory dependency graph, comprising: The memory normalization and evidence anchoring module is used to respond to multi-agent memory writing requests, generate evidence anchoring memory nodes in the main memory, and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. The conflict retrieval and conflict group isolation module is used to filter candidate existing memories from the main memory and perform typed conflict detection. When the conflict conditions are met, a conflict group is created or reused, conflict memories are associated with the same conflict group identifier, and ordinary recall permissions are calculated based on the verification status and permission risk of each party in the conflict. The recall index status synchronization module is used to generate index status synchronization events carrying node-level status versions, synchronize and project the recall control status and ordinary recall permission to the vector index, keyword index and graph index respectively, and compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory before the ordinary recall service returns the candidate results. When the index synchronization version is lagging behind or synchronization fails, at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering is performed. The memory dependency graph storage module is used to store the derived dependency relationships between memory nodes, and is logically divided into mutually isolated ordinary recall graph views and dependency propagation graph views. The upstream state change monitoring and downstream derived memory location module is used to respond to the state versioning change event of the upstream memory node, locate the affected downstream derived memory subgraph along the memory dependency graph after deduplication according to the state change event identifier and node-level state version, and process the affected nodes in the topological order. The dependency evidence survival rate calculation module is used to calculate the effective and credible evidence support rate of affected downstream derived memories based on the master memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence, and to perform hierarchical status determination in combination with counterexample effectiveness rate, core evidence group rules and permission rules. The derived memory incremental recalculation module is used to perform incremental recalculation only based on the remaining valid evidence that is valid and visible in its upstream dependencies when the recalculation conditions are met. This generates a new version of the derived memory, marks the old version of the derived memory as a historical version and retains the audit association, and generates a version replacement event to continue to trigger the re-evaluation of downstream derived memories and the state synchronization of each retrieval index. The verification, arbitration, and auditing module is used to recall conflict memories and their evidence anchors by conflict group identifier for verification or arbitration, and write the arbitration results back to the main memory. Specifically, the conflict retrieval and conflict group isolation module sends an index status synchronization event to the recall index status synchronization module; the upstream status change monitoring and downstream derived memory location module sends a status change event to the dependent evidence survival rate calculation module; the version replacement event generated by the derived memory incremental recalculation module is sent back to the recall index status synchronization module; and the arbitration result written back by the verification arbitration and audit module triggers the upstream status change monitoring and downstream derived memory location module to generate a status versioning event.

[0028] Furthermore, the recall index state synchronization module writes the memory identifier, node-level state version, index synchronization version, recall control state, ordinary recall permission, conflict group identifier, and version identifier into the vector index; writes the memory identifier, node-level state version, index synchronization version, ordinary recall permission, recall control state, tenant identifier, and permission domain into the keyword index; and writes the memory identifier, node-level state version, index synchronization version, ordinary recall permission, recall control state, conflict group identifier, and version identifier into the nodes or edges of the graph index. The ordinary recall graph view in the memory dependency graph storage module is filtered by the ordinary recall permission, permission domain, and index synchronization version, while the dependency propagation graph view retains the memory nodes and their dependent edges that are isolated, frozen, in historical versions, or in audit tombstone record states.

[0029] Compared with the prior art, the present invention has the following significant advantages: This invention creates or reuses conflict groups when a conflict is detected between the memory to be written and an existing memory. The conflicting memories are associated with the same conflict group identifier and the evidence anchors and version identifiers of the conflicting parties are preserved, rather than overwriting or deleting the old memory with the new memory. This ensures that the original source of evidence, the generating agent, and the version relationship are completely preserved after a conflict occurs, thereby supporting subsequent verification, arbitration, and audit traceability, and avoiding the problem of broken evidence chains that are easily caused by existing conflict handling methods.

[0030] This invention synchronously projects the ordinary recall permission, recall control status, and node-level status version onto the vector index, keyword index, and graph index used by the ordinary task recall. Before the ordinary recall service returns candidate results, it compares the synchronized version on the index side with the status version in the main memory. When the index synchronization version lags behind or index synchronization fails, it performs blacklist filtering, post-filter table filtering, or secondary filtering by the main memory status. This allows conflict or invalidation states in the main memory to be reflected in the multi-category retrieval index side in a timely manner. Thus, in the case of asynchronous updates between the main database and multiple indexes, it prevents unauthorized conflicting memories from entering the agent prompt words or planning context, avoiding the problem of simply marking abnormal states in the database while conflicting memories are still recalled by ordinary tasks.

[0031] This invention aggregates conflict memories by using conflict group identifiers and records each pair of conflict edges, their conflict types, conflict scores, triggering rules, and edge states within the conflict group. This enables verification agents, auditing modules, or human arbitrators to obtain the complete conflict context and evidence anchors of each party at once, based on the same user, the same fact object, or the same strategy object. This provides a unified entry point for conflict arbitration in scenarios where multiple agents write concurrently.

[0032] This invention generates state versioning events when upstream memory nodes experience lifecycle failure, isolation or freezing, recalculation of evidence usage policies as unavailable, access restrictions, decreased confidence, or arbitration results being written back. It then locates the affected downstream derived memory subgraphs along the memory dependency graph and calculates the effective and credible evidence support rate based on the main memory state field, recalculation of evidence usage policies, access visibility, dependency edge weights, and confidence. Combining the counterexample effectiveness rate and core evidence group rules, it performs hierarchical state determination, enabling the failure status of upstream evidence to propagate along derived dependencies to summaries, profiles, preferences, policy memories, and team shared knowledge. This prevents expired or unreliable information from continuing to participate in ordinary recalls in the form of derived conclusions.

[0033] This invention categorizes affected downstream derived memories into different processing levels—invalid, expired, downgraded, pending verification, and recalculated—based on the support rate of valid and credible evidence. When the recalculation condition is met, a new version of the derived memory is generated only based on the remaining valid evidence, while the audit relationship of the old version is retained. Simultaneously, the version replacement event continues to trigger the re-evaluation of further downstream derived memories. This results in derived memories with severely insufficient evidence support becoming directly invalid, some affected derived memories being downgraded or incrementally recalculated, and derived memories with minor impact retaining their existing versions. This avoids the loss of useful information caused by directly deleting all downstream memories after upstream evidence becomes invalid, and also avoids the computational cost and online latency caused by recalculating all summaries, profiles, and strategy memories for each state change.

[0034] This invention drives conflict group isolation, ordinary recall index synchronization suppression, dependency graph cascading propagation, and derived memory incremental recalculation through a unified node-level state version mechanism. Index synchronization events are updated idempotently according to the synchronization event identifier and the index synchronization version is written back after the update is completed. The old version of the derived memory is marked as a historical version and the audit association is retained. This enables the multi-agent shared long-term memory system to maintain recall state consistency under concurrent writing and multi-index asynchronous update conditions, and every state change, index synchronization, dependency propagation, and recalculation version can be traced. Attached Figure Description

[0035] Figure 1 This is a flowchart of the recall status synchronization and derived memory incremental recalculation method of the present invention; Figure 2This is a schematic diagram of the control flow of the multi-agent memory conflict isolation and derived memory incremental recalculation system provided in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the multi-agent memory conflict isolation and derived memory incremental recalculation method provided in an embodiment of the present invention. Detailed Implementation

[0036] Example 1

[0037] like Figure 1 As shown, this embodiment provides a method for recall state synchronization and derived memory incremental recalculation with multi-agent memory conflict isolation, applied to a multi-agent shared long-term memory system including a main memory bank, vector index, keyword index, graph index, and memory dependency graph. The method is characterized by the following steps: (1) In response to the multi-agent memory write request, generate evidence anchor memory nodes in the main memory bank and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. (2) Filter candidate existing memories from the main memory, and perform typed conflict detection on the memory to be written and the candidate existing memories based on structured field rules, permission rules, time rules or semantic models; if the preset conflict conditions are not met, set the memory to be written to the valid state and add it to each retrieval index, and update the memory dependency graph at the same time; if the preset conflict conditions are met, create or reuse a conflict group, associate the memory to be written with the conflicting existing memories to the same conflict group identifier, retain the evidence anchor point and version identifier of each party in the conflict, and calculate the ordinary recall permission of the members in the conflict group according to the verification status and permission risk of each party in the conflict. (3) Generate an index state synchronization event carrying the node-level state version, and project the recall control state and ordinary recall permission to the vector index, keyword index and graph index used by ordinary task recall, respectively, so as to suppress the participation of unpermitted conflicting memories in ordinary task recall through index state projection. (4) Before the ordinary recall service returns the candidate results, compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory. When the index synchronization version lags behind the node-level status version or the index synchronization fails, perform at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering to remove unauthorized candidate memories. (5) In response to any state versioning change event in the upstream memory node, such as lifecycle failure, isolation or freezing, setting the recalculation evidence usage strategy to unavailable, permission not visible, confidence decrease, or arbitration result write-back, after deduplication according to the state change event identifier and node-level state version, locate the affected downstream derived memory subgraph along the memory dependency graph, and process the affected nodes in the topological order, first process the directly dependent nodes and then process the more downstream dependent nodes. The failed derived memory is regarded as failed evidence in the calculation of its more downstream nodes. (6) For the affected downstream derived memories, calculate the effective and credible evidence support rate based on the main memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence level, and combine the counterexample effectiveness rate, core evidence group rules and permission rules to determine the graded status of downstream derived memories as invalid, expired, downgraded, pending verification or recalculation. (7) In response to the downstream derived memory meeting the recalculation conditions, incremental recalculation is performed only based on the remaining valid evidence that the state is valid and the permissions are visible in its upstream dependencies, generating a new version of the derived memory, marking the old version of the derived memory as a historical version and retaining the audit association, and generating a version replacement event to continue to trigger the re-evaluation of the downstream derived memory and the state synchronization of each retrieval index.

[0038] As one implementation method, in the evidence anchoring memory node described in this embodiment, the memory state is decoupled into mutually orthogonal fields, including: lifecycle state, recall control state, verification state, version relationship state, ordinary recall permission projection, and recalculation evidence usage strategy; ordinary task recall performs candidate filtering based on the combination of lifecycle state, recall control state, verification state, permission domain, and ordinary recall permission projection; derived memory recalculation distinguishes between valid evidence, low-confidence reference evidence, and unusable evidence based on the recalculation evidence usage strategy, wherein memories in the pending verification state are considered low-confidence reference evidence and are not included in the valid evidence set of the valid credible evidence support rate.

[0039] As one implementation method, in this embodiment, each conflict edge is recorded within the conflict group, and each conflict edge records the source memory identifier, target memory identifier, conflict type, conflict score, triggering rule, and edge status; ordinary recall permissions are first suppressed according to the default policy of the conflict group, and then partially released according to the confirmed members and conflict edges.

[0040] As one implementation method, the typed conflict detection in step (2) of this embodiment includes: Detect at least one of the following: factual conflict, temporal conflict, preference conflict, policy conflict, and permission conflict; According to the conflict score formula Calculate the conflict score, where , , , , , These are, respectively, the sub-scores for factual conflict, temporal conflict, preference conflict, strategy conflict, permission conflict, and semantic conflict. To correspond to the weight, each sub-score takes a value between 0 and 1; When the conflict score is greater than or equal to the preset conflict threshold, or when any of the hard conflict rules among enumeration value mutual exclusion, time interval conflict, permission out-of-bounds, security policy mutual exclusion, and core evidence mutual exclusion are triggered, the conflict condition is determined to be met.

[0041] As one implementation method, in this embodiment, the calculation of ordinary recall permission in step (2) includes: ordinary recall permission for conflict memories that have not been fully arbitrated within the conflict group is set to prohibited by default; members within the conflict group who have been confirmed by manual verification, high-credibility tool evidence, or compliant permission proof, under the condition that the permission rules are met and they do not return at the same time as other valid conflict edge members in the same ordinary recall result set, are restored to ordinary recall permission; conflict memories involving permission overstepping or mutual exclusion of security policies are frozen.

[0042] As one implementation method, in step (3) of this embodiment: each vector entry of the vector index is written with a memory identifier, node-level status version, index synchronization version, recall control status, ordinary recall permission, conflict group identifier and version identifier. During ordinary vector retrieval, entries with ordinary recall permission as prohibited are excluded in the retrieval filtering conditions, and a weighting coefficient is applied to expired status entries. Keyword indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, tenant identifiers, and permission domains. During normal keyword recall, candidates are filtered according to normal recall permissions, tenant identifiers, and permission domains. Nodes or edges of graph indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, conflict group identifiers, and version identifiers. During normal graph traversal, nodes or edges with prohibited normal recall permissions are skipped. Graph traversal verification or auditing accesses complete conflict subgraphs according to conflict group identifiers.

[0043] As one implementation method, in this embodiment, the index status synchronization event generated in step (3) carries a synchronization event identifier, a memory identifier, a node-level status version, a target index type, a recall control status, a normal recall permission, a conflict group identifier, a version identifier, and a number of retries. Each retrieval index side deduplicates according to the synchronization event identifier, and only updates the index status projection when the node-level status version carried by the index status synchronization event is not lower than the index synchronization version already recorded by the index side, and sets the index synchronization version to the corresponding node-level status version after the update is completed.

[0044] As one implementation method, in step (4) of this embodiment, when the index update fails, the corresponding memory is added to the ordinary recall blacklist. Before the ordinary recall service returns the candidate result, it performs secondary filtering according to the ordinary recall blacklist and the main memory status. After the index status is successfully synchronized, the corresponding memory is removed from the ordinary recall blacklist.

[0045] As one implementation method, the memory dependency graph in this embodiment is logically divided into two isolated ordinary recall graph views and dependency propagation graph views. The ordinary recall graph view is filtered by ordinary recall permission, permission domain and index synchronization version and is used for ordinary task recall. The dependency propagation graph view retains memory nodes and their dependency edges that are isolated, frozen, in historical version and in audit tombstone record state, and is used for state propagation, derivation recalculation and audit tracing.

[0046] As one implementation method, in step (6) of this embodiment: Derived memory Valid and credible evidence support rate Calculate using the following formula:

[0047] in, Let be the sequence number of the upstream positive support dependency edge of the derived memory. For the first The dependency weight of the upstream positive support dependency edge and , For the first The validity coefficient of the upstream memory in the current permission evaluation context, with a value ranging from 0 to 1. For the first The confidence normalization coefficient of the upstream memory is between 0 and 1, and the denominator is the sum of all positive support dependency weights of the derived memory. The upstream memory in a valid state is calculated jointly by the memory lifecycle state, recall control state, recalculation evidence usage strategy, and access visibility. A value of 1 indicates an upstream memory that is in an isolated, frozen, invalid, or deleted state. A value of 0 indicates that the upstream memory is in an expired state. Take a weighted value between 0 and 1; If a derived memory lacks positive supporting evidence or the sum of the positive supporting dependence weights is zero, then the derived memory is marked as invalid, pending verification, or a conservative version requiring supplementary evidence is generated. For counterexamples or negative constraint evidence in upstream dependencies, the numerator of positive support is not included, and the counterexample validity rate is calculated separately. ,in This refers to the dependency edge number of the counterexample evidence or negative constraint evidence. For the corresponding dependency weights, For the corresponding effective coefficients, The corresponding confidence level normalization coefficient is used; when the counterexample validity rate exceeds the preset counterexample threshold, the downstream derived memory is marked as pending verification, incremental recalculation is triggered, or the weight of ordinary recall is reduced.

[0048] As one implementation method, the hierarchical state determination setting in step (6) of this embodiment satisfies Failure threshold and expiration threshold Furthermore, the judgment order follows a hard rule, taking precedence over the support rate threshold: Core evidence is managed as core evidence groups. Each core evidence group is configured with rules that all evidence must be valid and any valid evidence can support or replace the evidence group. When a core evidence group does not meet its validity rules, or when core evidence enters an isolated, frozen, invalid, or deleted state, it directly triggers recalculation, pending verification, or invalidation processing if the valid and credible evidence support rate threshold is exceeded. Assuming the risk of core evidence is excluded, when Furthermore, when the decline originates from global evidence invalidation, logical deletion, arbitration rejection, or when the evidence recalculation usage strategy is set to unavailable, downstream derived memories will be marked as invalid and removed from the ordinary recall index. when When downstream derived memories are marked as expired, the weight of ordinary recall is reduced, and the recalculation priority is determined according to the survival rate of dependent evidence, recall frequency, permission risk or user impact before being added to the recalculation queue. when However, when there are changes in core evidence, the effectiveness of counterexamples exceeds the preset counterexample threshold, or the proportion of evidence not visible in the permission domain exceeds the preset ratio, the downstream derived memory will be marked as pending verification, incremental recalculation will be triggered, or context-level restrictions will be generated. when If there is no decrease and no changes in core evidence, valid counterexamples, or permission risks, only the change in dependency state is recorded, and no recalculation is performed.

[0049] As one implementation method, in this embodiment, step (7) of performing incremental recalculation based only on the remaining valid evidence includes: Obtain the upstream dependency set of downstream derived memories from the memory dependency graph; Filter out upstream memories that have been logically deleted, frozen, isolated, marked as invalid, have invisible permissions, or have been set to unusable by the evidence usage strategy after recalculation. Remove upstream memories in the state to be verified as low-credibility reference evidence from the set of valid evidence and record them separately. The remaining valid evidence is sorted by dependency weight, evidence type, time range, and confidence level. Select the corresponding recalculation template based on the type of downstream derived memory to generate a new derived memory version; Establish evidence anchors, version relationships, and dependency edges for the new derived memory version, and mark the version status of the old version as replaced while retaining the audit association; When the remaining valid evidence is insufficient to support the original derived conclusion, a conservative version, an empty version, or a supplementary evidence task is generated, and no strong conclusion is output.

[0050] As one implementation method, in step (5) of this embodiment, when locating the affected downstream derived memory subgraph along the memory dependency graph, it is subject to at least one of the following constraints: preset maximum propagation depth, preset maximum number of processing nodes, memory type filtering rules, and tenant permission boundaries; for derived memories that are not located in the affected subgraph or whose validity has not changed in the positive supporting evidence and core evidence group, no recalculation task is created.

[0051] As one implementation method, this embodiment also includes: The memory recall is divided into ordinary task recall, verification recall, audit recall and recalculation recall. Ordinary task recall is prohibited for memories in the isolated, pending verification, frozen and invalid states. Degraded recall is set for memories in the expired state. Controlled access is set for verification recall and audit recall. In response to concurrent writes by multiple agents to mutually exclusive memories targeting the same principal object, the same attribute predicate, and overlapping effective time ranges, conflict merge keys are generated according to tenant, principal object, attribute predicate, effective time range, permission domain, and memory type. When the merge keys of conflict groups created by multiple write transactions overlap with the conflict participating nodes, multiple conflict groups are merged into the same target conflict group, and the ordinary recall permission and index state synchronization events are recalculated with the latest node-level state version. In response to receiving a manual or automatic arbitration result, the arbitration result is written back to the main memory, and the normal recall index state synchronization and downstream dependency propagation are triggered again through the updated node-level state version.

[0052] Example 2

[0053] This embodiment provides a multi-agent memory conflict isolation recall state synchronization and derived memory incremental recalculation system, applied to a multi-agent shared long-term memory system including a main memory bank, vector index, keyword index, graph index, and memory dependency graph, including: The memory normalization and evidence anchoring module is used to respond to multi-agent memory writing requests, generate evidence anchoring memory nodes in the main memory, and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. The conflict retrieval and conflict group isolation module is used to filter candidate existing memories from the main memory and perform typed conflict detection. When the conflict conditions are met, a conflict group is created or reused, conflict memories are associated with the same conflict group identifier, and ordinary recall permissions are calculated based on the verification status and permission risk of each party in the conflict. The recall index status synchronization module is used to generate index status synchronization events carrying node-level status versions, synchronize and project the recall control status and ordinary recall permission to the vector index, keyword index and graph index respectively, and compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory before the ordinary recall service returns the candidate results. When the index synchronization version is lagging behind or synchronization fails, at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering is performed. The memory dependency graph storage module is used to store the derived dependency relationships between memory nodes, and is logically divided into mutually isolated ordinary recall graph views and dependency propagation graph views. The upstream state change monitoring and downstream derived memory location module is used to respond to the state versioning change event of the upstream memory node, locate the affected downstream derived memory subgraph along the memory dependency graph after deduplication according to the state change event identifier and node-level state version, and process the affected nodes in the topological order. The dependency evidence survival rate calculation module is used to calculate the effective and credible evidence support rate of affected downstream derived memories based on the master memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence, and to perform hierarchical status determination in combination with counterexample effectiveness rate, core evidence group rules and permission rules. The derived memory incremental recalculation module is used to perform incremental recalculation only based on the remaining valid evidence that is valid and visible in its upstream dependencies when the recalculation conditions are met. This generates a new version of the derived memory, marks the old version of the derived memory as a historical version and retains the audit association, and generates a version replacement event to continue to trigger the re-evaluation of downstream derived memories and the state synchronization of each retrieval index. The verification, arbitration, and auditing module is used to recall conflict memories and their evidence anchors by conflict group identifier for verification or arbitration, and write the arbitration results back to the main memory. Specifically, the conflict retrieval and conflict group isolation module sends an index status synchronization event to the recall index status synchronization module; the upstream status change monitoring and downstream derived memory location module sends a status change event to the dependent evidence survival rate calculation module; the version replacement event generated by the derived memory incremental recalculation module is sent back to the recall index status synchronization module; and the arbitration result written back by the verification arbitration and audit module triggers the upstream status change monitoring and downstream derived memory location module to generate a status versioning event.

[0054] As one implementation, the recall index state synchronization module in this embodiment writes the memory identifier, node-level state version, index synchronization version, recall control state, ordinary recall permission, conflict group identifier, and version identifier into the vector index; writes the memory identifier, node-level state version, index synchronization version, ordinary recall permission, recall control state, tenant identifier, and permission domain into the keyword index; and writes the memory identifier, node-level state version, index synchronization version, ordinary recall permission, recall control state, conflict group identifier, and version identifier into the nodes or edges of the graph index. The ordinary recall graph view in the memory dependency graph storage module is filtered by the ordinary recall permission, permission domain, and index synchronization version, while the dependency propagation graph view retains the memory nodes and their dependent edges that are isolated, frozen, in historical versions, or in audit tombstone record states.

[0055] Example 3

[0056] This invention proposes a method and system for multi-agent memory conflict isolation and incremental recalculation of derived memories based on recall state synchronization and evidence survival rate dependence. The system establishes an evidence-anchored memory node for each memory and records the generating agent, generation time, version, memory type, lifecycle state, recall control state, verification state, evidence anchor point, and derived dependency edges. When any agent writes a new memory, the system first filters candidate existing memories based on entity object, attribute predicate, time range, permission domain, and memory type, and performs typed conflict detection between the memory to be written and the candidate existing memories. If the conflict conditions are met, the system creates a conflict group, associates the conflicting parties with the same conflict group identifier, and calculates ordinary recall permission based on situations such as non-arbitration, confirmed, or permission risk. Non-arbitrated conflicting memories default to isolation, pending verification, or frozen states, while confirmed trusted versions can retain ordinary recall eligibility when permitted by the policy. The system simultaneously synchronizes the recall control state and ordinary recall permission to the vector index, keyword index, and graph index, ensuring that unpermitted conflicting memories do not participate in ordinary task recall. When any upstream evidence memory undergoes logical deletion, freezing, isolation, deweighting, summary replacement, or a change in untrusted status, the system locates the affected downstream derived memories along the memory dependency graph and calculates the dependent evidence survival rate for each derived memory. Based on the dependent evidence survival rate and a preset threshold, the system marks the derived memory as invalid, expired, downweighted for recall, or triggers incremental recalculation. During incremental recalculation, the system only uses the remaining valid evidence to regenerate a new version of the derived memory; the old version is retained for auditing and backtracking.

[0057] Reference Figure 2The multi-agent memory conflict isolation and derived memory incremental recalculation system provided in this embodiment of the invention includes a main memory, a vector index, a keyword index, a graph index, a memory dependency graph, as well as a memory normalization and evidence anchoring module, a candidate conflict retrieval module, a typified conflict detection module, a conflict group isolation module, a recall state control module, a recall index state synchronization module, a memory dependency graph storage module, an upstream state change monitoring module, a downstream derived memory location module, a dependency evidence survival rate calculation module, a derived memory incremental recalculation module, and a verification arbitration and auditing module.

[0058] The main memory stores evidence anchoring memory nodes. Vector indexes, keyword indexes, and graph indexes are used for general task retrieval; all three types of indexes are written to node-level state versions and index synchronization versions. The memory dependency graph stores the derived dependencies between memory nodes, logically divided into a general retrieval graph view and a dependency propagation graph view.

[0059] The memory normalization and evidence anchoring module receives memories to be written, normalizes their format, binds traceable evidence sources to each memory, and generates evidence-anchored memory nodes to be written to the main memory. The candidate conflict retrieval module filters existing memories that may conflict with the main memory before the memories to be written enter it. The categorized conflict detection module performs factual conflict, temporal conflict, preference conflict, policy conflict, and permission conflict detection between the memories to be written and candidate existing memories. The conflict group isolation module creates or reuses conflict groups when determining conflicts, associates conflicting memories with the same conflict group identifier, and preserves the evidence anchor points and version identifiers of each conflicting party. The recall status control module uniformly determines whether a memory can participate in different types of recalls and calculates the ordinary recall permission for members within the conflict group. The recall index status synchronization module generates index status synchronization events carrying node-level status versions, synchronously projects the recall control status and ordinary recall permission to the vector index, keyword index, and graph index, and performs version comparison and post-filtering before the ordinary recall service returns candidate results.

[0060] The memory dependency graph storage module stores the derived dependencies between memory nodes. The upstream state change monitoring module monitors state versioning change events of memory nodes in the main memory. The downstream derived memory location module locates the downstream derived memory subgraph affected by state changes along the memory dependency graph. The dependency evidence survival rate calculation module calculates the effective credible evidence support rate and counterexample effectiveness rate of affected derived memories, and performs hierarchical state determination based on the core evidence group rules. The derived memory incremental recalculation module performs incremental recalculation on derived memories that meet the recalculation conditions based on the remaining effective evidence, generating new versions of derived memories. The verification arbitration and auditing module recalls conflicting memories and their evidence anchors according to the conflict group identifier for verification or arbitration, and writes the arbitration results back to the main memory.

[0061] Reference Figure 2 The control flow between modules is as follows: Multi-agent memory write requests are processed by the memory normalization and evidence anchoring module, the candidate conflict retrieval module, and the typified conflict detection module, and then split into two branches by the conflict judgment node. If the conflict conditions are not met, the request is written to a valid memory node and the memory dependency graph is updated by the memory dependency graph storage module. If the conflict conditions are met, the conflict group isolation module creates or reuses a conflict group. After the recall status control module calculates the ordinary recall permission, the recall index status synchronization module synchronizes the recall control status and the ordinary recall permission to the vector index, keyword index, and graph index. After index synchronization is complete, the index synchronization version is recorded and returned to the memory dependency graph storage. If index synchronization fails, it is filtered twice by the blacklist and the main database status before returning to the memory dependency graph storage.

[0062] State versioning events are triggered by three sources: first, state changes generated by the memory dependency graph storage module after new memory is written or derived dependency edges are established; second, new derived versions and version replacement events generated by the derived memory incremental recalculation module; and third, arbitration result write-back events from the verification arbitration and auditing module. State versioning events are located along the memory dependency graph by the downstream derived memory positioning module, which then locates the affected subgraph. The dependency evidence survival rate calculation module calculates the effective and credible evidence support rate and counterexample effectiveness rate, and executes hard rules and threshold classification. The classification results are divided into three paths: those below the failure threshold or triggering hard failure rules are marked as invalid and ordinary recall is suppressed, and the verification arbitration and auditing module is notified to record the audit; those in the middle range or with core evidence awaiting verification are marked as expired, awaiting verification, or downgraded, added to the recalculation queue, and the verification arbitration and auditing module is notified to record the audit; those meeting the recalculation conditions are recalculated by the derived memory incremental recalculation module based on the remaining effective evidence, generating new derived versions and version replacement events. After the recall status control module calculates ordinary recall permission for the new version, the recall index status synchronization module synchronizes it to each retrieval index. After the arbitration result of the verification and auditing module is written back, if the arbitration conclusion is to generate a summary to replace the memory, a new derived version and version replacement event will be generated, which will continue to trigger index synchronization and downstream propagation.

[0063] The aforementioned modules can be merged or split in physical implementation. For example, the memory normalization and evidence anchoring module can be split into a memory normalization sub-module and an evidence anchoring sub-module; the candidate conflict retrieval module, the typified conflict detection module, and the conflict group isolation module can be merged into a conflict retrieval and conflict group isolation module; the upstream state change monitoring module and the downstream derived memory localization module can be merged into a state monitoring and subgraph localization module. The merging or splitting of modules does not affect the implementation of this invention.

[0064] Evidence anchor memory nodes are used to describe a memory and its source, generation process, recall status, and version relationship. Fields in evidence anchor memory nodes can be categorized as follows: basic identifier fields, such as memory identifier, tenant identifier, and subject identifier; semantic fields, such as memory type, entity key, attribute predicate key, value, and valid time range; evidence fields, such as evidence anchor identifier, evidence type, evidence summary, source link, source fragment identifier, and source tool call identifier; generation fields, such as writing agent identifier, generating agent identifier, generation time, model version, and prompt version; status fields, such as lifecycle status, recall control status, confidence level, conflict group identifier, and verification status; version fields, such as version identifier, predecessor version identifier, replacement relationship, replaced relationship, and version relationship status; dependency fields, such as upstream dependency set, dependency set identifier, and dependency snapshot version; permission fields, such as permission domain, visibility scope, normal recall permission, audit recall permission, and recalculation evidence usage strategy; and synchronization fields, such as node-level status version, index synchronization version, synchronization event identifier, most recent synchronization time, and synchronization failure reason.

[0065] Memory types can include raw factual memories, dialogue summaries, user profiles, user preferences, long-term habits, agent strategy memories, tool usage experiences, and team-shared knowledge.

[0066] To avoid confusion regarding state meanings, memory states are split into mutually orthogonal fields. Lifecycle states include valid, invalid, and deleted; recall control states include active, isolated, pending verification, frozen, and expired; verification states include unverified, verification in progress, confirmed, rejected, and merged; version relationship states include current, replaced, obsolete, recalculation source, and tombstone; ordinary recall permission is true or false, calculated from the above states and permission rules; recalculation evidence usage policy is available, unavailable, and low-trust reference.

[0067] In this invention, logical deletion refers to the main memory retaining the memory node and audit information, but setting its lifecycle status to deleted or invalid; recall deletion refers to removing the memory from the ordinary recall index, or setting its ordinary recall permission to prohibited. Logical deletion is not the same as recall deletion, and recall deletion does not necessarily prevent the memory from being used as evidence for internal recalculation.

[0068] The ordinary recall index does not directly rely on a single status field, but rather filters based on a combination of multiple status fields and permission rules. Specifically, the filtering conditions for the ordinary recall index include: for statuses such as isolated, pending verification, frozen, and invalid, the ordinary recall permission is set to false; for expired statuses, the ordinary recall permission can be kept true, but the recall ranking score is subject to a weighting factor; for historical version statuses, the ordinary recall permission is set to false by default; and for active statuses, the ordinary recall permission is set to true.

[0069] Derived memory recalculation does not directly reuse ordinary recall permissions. Instead, it determines whether upstream memories are valid evidence, low-confidence reference evidence, or unusable evidence based on the recalculation evidence usage strategy. Valid evidence refers to upstream memories that, within the current permission domain and current state version, have a valid lifecycle, are not isolated or frozen, are permitted for recalculation by the recalculation evidence usage strategy, and meet the confidence requirements. Low-confidence reference evidence refers to upstream memories that are pending verification, have low confidence, or are only for verification purposes. These are not included in the valid evidence set but can be used to generate conservative versions, pending conclusions, or supplementary verification tasks. Through this separation, lifecycle expiration, recall isolation, arbitration verification, version replacement, and internal recalculation are not confused as the same concept.

[0070] When the terms "active," "isolated," "pending verification," "frozen," "expired," "invalid," and "historical" appear in the recall table, it represents a recall state projection calculated from multiple state fields, rather than requiring the system to store only one mutually exclusive state enumeration. This projection can be calculated from at least the lifecycle state, recall control state, verification state, version relationship state, permission domain, ordinary recall permission, and recalculation evidence usage strategy.

[0071] The node-level state version is a memory node-level state version that increments each time the lifecycle state, recall control state, verification state, version relationship, or recalculation evidence usage strategy of the memory node changes. Synchronization event identifiers or global event sequences are used for idempotent processing of synchronization events and cross-index retries. The index synchronization version indicates the node state version that a given index entry or index view has been synchronized to. By distinguishing between node state versions, synchronization event identifiers, and index synchronization versions, older synchronization events can be prevented from overwriting new states, and it also facilitates the normal recall service in determining whether the index-side state is lagging behind the master database.

[0072] A conflict group is used to store a set of memory nodes that have conflicting relationships with each other, and serves as an access point for verification, auditing, and arbitration. Conflict group fields may include conflict group identifier, conflict type, conflict score, set of involved memory nodes, set of conflict edges within the group, set of evidence anchor points corresponding to the conflict memory, first detection time, arbitration status, general recall strategy, and audit recall strategy.

[0073] The default policy after a conflict group is created is "suppress all unarbitrated memories," meaning that unconfirmed conflict memories within the same conflict group are not allowed to participate in normal task recalls. If a memory in a conflict group has been manually confirmed, supported by highly reliable tools, or has compliant authorization, the system can set the memory's verification status to confirmed and the normal recall permission to true, while continuing to isolate unconfirmed or rejected memories in the same group. When a conflict group is in a state of incomplete arbitration, unconfirmed members are prohibited from normal recalls by default; members who have been confirmed manually, supported by highly reliable tools, or have compliant authorization can resume normal recalls provided that the permission rules are met and they do not return simultaneously with other valid conflict edge members in the same normal recall result set. Allowing access is limited to confirmed members within the group, not unconditionally allowing access to the entire conflict group.

[0074] Within a conflict group, each pair of conflicting edges is recorded. Each conflicting edge can include a source memory identifier, a target memory identifier, a conflict type, a conflict score, a trigger rule, a detection time, and an edge state. When a conflict group contains more than three memories, the system does not presume that all memories within the group are mutually exclusive. Instead, it determines which two memories have factual, temporal, preference, policy, or permission conflicts based on the conflicting edges. Normal recall permissions can first be suppressed according to the default policy for the conflict group, and then partially allowed based on the confirmed memories and specific conflicting edges.

[0075] Memory dependency edges are used to represent the relationship between derived memories and upstream evidence memories. Dependency edges are directed edges, pointing from upstream evidence memories to downstream derived memories. For example, if a user profile is generated from original preference memories, tool result memories, and dialogue summaries, the system establishes three dependency edges pointing from the aforementioned upstream memories to the user profile, and assigns a dependency weight to each edge.

[0076] The dependency edge field can include upstream memory node identifier, downstream derived memory node identifier, dependency type, dependency weight, evidence role, support direction, establishment time, and creator. Dependency type can include summary dependency, profile dependency, preference dependency, strategy dependency, and tool experience dependency. Dependency weight represents the contribution of upstream memory to downstream derived memory, and is preferably recorded on the dependency edge rather than only on the memory node, because the contribution of the same upstream memory to different downstream derived memories may vary. Dependency weight can be determined by the output of the generative model, rule configuration, evidence type, or manual annotation. Evidence role can include core evidence, auxiliary evidence, counterexample evidence, and time-limited evidence. Support direction can include positive support, negative constraint, counterexample, or only for time-limited purposes. For counterexample evidence or negative constraint evidence, the system does not include it in the numerator of the positive support survival rate, but calculates the counterexample effectiveness rate or triggers the rule to be verified separately, avoiding the possibility that valid counterexample evidence might incorrectly increase the survival rate of derived conclusions.

[0077] The system categorizes recall into four types: general task recall, verification recall, audit recall, and recalculation recall. General task recall refers to recall used by an agent to answer user questions, perform task planning, generate recommendations, select tools, or generate strategies. Verification recall refers to controlled recall used by a verification agent or rule module to determine conflicts or verify the credibility of evidence. Audit recall refers to controlled access to the complete chain of evidence in scenarios such as manual auditing, compliance auditing, or log interpretation. Recalculation recall refers to internal recall used during derived memory recalculation to obtain remaining valid evidence or historical versions.

[0078] The recall permissions under each recall status projection are as follows: In the active state, normal task recalls, verification recalls, audit recalls, and recalculation recalls are all allowed; in the isolated state, normal task recalls are prohibited, verification recalls and audit recalls are allowed, and recalculation recalls can be recorded as evidence of impact; in the pending verification state, normal task recalls are prohibited, verification recalls and audit recalls are allowed, and recalculation recalls are not counted as valid evidence but can be used as low-confidence reference evidence; in the frozen state, normal task recalls are prohibited, verification recalls require privileges, audit recalls are allowed, and recalculation recalls are not considered valid evidence; in the historical state, normal task recalls are prohibited by default, verification recalls and audit recalls are allowed, and recalculation recalls can be used as historical versions; in the expired state, normal task recalls are downgraded, verification recalls and audit recalls are allowed, and recalculation recalls are allowed to be recalculated; in the invalid state, normal task recalls are prohibited, verification recalls and audit recalls are allowed, and recalculation recalls are not considered valid evidence.

[0079] The fact that a pending verification state is prohibited in a normal task recall does not mean that the memory is completely unavailable in all internal processes. For derived memory recalculation or conflict verification processes, the system does not include the pending verification memory in the set of valid evidence, but instead treats it as low-confidence reference evidence for generating conservative versions, pending verification conclusions, or supplementary verification tasks.

[0080] The memory normalization and evidence anchoring module is used to transform candidate memories from different agents, tools, or session sources into a unified structure. For user-statement type memories, the system extracts entity objects, attribute predicates, values, time ranges, and context fragments; for tool result type memories, the system records the tool call identifier, returned result summary, and tool execution context; for derived memories, the system records the set of upstream memories it depends on and their weights. During normalization, the system does not require all memories to have the same fields, but at least for subsequent conflict detection and dependency propagation, it retains entity objects, memory types, evidence anchors, generating agents, generation time, version, lifecycle states, and recall control states.

[0081] The evidence anchoring module is used to bind a traceable source of evidence to each memory. Evidence anchors can correspond to original dialogue fragments, tool call results, external system events, manual confirmation records, file fragments, webpage fragments, or other verifiable sources. Evidence anchors preferably store evidence summaries, source identifiers, timestamps, the generating agent, and permission domains, rather than storing unnecessary plaintext sensitive content. Through evidence anchors, the system can preserve the original evidence from both sides in the event of a conflict, avoiding direct overwriting that would prevent subsequent determination of which memory is more credible.

[0082] The candidate conflict retrieval module filters existing memories that may conflict before they are written into the long-term memory. Candidate filtering can be performed based on the following dimensions: identical or semantically equivalent entity objects; identical attribute predicates or belonging to the same conflict domain; overlapping time ranges or contradictory sequences; identical permission domains, tenants, users, or agent teams; identical memory types, or memory types that can influence each other (e.g., factual memories influence user profiles, tool experience influences policy memories); and vector similarity, keyword similarity, or graph proximity reaches a candidate threshold. This module does not directly determine conflicts, but rather reduces the scope of conflict detection, improving online processing efficiency during writing.

[0083] The typified conflict detection module is used to determine conflicts between the memory to be written and the candidate existing memory. Conflict types include at least: factual conflict, i.e., the same entity and the same attribute take mutually exclusive values ​​within the same valid time range; temporal conflict, i.e., the temporal order, validity period, or event occurrence time of two memories cannot be simultaneously true; preference conflict, i.e., user preferences or taboo information contradict each other; policy conflict, i.e., the subsequent execution policies given by the agent's policy memories are mutually exclusive; and permission conflict, i.e., the visibility, sharing, or recall scope of the new memory exceeds the permission domain of its evidence source.

[0084] In one implementation, the conflict score is calculated using the following formula:

[0085] in, Conflict score; For fact conflict sub-scores; Sub-scores for time conflicts; For preference conflict sub-scores; For strategy conflict sub-scores; Sub-scores for permission conflicts; Sub-scores for semantic conflicts; , , , , , These are the weights corresponding to factual conflicts, time conflicts, preference conflicts, policy conflicts, permission conflicts, and semantic conflicts, respectively. Each sub-score is a value between 0 and 1, with each weight greater than or equal to 0 and the sum of the weights greater than 0. After applying the above normalization formula, CS is between 0 and 1; if the sum of each weight is pre-constrained to be 1 during implementation, the denominator can be omitted. If the conflict score is greater than or equal to a preset conflict threshold, or if any hard conflict rule is triggered, the conflict condition is determined to be met. The conflict threshold can be configured according to the memory type; the example values ​​are 0.6 to 0.9.

[0086] Each sub-score can be obtained by rules, models, or a combination of both. The factual conflict sub-score is higher when mutually exclusive values ​​occur for the same entity and the same attribute within overlapping valid timeframes; the temporal conflict sub-score increases when the timing, validity period, or sequential dependence of events cannot simultaneously hold; the preference conflict sub-score increases when both "preferential selection" and "explicit prohibition of selection" exist; the strategy conflict sub-score increases when two strategy memories require mutually exclusive tools, mutually exclusive execution paths, or mutually exclusive security policies; and the permission conflict sub-score is higher when the shared scope or recall scope of the new memory exceeds the permission domain of the evidence source. Semantic conflict sub-scores can be obtained by training a natural language reasoning model, rule base, or manually labeled samples. The aforementioned natural language reasoning model can employ textual entailment models or contradiction detection models known in the art. The model's training data construction, preprocessing, and training processes are conventional techniques in the art, and this invention does not rely on a specific model structure. Rules such as hard permission overstepping and mutual exclusion of core evidence can directly trigger conflicts without relying on model scores.

[0087] To reduce reliance on subjective judgments from large language models, determinable conflict conditions are first handled through rules, with model judgments serving as supplementary evidence. Determinable rules include mutual exclusion rules for enumerated values, time interval conflict rules, permission out-of-bounds rules, security policy mutual exclusion rules, and core evidence mutual exclusion rules. Only when rules cannot directly determine whether natural language semantics are contradictory does the system invoke the semantic model to obtain semantic conflict sub-scores, and write the model output, prompt version, model version, and confidence level into the conflict audit event. Thus, even without relying on a specific large model, the system can still perform conflict isolation and recall control based on structured fields, permission rules, and time rules.

[0088] When the typified conflict detection module determines that the memory to be written meets the conflict condition with at least one existing memory, the conflict group isolation module does not directly delete the old memory, nor does it directly allow the new memory to overwrite the old memory. Instead, it performs the following processing: creates or reuses a conflict group identifier; adds the memory to be written and the conflicting existing memory to the same conflict group; retains the evidence anchor point, version, generating agent, generation time, and permission domain of both conflicting parties; calculates the general recall strategy for the conflict group based on the conflict type, evidence credibility, verification status, and permission risk, and updates the recall control status of the memory to be written and / or the existing memory to be isolated, pending verification, or frozen; generates a conflict audit event, records the conflict detection process, conflict score, triggering rules, and participating memory nodes; and sends a status synchronization event to the recall status control module.

[0089] If neither party in the conflict has been verified, both enter a pending verification state and the ordinary recall permission is deemed false. If existing memories have been manually confirmed or have highly credible evidence, while new memories originate from low-credibility sources, the new memories enter an isolated state, and existing confirmed memories can continue to be recalled according to the conflict group strategy. If the conflict involves permission overstepping or security policies, the relevant memories enter a frozen state until auditing or arbitration is completed. For multiple conflict groups formed by concurrent writes from multiple agents within the same time window, the system can perform conflict group merging based on entity objects, attribute predicates, effective time ranges, and permission domains to prevent the same conflict from being split into multiple verification entry points.

[0090] The recall status control module is used to uniformly determine whether a memory can participate in different types of recalls. For states such as isolated, pending verification, frozen, and invalid, the ordinary recall permission is set to false; for expired states, the ordinary recall permission can be kept true, but the recall ranking score is subject to a weighting factor. After the conflict group isolation module completes the creation of the conflict group and the derived memory incremental recalculation module generates a new derived version, the recall status control module calculates the ordinary recall permission based on the memory status field and permission rules, and then hands it over to the recall index status synchronization module to synchronize it to each retrieval index.

[0091] The recall index status synchronization module is one of the key distinguishing features of this invention. This module synchronizes the recall control status, ordinary recall permission, and status version of the memory node to the retrieval index actually used by ordinary task recall, instead of only recording the status field in the main database.

[0092] In one implementation, the system maintains state projections for three types of indexes. For each vector entry in the vector index, a memory identifier, vector identifier, node-level state version, index synchronization version, recall control status, ordinary recall permission, conflict group identifier, and version identifier are written. During ordinary vector retrieval, the retrieval filtering conditions exclude entries with false ordinary recall permissions, and apply a weighting coefficient to expired entries. When synchronization fails or the version lags behind, the memory identifier is written to a blacklist or post-filter table, and secondary filtering is performed based on the master database status. For the keyword index, a memory identifier, node-level state version, index synchronization version, ordinary recall permission, recall control status, tenant identifier, and permission domain are written. During ordinary keyword recall, filtering is performed by permission, tenant, and permission domain before the inverted index hit candidates are returned. If the index synchronization version of a hit entry is less than the node-level state version, the master database is queried and the candidate is discarded. The nodes or edges of the graph index are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, conflict group identifiers, and version identifiers; normal graph traversal skips nodes or edges that are prohibited from normal recall; verification or auditing graph traversal can access the complete conflict subgraph by conflict group identifier; before returning the graph traversal results, it is pruned again according to the master database status and blacklist.

[0093] Index state synchronization can be achieved through in-situ metadata updates, rebuilding after deleting old index entries, writing to a bypass filter table, or performing candidate post-filtering in the recall service. Regardless of the implementation method, the ordinary recall service uses the master database node-level state version as the final decision version to avoid asynchronous index delays causing conflict memories to re-enter the ordinary task context.

[0094] When the memory state changes, the recall index state synchronization module generates an index update event. This event can include a synchronization event identifier, a memory identifier, a node-level state version, the target index type, recall control status, normal recall permission, conflict group identifier, version identifier, and the number of retries. Each index side deduplicates the events based on the synchronization event identifier and updates the state projection only if the node-level state version carried by the event is not lower than the index synchronization version already recorded on the index side. After the update, the index synchronization version is set to the corresponding node-level state version to prevent older events from overwriting new states.

[0095] If the index update fails, the system temporarily adds the corresponding memory to the regular recall blacklist or writes it to the post-filter table. The regular recall service then performs secondary filtering based on the blacklist, post-filter table, and master database status before returning candidate results, until the index status is successfully synchronized or the preset degradation strategy is reached. The difference between the post-filter table and the blacklist is that the post-filter table records candidate entries to be filtered based on memory identifier and node-level status version. The regular recall service queries this table and discards outdated entries before returning candidate results. The blacklist, on the other hand, removes the corresponding memory identifier after successful index synchronization. The blacklist has a retention period, and index synchronization retries have a retry limit; exceeding the limit results in manual or offline repair. This index synchronization event ensures consistent visibility on the regular recall side; the primary trigger source for propagation remains the status change event or arbitration result write-back event in the master database, rather than depending on whether a specific index has been updated.

[0096] In a more stringent implementation, before returning candidate results, the normal recall service compares the index synchronization version on the index side of the candidate memory with the master database node-level status version. If the index-side version lags behind the master database version, the system prioritizes filtering the candidate memory based on the master database status and blacklist, or restricts the candidate memory to verification recall and audit recall. This mechanism ensures that index synchronization failure or delay will not become a loophole for conflicting memories to re-enter the normal task context.

[0097] The memory dependency graph storage module is used to store the derivation relationships between memory nodes. Nodes in the graph represent original or derived memories, and edges indicate that downstream memories depend on upstream memories. The memory dependency graph and the ordinary recall graph index can be physically stored in the same graph database or stored separately; however, logically they are distinguished as different views. The ordinary recall graph view is filtered by ordinary recall permissions, permission domains, and index synchronization versions, and is used for ordinary task recall; the dependency propagation graph view retains isolated, frozen, historical version, and audit tombstone nodes and their dependent edges, and is used for state propagation, recalculation, and auditing. The aforementioned audit tombstone record refers to the minimum traceable record retained after a memory is deleted, replaced, or expired, used to store version identifiers, evidence summaries, reasons for state changes, and dependency edge information. Therefore, even if a memory has been filtered from the ordinary recall graph view, the system can still locate its downstream derived memories along the dependency propagation graph view.

[0098] The upstream state change monitoring module is used to monitor changes in the state of memory nodes. Triggering conditions include at least: the original memory is logically deleted, its lifecycle expires, the recalculation evidence is set to unavailable or written to the audit tombstone record using the recalculation evidence usage strategy; the original memory is isolated, frozen, or marked as pending verification; the confidence level of the original memory is reduced to below the threshold; the original memory or derived memory is replaced by a new digest version, a new derived version, or other new versions; the source of memory evidence is revoked, expired, or determined to be unreliable; and the conflict arbitration result causes certain memories to become invalid or demoted.

[0099] When the triggering condition occurs, this module sends a state change event to the downstream derived memory location module, carrying the changed node, the state before the change, the state after the change, the reason for the change, and the changed version. If a memory is only recalled and deleted, but is still allowed to be used as internal recalculation evidence, it does not necessarily reduce the evidence survival rate of downstream derived memories. Only the recall index can be synchronized without triggering a decrease in the downstream survival rate. Only when its lifecycle expires, is frozen and isolated, the recalculation evidence usage policy is set to unavailable, permissions are not visible, or the confidence level drops below the threshold, will it be used as valid evidence to reduce the event triggering downstream hierarchical processing. If no state versioning change event is generated, the current round of processing ends and the audit record is retained.

[0100] The impact of different state change types on ordinary task recall, effective credible evidence support rate, and derived memory reassessment is as follows: When only recall deletion or ordinary recall permission is closed, ordinary task recall is affected, but the effective credible evidence support rate is not reduced (unless the recalculation evidence usage strategy is simultaneously set to unavailable). Derived memory reassessment is usually not triggered, or only dependency state changes are recorded. When lifecycle expires, is logically deleted, or becomes invalid, ordinary task recall is affected, the effective credible evidence support rate is reduced, and derived memory reassessment is triggered. When isolated, frozen, or pending verification, ordinary task recall is affected; isolation and freezing are treated with an effectiveness coefficient of 0, pending verification is treated as low-credibility reference evidence, and derived memory reassessment is triggered. When the recalculation evidence usage strategy is set to unavailable, it may affect... When a normal task recall is affected, the rate of support for valid and credible evidence decreases, and a reassessment of derived memories is triggered. When permissions are invisible or revoked, normal task recall is affected, the rate of support for valid and credible evidence decreases in the current permission assessment context, and a reassessment of derived memories is triggered. Typically, a context-level recall projection or a context-level derived version is formed first, and the global memory state is only changed when global permissions are revoked or evidence becomes invalid. When the confidence level drops below the threshold, normal task recall can be affected, the rate of support for valid and credible evidence is reduced by the confidence level normalization coefficient or the validity coefficient, and a reassessment of derived memories is triggered. When a new version replaces an old version, normal task recall is affected, derived memories that depend on the old version are reassessed, and the process continues to propagate downstream through the version replacement event.

[0101] The downstream derived memory location module starts from the changed node along the memory dependency graph to find the directly or indirectly affected derived memories. To avoid infinite propagation or overcomputation, the system sets maximum propagation depth, maximum number of nodes, memory type filtering rules, and tenant permission boundaries. It also performs deduplication through state change event identifiers or dependency snapshot versions to prevent the same upstream state change from repeatedly triggering the recalculation of the same derived memory during concurrent writes or retries.

[0102] The system processes affected nodes using a topological order, first handling directly dependent derived memories, and then processing further downstream memories that depend on these derived memories. If a derived memory has been determined to be invalid, its downstream nodes treat that derived memory as invalid evidence when calculating the support rate of valid and credible evidence.

[0103] If a derived memory is recalculated to generate a new version, the system continues to propagate the replacement relationship from the old version to the new version as a new state change event downstream. For further downstream memories that depend on the old version, the system decides whether to re-attach to the new version, recalculate the support rate of valid and credible evidence, enter a pending verification state, or retain the historical dependency based on the version snapshot of the dependent edge. Thus, the incremental recalculation of derived memories will not stop at a single node, but will continue to maintain the consistency of further downstream derived conclusions.

[0104] The downstream derived memory positioning module sends the located affected derived memory subgraphs and deduplicated state change events to the dependent evidence survival rate calculation module, which then performs the calculation of the effective and credible evidence support rate and the graded state determination.

[0105] The dependent evidence survival rate calculation module does not simply delete all downstream derived memories, nor does it recalculate the entire dataset each time. Instead, it calculates how much valid evidence still supports each derived memory. The dependent evidence survival rate calculated by this module is also called the valid credible evidence support rate. In one implementation, derived memories... Valid and credible evidence support rate Calculate using the following formula:

[0106] in, Indicates derived memory; This is the sequence number of the upstream positive support dependency edge of this derived memory; For the first The dependency weight of the upstream positive support dependency edge, and >0; is the validity coefficient of the i-th upstream memory in the current permission evaluation context, and its value ranges from 0 to 1; is the confidence normalization coefficient of the i-th upstream memory, with a value ranging from 0 to 1; the denominator is the sum of all positive support dependency weights of the derived memory. It is calculated jointly by lifecycle status, recall control status, recalculation evidence usage strategy, and permission visibility, rather than being determined solely by ordinary recall permission.

[0107] Example values ​​are as follows: 1 for active status; 0.5 to 0.8 for expired status; 0 for pending verification status, or recorded separately as low-credibility reference evidence instead of being counted as valid evidence; 0 for isolated status; 0 for frozen status; 0 for invalid status; 0 for deleted status; and 0 to 0.3 for historical or replaced versions. The above values ​​are merely examples; in actual implementation, different parameters can be set according to memory type, evidence type, business risk level, and permission domain.

[0108] If some upstream evidence cannot be used by the current subject due to lack of access permissions, then this evidence should be used within the current access permission assessment context. Set to 0; alternatively, the percentage of evidence that is not visible due to permissions can be separately tallied to trigger rules requiring verification, recalculation, or expiration. (This is due to the invisibility of permissions.) The priority of demotion primarily applies to recall projections, demotion strategies, recalculation tasks, or context-level derived versions within the current permission evaluation context; unless the permission change involves global permission revocation, invalidation of evidence sources, or write-back of arbitration results, it does not necessarily invalidate the global lifecycle state of the original derived memory.

[0109] This represents the proportion of derived memories that are still supported by valid and credible upstream evidence in their current state. Its decrease can stem from evidence invalidation, unvisible permissions, the recalculation of evidence usage policies becoming unavailable, or a drop in confidence, not just the deletion of evidence nodes. The technical significance of this formula lies not in protecting the weighted average formula alone, but in mapping the master database state field, index recall control field, recalculation of evidence usage policies, permission visibility, and dependency edge weights to derived memory version control actions. The formula's input comes from the structured state and dependency graph stored within the computer system, and its output is not a manually judged result, but rather a control over the derived memory's lifecycle state, recall control state, ordinary recall permission, context-level recall projection, recalculation queue priority, and new version write actions. This mapping relationship enables upstream state changes to be translated into executable index updates, candidate filtering, and derived version update operations.

[0110] If the dependency set contains counterexamples, negative constraint evidence, or evidence used only to limit the time range, the system does not include them in the numerator of the positive support survival rate, but instead calculates the counterexample effectiveness rate separately. :

[0111] in, The dependency edge number is the number of the counterexample evidence or negative constraint evidence; For the first Dependency weight of counterexample evidence or negative constraint evidence; The validity coefficient of this counterexample evidence under the current state and permission context; This is the normalized confidence coefficient for the counterexample evidence; the denominator is the weighted sum of all counterexample evidence or negative constraint evidence. When there is no counterexample evidence or the weighted sum is 0, Record it as 0 or do not trigger the counterexample rule. When Even if the preset counterexample threshold is exceeded, A higher value will also mark derived memories as pending verification, trigger recalculation, or reduce the weight of ordinary recall.

[0112] When a derived memory lacks supporting evidence, or the sum of the weights of the supporting evidence is 0, the system does not forcibly apply the above division formula. Instead, it treats it as having no valid supporting evidence: marking the derived memory as invalid, pending verification, or generating a conservative version requiring supplementary evidence. If the dependency set only contains counterexample evidence or time-limited evidence, the system does not generate a strong derived conclusion, but instead generates a restrictive conclusion, an empty conclusion, or a supplementary evidence task.

[0113] For derived memories whose core evidence has expired, the system sets hard rules for core evidence. Core evidence is managed by core evidence groups, and each group is configured with rules such as "all must be valid," "any valid evidence is sufficient," or "can be replaced by another evidence group." When a core evidence group does not meet its validity rules, or when core evidence enters an isolated, frozen, invalid, or deleted state, even if the overall survival rate is high, recalculation, pending verification, or invalidation processing is directly triggered. If the core evidence is only pending verification or expired, the derived memory is downgraded and recalled, added to the recalculation queue, or restricted to use in verification recalls, depending on business risk.

[0114] The system sets two or more thresholds, and satisfies the following:

[0115] in, The failure threshold This is the expiration threshold. If If the decrease stems from global evidence invalidation, logical deletion, arbitration rejection, or the unavailability of the evidence recalculation policy, then the derived memory is marked as invalid and removed from the normal recall; if the decrease only stems from the current permission context being invisible, then it is preferable to generate a context-level recall prohibition or a context-level derived version. If so, the derived memory will be marked as expired, its weight in normal recall will be reduced, and it will be added to the recalculation queue. If However, if there are changes in core evidence, a counterexample validity rate exceeding a threshold, or an excessively high proportion of evidence invisible to the authorized domain, then derived memories will be marked as pending verification, incremental recalculation will be triggered, context-level restrictions will be generated, or they will be directly invalidated when a global risk is established, based on the hard rules of core evidence, the validity rate of counterexamples, or the authorized rules. If SR(D) does not decrease significantly and there are no changes in core evidence, valid counterexample evidence, or authorized risks, then only changes in dependency status and audit events will be recorded, and recalculation will not be performed immediately.

[0116] The above judgment adopts the order of "prioritizing hard rules and supplementing with survival rate thresholds". The failure of core evidence, the exceeding of valid counterexamples, or the violation of authority triggers verification, recalculation, or invalidation before the SR(D) threshold. When these hard risks do not exist, the decision to downgrade, expire, or retain evidence is primarily based on the range in which the SR(D) falls. This avoids a large number of supporting evidences masking the substantial risks caused by the failure of a few core pieces of evidence.

[0117] The derived memory incremental recalculation module regenerates derived memories based on the remaining valid evidence when derived memories are marked as expired, invalid, or require recalculation. The "incremental" aspect here is reflected at least in the following ways: only the dependency subgraph affected by the state change event is traversed, only the affected derived memory nodes are recalculated, only the remaining evidence that is still valid and visible to permissions is used, and the existing version of the unaffected derived memories is retained.

[0118] The recalculation process includes: obtaining the upstream dependency set of the derived memory from the dependency graph; filtering out upstream memories that have been logically deleted, frozen, isolated, invalidated, have inaccessible permissions, or whose recalculation evidence usage strategy is unavailable; removing low-confidence reference evidence such as those awaiting verification from the valid evidence set and recording them separately; sorting the remaining evidence by dependency weight, evidence type, time range, and confidence level; selecting the corresponding recalculation template according to the derived memory type, such as summary template, profile template, preference template, strategy template, or tool experience template; the recalculation template defines the input evidence fields, generation prompts, and output structure of the corresponding type of derived memory, with the input being the sorted and filtered remaining valid evidence set, and the output being the content fields and confidence level of the new version of the derived memory; generating a new version of the derived memory; establishing new evidence anchors, version relationships, and dependency edges for the new version; marking the version relationship status of the old version as obsolete, recalculation source, or replaced, and setting its ordinary recall permission to false if necessary, retaining it for auditing; and after the new version is handed over to the recall status control module to calculate the ordinary recall permission, synchronizing it to the ordinary recall index according to its status.

[0119] If the remaining valid evidence is insufficient to support the original derived conclusion, the system will not generate a strong conclusion, but instead will generate a conservative version, an empty version, or a supplementary evidence task. If only low-confidence reference evidence exists, the system may generate a version to be verified, but it must not be used as a high-confidence general recall result. This avoids the system from continuing to output overly certain user profiles, preferences, or strategies when evidence is insufficient.

[0120] Once the new derived memory version is written, the system generates a version replacement event, carrying the old version identifier, the new version identifier, the dependent snapshot version, and the reason for recalculation. This version replacement event is used both to synchronize the ordinary recall index and to trigger downstream derived memories to re-evaluate their dependency sets, thereby ensuring that old conclusions in multi-level derived memories do not continue to propagate due to only completing a partial recalculation.

[0121] The system records the affected subgraph identifier, triggering state change events, the set of affected nodes, the set of unaffected nodes, the set of recalculation input evidence, and the dependency snapshot version in the recalculation task. For derived memories not located in the affected subgraph, or whose positive supporting evidence and core evidence groups have not changed in validity, the system does not create a recalculation task, but only records the dependency state check results. Therefore, incremental recalculation is not a simple regeneration of the summary, but a local maintenance of the affected subgraph based on state change events and dependency snapshot versions.

[0122] The verification, arbitration, and auditing module provides conflict interpretation, evidence viewing, arbitration result writing back, and audit link restoration. This module recalls the memory nodes, evidence anchors, generated agents, conflict scores, state change records, and index synchronization records of both conflicting parties according to the conflict group identifier. Arbitration results can include activating a memory, freezing a memory, merging two memories, generating a summary to replace the memory, requesting supplementary verification, or deleting invalid memories.

[0123] After the arbitration result is written back, the system triggers recall status synchronization and downstream dependency propagation again to ensure that the results of manual or automatic arbitration can affect the recall of ordinary tasks and the state of derived memories. If the arbitration conclusion is to generate a summary to replace the memory, the system generates a new version of the derived memory based on the evidence confirmed by the arbitration, establishes a version replacement relationship, and generates a version replacement event. This event is synchronized to each retrieval index after the recall status control module calculates the ordinary recall permission, and at the same time, it continues to trigger the re-evaluation of more downstream derived memories along the memory dependency graph.

[0124] Reference Figure 2 The method provided in this embodiment of the invention includes a memory write conflict isolation process and an upstream state change cascading process.

[0125] (a) Memory writing conflict isolation process S1, the system receives the memory to be written from the agent, tool, workflow or manual confirmation entry.

[0126] S2, the system generates evidence anchor memory nodes for the memory to be written, and records the evidence anchor point, writing agent, generation time, version, memory type, permission domain, life cycle state and initial recall control state.

[0127] S3: The system filters candidate existing memories from the target memory bank based on entity objects, attribute predicates, time range, permission domain, memory type, semantic similarity, and graph proximity.

[0128] S4, the system performs factual conflict, time conflict, preference conflict, policy conflict and permission conflict detection between the memory to be written and the candidate existing memory, and obtains the conflict type and conflict score.

[0129] S5, the system determines whether the conflict score meets the preset conflict conditions or whether a hard conflict rule has been triggered.

[0130] S6. If there is no conflict, the system will write the memory to be written to the valid state and add it to the normal task recall index at the same time; if the memory is a derived memory, its upstream dependent edge and dependent snapshot version will be written at the same time.

[0131] S7. If a conflict occurs, the system creates or reuses a conflict group, associates the conflict memory with the same conflict group, records the conflict edges between each pair within the group, and retains the evidence, version, generating agent, permission domain, and conflict audit event of both parties in the conflict.

[0132] S8: The system calculates a normal recall permit based on the conflict type, evidence credibility, verification status, and permission risk. Unarbitrated conflicts suppress normal recalls by default; existing confirmed versions can continue normal recalls when permitted by the policy; permissions exceeding limits or security risks are frozen.

[0133] S9, the system generates an index status synchronization event with node-level status version and synchronization event identifier, and synchronizes the recall control status and ordinary recall permission to the vector index, keyword index and graph index.

[0134] S10, the system determines whether index synchronization is complete. If synchronization fails, the system adds the corresponding memory to the normal recall blacklist or writes it to the post-filter table, and performs secondary filtering of the blacklist, post-filter table and master database status before the normal recall service returns candidate results; if synchronization is successful, the system records the index synchronization version and audit event.

[0135] In S11, the system updates the memory dependency graph. If the memory to be written is a primary memory, the system records its evidence anchor, version, and node information that can be referenced by subsequent derived memories. If the memory to be written is a derived memory such as a summary, profile, preference, strategy, or team knowledge, the system establishes dependency edges from the upstream memory to the derived memory according to its upstream evidence set, and records the dependency weight, evidence role, and supporting direction. After the version is successfully recorded in S10 through index synchronization, or after secondary filtering by the blacklist and post-filter table, the system returns to S11 to complete the memory dependency graph update.

[0136] (ii) Upstream status change cascading process E1: When any upstream memory undergoes logical deletion, isolation, freezing, demotion, setting the recalculation evidence usage policy to unavailable, digest version replacement, new derived version replacement, becoming untrusted, permission revocation, or arbitration result write-back, the system generates a state versioning change event. If only recall deletion occurs but internal recalculation is still allowed, only the recall index can be synchronized without triggering a decrease in downstream survivability. If no state versioning change event is generated, the current round of processing ends and audit records are retained.

[0137] E2: The system performs deduplication based on the state change event identifier, state version, and dependent snapshot version to avoid duplicate processing of the same derived memory due to concurrent writes or retries.

[0138] E3: The system searches for downstream derived memory nodes that are directly or indirectly affected along the memory dependency graph, and is constrained by the maximum propagation depth, the maximum number of nodes, the memory type, and the tenant permission boundary.

[0139] E4: The system processes affected derived memories in topological order, first processing directly dependent nodes, and then processing more downstream nodes; if an upstream derived memory has failed, its downstream computation will treat it as evidence of failure.

[0140] E5, the system calculates the effective and credible evidence support rate for each affected derived memory; if there is counterexample evidence, core evidence, or evidence that is not visible to the user, the counterexample effectiveness rate is calculated or the corresponding hard rule is triggered.

[0141] E6: The system determines the processing strategy based on the range of valid and credible evidence support rate, core evidence rules, counterexample effectiveness rate, and permission rules.

[0142] E7. If the effective and credible evidence support rate is lower than the invalidation threshold, or if the core evidence is invalid and cannot be supported by the remaining evidence, the system will mark the derived memory as invalid and remove it from the ordinary recall index. At the same time, the system will notify the verification, arbitration and auditing module to audit the invalidation record.

[0143] E8. If the effective and credible evidence support rate is between the invalidation threshold and the expiration threshold, or if the core evidence enters the pending verification state, the system will mark the derived memory as expired, pending verification, or downgraded, and add it to the recalculation queue. At the same time, the system will notify the verification arbitration and auditing module to record the status change.

[0144] E9. If the recalculation condition is met, the system will regenerate a new version of the derived memory based on the remaining valid evidence; if the remaining evidence is insufficient, a conservative version, an empty version, or a supplementary evidence task will be generated instead of continuing to output a strong conclusion.

[0145] E10: The system writes a new derived memory version, establishes a version replacement relationship and a new dependency edge. After the recall status control module calculates the ordinary recall permission, a version replacement event is generated and the recall index is synchronized. At the same time, the calculation results of the effective and credible evidence support rate, the hierarchical processing strategy, the index synchronization results, and the recalculation audit event are recorded. If the downstream derived memory depends on the old version, the version replacement event will continue to trigger the reassessment or incremental recalculation of the effective and credible evidence support rate of the downstream nodes.

[0146] In E6, if the rate of support for valid and credible evidence has not decreased significantly and there are no changes in core evidence, valid counterexamples, or authority risks, only changes in dependency status and audit events are recorded, and the audit is not immediately recalculated.

[0147] Application Scenario 1: Isolation of User Preference Conflicts Agent A writes memory M1 based on historical conversations, stating "The user tends to choose a certain type of beverage." M1 is bound to evidence anchor E1, its state is active, and it is entered into the general vector index and keyword index. Subsequently, Agent B writes memory M2 based on new conversation evidence, stating "The user should not choose this type of beverage for health reasons." After normalizing M2, the system retrieves M1 based on the same user, the same preference attribute, and overlapping time range, and determines that there is a preference conflict between the two. The conflict score CS is 0.82, which is greater than the preset conflict threshold of 0.6.

[0148] The system neither deletes M1 nor directly overwrites it with M2. Instead, it creates a conflict group CG1 and adds both M1 and M2 to this group. Since M2 involves a new restrictive preference and the conflict has not yet been arbitrated, the system marks M1 as pending verification or isolation, marks M2 as pending verification, and sets the ordinary recall permission for both to false. The system synchronously updates the vector index and keyword index, preventing either from entering the ordinary recommendation or ordinary task planning context. The verification agent or the human arbitration module can view the two memories and their evidence anchors through CG1. If the arbitration confirms that M2 is the latest credible restrictive preference, the system sets the verification status of M2 to confirmed and restores its ordinary recall eligibility, while continuing to isolate or discard M1.

[0149] Application Scenario 2: Derivative Memory Recalculation of User Profiles User profile memory D1 is generated from five upstream memories M1 to M5, where M1 and M2 are core preference evidence, M3 and M4 are auxiliary behavioral evidence, and M5 is historical summary evidence. The weights of each dependency edge are 0.3 for M1, 0.3 for M2, 0.15 for M3, 0.15 for M4, and 0.1 for M5.

[0150] When M1 is isolated by the conflict group and M2 is determined to be invalid, the system locates D1 along the dependency graph. Since M1 and M2 belong to the core preference evidence group, the system first judges the rules of the core evidence group: if the group is configured as "all must be valid", then even if there is still a lot of supporting evidence, the system will mark D1 as invalid or pending verification and prohibit its ordinary recall; if the group is configured as "alternative evidence group", the system will continue to calculate the support rate of valid and credible evidence as the basis for classification.

[0151] In the example of the alternative evidence group, the validity coefficient Vi corresponding to the isolated and invalid evidence is 0, the Vi of M3 and M4 is 1, the Vi of expired M5 is 0.6, the confidence normalization coefficient Ci of each upstream memory is 1, and the sum of dependency weights in this example is 1. The valid and credible evidence support rate of D1, SR(D1) = 0.3×0×1 + 0.3×0×1 + 0.15×1×1 + 0.15×1×1 + 0.1×0.6×1 = 0.36. If the invalidation threshold Tinvalid is 0.3 and the staleness threshold Tstale is 0.7, then Tinvalid ≤ SR(D1) < Tstale, the system will mark D1 as stale or to-be-verified, reduce or prohibit its normal recall, and add it to the recalculation queue. The recalculation module generates a new conservative user profile version D2 only based on the still valid and permission-visible M3, M4 and M5, and the old version D1 is marked as replaced by D2 with the audit relationship retained.

[0152] Application Scenario 3: Cascading Failure of Policy Memory The policy memory S1 is generated from the tool invocation experience memory T1 and the task result summary R1, and is used to guide subsequent agents to preferentially select a certain tool in similar tasks. Later, the system finds that the tool invocation corresponding to T1 has a permission overstep, and the tool result is marked as frozen. The upstream state change monitoring module triggers dependency propagation to locate the policy memory S1. Since T1 is the core evidence of S1, even if the calculated SR(S1) is not lower than the invalidation threshold, the system marks S1 as invalid or to-be-verified according to the core evidence invalidation rule, and removes it from the normal policy recall index. If subsequent manual audit confirms that the permission overstep only affects part of the context, the system recalculates a new version of the policy memory based on the remaining valid evidence and new permission constraints, instead of restoring the original policy memory.

[0153] Application Scenario 4: Compensation for Concurrent Writing and Index Synchronization Failure Agent A and Agent B almost simultaneously write M6 and M7 for the same user preference, both of which conflict with the existing memory M0. The system successively creates two temporary conflict groups CG2 and CG3. The conflict group merging module identifies that CG2 and CG3 actually belong to the same conflict domain according to the same user, the same attribute predicate, overlapping valid time range and the same permission domain, merges them into CG4, and recalculates the normal recall permissions of M0, M6 and M7.

[0154] If vector index synchronization succeeds after CG4 is written back to the main database but keyword index synchronization fails, the system will add M0, M6, and M7 to the general recall blacklist or write them to the post-filter table. Even if the general recall service hits any of these memories from the keyword index, it will filter again based on the blacklist, post-filter table, and main database node-level state version before returning the candidate context. Once the keyword index successfully retryes idempotently according to the synchronization event identifier and node-level state version, the system removes the corresponding entries from the blacklist and post-filter table, records the index synchronization version and index synchronization audit event, and updates the memory dependency graph.

[0155] Application Scenario 5: Outdated Index Versions and Recalculation of Affected Subgraphs User profile D10 depends on ten upstream memories, only three of which have dependency edges with isolated conflict group members. The master database node-level state version of upstream memory M20 has been updated from 12 to 13, and the normal recall permission is false, but the index synchronization version in the vector index is still 12. After the normal recall service hits M20 from the vector index, it first compares the index-side version with the master database version. Finding that the index-side version is lagging, it queries the master database state and discards the candidate before returning it, while simultaneously writing M20 into the post-filter table until the vector index completes the state projection update to version 13.

[0156] Under the same state version mechanism, the state change event continues to search for downstream derived memories along the memory dependency graph. The system locates the affected subgraph, including D10, based on the dependency edges and records the affected subgraph identifier, trigger event identifier, and dependency snapshot version. For other profile memories that do not depend on M20 or whose core evidence group has not changed, the system does not create a recalculation task; for D10, the system calculates SR(D10) and determines whether to enter the recalculation queue. If the recalculation conditions are met, the system only uses the remaining seven valid and authorized upstream memories to generate a new version D11 and marks D10 as a historical version. Thus, the system avoids erroneous recall during index synchronization delay and limits the recalculation scope to the affected subgraph.

[0157] To avoid contamination of the general recall process due to changes in the master database state without corresponding index updates, the system employs an index synchronization confirmation mechanism. After a memory state change, the system first records the state change version in the master database, and then sends synchronization events to the vector index, keyword index, and graph index respectively. If any index synchronization fails, the system adds the memory to the runtime recall blacklist or writes it to the post-filter table. The general recall service then filters again based on the blacklist, post-filter table, and master database state before returning candidate results.

[0158] Derived memory recalculation employs a priority queue. Derived memories with lower evidence survival rates, higher recall frequencies, higher permission risks, or greater user impact receive higher recalculation priority. Low-frequency or low-risk derived memories are recalculated using offline batch processing. Recalculation modes include synchronous recalculation, asynchronous recalculation, batch recalculation, or delayed recalculation.

[0159] If two memories are semantically conflicting but originate from different tenants, project spaces, or permission domains, the system may not treat them as the same ordinary conflict, but instead establish a permission domain isolation relationship. During a normal recall, the system only selects visible memories within the current permission domain; only during an audit recall is it allowed for authorized subjects to view the cause of the conflict across permission domains.

[0160] In scenarios where multiple agents write to memory simultaneously, different agents may write multiple mutually exclusive memories for the same entity, the same attribute, and overlapping time ranges within a short period. The system generates a conflict merge key for candidate conflict retrieval results. The merge key includes at least the tenant, subject object, attribute predicate, effective time range, permission domain, and memory type. If multiple write transactions create different conflict groups, but the merge key and conflict participating nodes overlap, the system merges the multiple conflict groups into the same conflict group and recalculates the ordinary recall permission and index synchronization event based on the latest node-level state version.

[0161] For derived memories such as summaries, profiles, preferences, and strategies, the system categorizes dependent evidence into core evidence, supporting evidence, counterexample evidence, and time-limited evidence. When core evidence fails, recalculation or pending verification is prioritized; when supporting evidence fails, it primarily affects the effective and credible evidence support rate; when counterexample evidence is valid, a counterexample effectiveness rate assessment is triggered; and when time-limited evidence fails, the effective time range of the derived memory is corrected first. In this way, the calculation of the effective and credible evidence support rate is not simply a statistical count of available evidence, but rather a determination of whether the derived memory can still enter the general recall process, considering the evidence's role, status, and permissions.

[0162] The main parameters involved in the system include: conflict determination threshold (example values ​​range from 0.6 to 0.9, configurable according to memory type); candidate conflict retrieval threshold (used to filter existing memories that may conflict); derived memory invalidation threshold (Tinvalid, e.g., 0.3, below which normal recall is prohibited); derived memory expiration threshold (Tstale, e.g., 0.7, below which weighting or recalculation occurs); counterexample validity threshold (when valid counterexample evidence exceeds this threshold, it triggers pending verification, weighting, or recalculation); upstream state validity coefficient Vi, configured according to states such as active, expired, pending verification, and isolated; and upstream confidence normalization coefficient Ci, taking a value of... Values ​​range from 0 to 1; core evidence hard rules, when core evidence fails, it can directly trigger recalculation or failure by bypassing the effective and credible evidence support rate threshold; core evidence group rules, indicating whether the core evidence has a relationship of all being necessary, any being satisfied, or being substitutable; upstream evidence dependency weight Wi, which can be determined by rules, models, or manual annotation; evidence support direction, distinguishing between positive support, negative constraints, counterexamples, and time-limited evidence; positive support weight sum, when it is 0, the effective and credible evidence support rate division formula is not applied, and the process proceeds to no effective positive evidence; counterexample effectiveness rate CR(D), used to determine whether a valid counterexample or negative constraint is sufficient to trigger the pending... Verification, demotion, or recalculation; permission assessment context, indicating the current tenant, user, agent team, or derived entity, used to determine evidence visibility; recalculation evidence usage strategy, distinguishing between valid evidence, low-confidence reference evidence, and unusable evidence; general recall permission, controlling whether ordinary tasks can recall the memory; audit recall permission, controlling accessibility in verification or audit scenarios; maximum cascading propagation depth, preventing excessively deep dependency graphs from overloading online processing; maximum number of processing nodes in a single cascading event, preventing a single state change from affecting too many derived memories and blocking online tasks; recalculation modes, including synchronous recalculation, asynchronous recalculation, and batch recalculation. Calculate or delay recalculation; node-level state version, incremented when the memory node state, recall permission, verification status, version relationship, or recalculation evidence usage strategy changes, used for comparison with the index-side version; synchronization event identifier, used for index synchronization, retry, and deduplication; index synchronization version, indicating the memory node state version that a certain index entry or index view has been synchronized to; version replacement event, used to trigger index synchronization and downstream dependency re-evaluation after the derived memory recalculation generates a new version; ordinary recall blacklist retention time, temporarily blocking candidate memories when index synchronization fails; index synchronization retry limit, after exceeding the limit, it enters the manual or offline repair queue.

[0163] The above parameters can be configured by tenant, memory type, business risk level, agent team, or permission domain. Parameter values ​​are not a limitation of the claims, as long as they enable conflict isolation, recall status synchronization, and derived memory processing based on dependency evidence survival rate.

[0164] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for recall state synchronization and derived memory increment recalculation with multi-agent memory conflict isolation, applied to a multi-agent shared long-term memory system including a main memory bank, vector index, keyword index, graph index, and memory dependency graph, characterized in that, Includes the following steps: (1) In response to the multi-agent memory write request, generate evidence anchor memory nodes in the main memory bank and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. (2) Filter candidate existing memories from the main memory, and perform typed conflict detection on the memory to be written and the candidate existing memories based on structured field rules, permission rules, time rules or semantic models; If the preset conflict conditions are not met, the memory to be written is set to a valid state and added to each retrieval index, while the memory dependency graph is updated; if the preset conflict conditions are met, a conflict group is created or reused, the memory to be written and the existing memory that has conflicted are associated with the same conflict group identifier, the evidence anchor and version identifier of each party in the conflict are preserved, and the ordinary recall permission of the members in the conflict group is calculated based on the verification status and permission risk of each party in the conflict. (3) Generate an index state synchronization event carrying the node-level state version, and project the recall control state and ordinary recall permission to the vector index, keyword index and graph index used by ordinary task recall, respectively, so as to suppress the participation of unpermitted conflicting memories in ordinary task recall through index state projection. (4) Before the ordinary recall service returns the candidate results, compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory. When the index synchronization version lags behind the node-level status version or the index synchronization fails, perform at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering to remove unauthorized candidate memories. (5) In response to any state versioning change event in the upstream memory node, such as lifecycle failure, isolation or freezing, setting the recalculation evidence usage strategy to unavailable, permission not visible, confidence decrease, or arbitration result write-back, after deduplication according to the state change event identifier and node-level state version, locate the affected downstream derived memory subgraph along the memory dependency graph, and process the affected nodes in the topological order, first process the directly dependent nodes and then process the more downstream dependent nodes. The failed derived memory is regarded as failed evidence in the calculation of its more downstream nodes. (6) For the affected downstream derived memories, calculate the effective and credible evidence support rate based on the main memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence level, and combine the counterexample effectiveness rate, core evidence group rules and permission rules to determine the graded status of downstream derived memories as invalid, expired, downgraded, pending verification or recalculation. (7) In response to the downstream derived memory meeting the recalculation conditions, incremental recalculation is performed only based on the remaining valid evidence that the state is valid and the permissions are visible in its upstream dependencies, generating a new version of the derived memory, marking the old version of the derived memory as a historical version and retaining the audit association, and generating a version replacement event to continue to trigger the re-evaluation of the downstream derived memory and the state synchronization of each retrieval index.

2. The method according to claim 1, characterized in that, The typed conflict detection in step (2) includes: Detect at least one of the following: factual conflict, temporal conflict, preference conflict, policy conflict, and permission conflict; According to the conflict score formula Calculate the conflict score, where , , , , , These are, respectively, the sub-scores for factual conflict, temporal conflict, preference conflict, strategy conflict, permission conflict, and semantic conflict. To correspond to the weight, each sub-score takes a value between 0 and 1; When the conflict score is greater than or equal to the preset conflict threshold, or when any of the hard conflict rules among enumeration value mutual exclusion, time interval conflict, permission out-of-bounds, security policy mutual exclusion, and core evidence mutual exclusion are triggered, the conflict condition is determined to be met.

3. The method according to claim 1, characterized in that, The calculation of ordinary recall permission in step (2) includes: ordinary recall permission for conflict memories that have not been fully arbitrated within the conflict group is set to prohibited by default; members within the conflict group who have been confirmed by manual verification, high-credibility tool evidence or compliance permission proof, shall have their ordinary recall permission restored if they meet the permission rules and do not return at the same time as other valid conflict edge members in the same ordinary recall result set; conflict memories involving permission overstepping or mutual exclusion of security policies are frozen.

4. The method according to claim 1, characterized in that, In step (3): each vector entry of the vector index is written with a memory identifier, node-level status version, index synchronization version, recall control status, ordinary recall permission, conflict group identifier and version identifier. During ordinary vector retrieval, entries with ordinary recall permission as prohibited are excluded in the retrieval filtering conditions, and a weighting coefficient is applied to expired status entries. Keyword indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, tenant identifiers, and permission domains. During normal keyword recall, candidates are filtered according to normal recall permissions, tenant identifiers, and permission domains. Nodes or edges of graph indexes are written with memory identifiers, node-level status versions, index synchronization versions, normal recall permissions, recall control status, conflict group identifiers, and version identifiers. During normal graph traversal, nodes or edges with prohibited normal recall permissions are skipped. Graph traversal verification or auditing accesses complete conflict subgraphs according to conflict group identifiers.

5. The method according to claim 1, characterized in that, The index status synchronization event generated in step (3) carries a synchronization event identifier, memory identifier, node-level status version, target index type, recall control status, normal recall permission, conflict group identifier, version identifier, and retry count. Each retrieval index side deduplicates according to the synchronization event identifier, and only updates the index status projection when the node-level status version carried by the index status synchronization event is not lower than the index synchronization version already recorded by the index side, and sets the index synchronization version to the corresponding node-level status version after the update is completed.

6. The method according to claim 1, characterized in that, In step (4), when the index update fails, the corresponding memory is added to the ordinary recall blacklist. Before the ordinary recall service returns the candidate results, it performs secondary filtering according to the ordinary recall blacklist and the main memory status. After the index status is successfully synchronized, the corresponding memory is removed from the ordinary recall blacklist.

7. The method according to claim 1, characterized in that, The memory dependency graph is logically divided into two isolated views: a normal recall graph and a dependency propagation graph. The normal recall graph is filtered by normal recall permissions, permission domains, and index synchronization versions and is used for normal task recall. The dependency propagation graph retains memory nodes and their dependency edges that are isolated, frozen, in historical versions, or in the state of audit tombstone records and is used for state propagation, derivation recalculation, and audit tracing.

8. The method according to claim 1, characterized in that, In step (6): Derived memory Valid and credible evidence support rate Calculate using the following formula: in, Let be the sequence number of the upstream positive support dependency edge of the derived memory. For the first The dependency weight of the upstream positive support dependency edge and , For the first The validity coefficient of the upstream memory in the current permission evaluation context, with a value ranging from 0 to 1. For the first The confidence normalization coefficient of the upstream memory is between 0 and 1, and the denominator is the sum of all positive support dependency weights of the derived memory. The upstream memory in a valid state is calculated jointly by the memory lifecycle state, recall control state, recalculation evidence usage strategy, and access visibility. A value of 1 indicates an upstream memory that is in an isolated, frozen, invalid, or deleted state. A value of 0 indicates that the upstream memory is in an expired state. Take a weighted value between 0 and 1; If a derived memory lacks positive supporting evidence or the sum of the positive supporting dependence weights is zero, then the derived memory is marked as invalid, pending verification, or a conservative version requiring supplementary evidence is generated. For counterexamples or negative constraint evidence in upstream dependencies, the numerator of positive support is not included, and the counterexample validity rate is calculated separately. ,in This refers to the dependency edge number of the counterexample evidence or negative constraint evidence. For the corresponding dependency weights, For the corresponding effective coefficients, The corresponding confidence level normalization coefficient is used; when the counterexample validity rate exceeds the preset counterexample threshold, the downstream derived memory is marked as pending verification, incremental recalculation is triggered, or the weight of ordinary recall is reduced.

9. The method according to claim 1, characterized in that, The hierarchical state determination setting in step (6) satisfies Failure threshold and expiration threshold Furthermore, the judgment order follows a hard rule, taking precedence over the support rate threshold: Core evidence is managed as core evidence groups. Each core evidence group is configured with rules that all evidence must be valid and any valid evidence can support or replace the evidence group. When a core evidence group does not meet its validity rules, or when core evidence enters an isolated, frozen, invalid, or deleted state, it directly triggers recalculation, pending verification, or invalidation processing if the valid and credible evidence support rate threshold is exceeded. Assuming the risk of core evidence is excluded, when Furthermore, when the decline originates from global evidence invalidation, logical deletion, arbitration rejection, or when the evidence recalculation usage strategy is set to unavailable, downstream derived memories will be marked as invalid and removed from the ordinary recall index. when When downstream derived memories are marked as expired, the weight of ordinary recall is reduced, and the recalculation priority is determined according to the survival rate of dependent evidence, recall frequency, permission risk or user impact before being added to the recalculation queue. when However, when there are changes in core evidence, the effectiveness of counterexamples exceeds the preset counterexample threshold, or the proportion of evidence not visible in the permission domain exceeds the preset ratio, the downstream derived memory will be marked as pending verification, incremental recalculation will be triggered, or context-level restrictions will be generated. when If there is no decrease and no changes in core evidence, valid counterexamples, or permission risks, only the change in dependency state is recorded, and no recalculation is performed.

10. A multi-agent memory conflict isolation recall state synchronization and derived memory incremental recalculation system, characterized in that, Applied to a multi-agent shared long-term memory system including a main memory bank, vector index, keyword index, graph index, and memory dependency graph, for implementing the method described in any one of weights 1 to 9 above, the system includes: The memory normalization and evidence anchoring module is used to respond to multi-agent memory writing requests, generate evidence anchoring memory nodes in the main memory, and record the evidence anchor point, the writing agent identifier, the generation time, the version identifier, the memory type, the permission domain, the life cycle state, the recall control state, the recalculation evidence usage strategy, and the node-level state version. The conflict retrieval and conflict group isolation module is used to filter candidate existing memories from the main memory and perform typed conflict detection. When the conflict conditions are met, a conflict group is created or reused, conflict memories are associated with the same conflict group identifier, and ordinary recall permissions are calculated based on the verification status and permission risk of each party in the conflict. The recall index status synchronization module is used to generate index status synchronization events carrying node-level status versions, synchronize and project the recall control status and ordinary recall permission to the vector index, keyword index and graph index respectively, and compare the index synchronization version of the candidate entries on the retrieval index side with the node-level status version in the main memory before the ordinary recall service returns the candidate results. When the index synchronization version is lagging behind or synchronization fails, at least one of blacklist filtering, post-filter table filtering and main memory status secondary filtering is performed. The memory dependency graph storage module is used to store the derived dependency relationships between memory nodes, and is logically divided into mutually isolated ordinary recall graph views and dependency propagation graph views. The upstream state change monitoring and downstream derived memory location module is used to respond to the state versioning change event of the upstream memory node, locate the affected downstream derived memory subgraph along the memory dependency graph after deduplication according to the state change event identifier and node-level state version, and process the affected nodes in the topological order. The dependency evidence survival rate calculation module is used to calculate the effective and credible evidence support rate of affected downstream derived memories based on the master memory state field, recalculation evidence usage strategy, permission visibility, dependency edge weight and confidence, and to perform hierarchical status determination in combination with counterexample effectiveness rate, core evidence group rules and permission rules. The derived memory incremental recalculation module is used to perform incremental recalculation only based on the remaining valid evidence that is valid and visible in its upstream dependencies when the recalculation conditions are met. This generates a new version of the derived memory, marks the old version of the derived memory as a historical version and retains the audit association, and generates a version replacement event to continue to trigger the re-evaluation of downstream derived memories and the state synchronization of each retrieval index. The verification, arbitration, and auditing module is used to recall conflict memories and their evidence anchors by conflict group identifier for verification or arbitration, and write the arbitration results back to the main memory. Specifically, the conflict retrieval and conflict group isolation module sends an index status synchronization event to the recall index status synchronization module; the upstream status change monitoring and downstream derived memory location module sends a status change event to the dependent evidence survival rate calculation module; the version replacement event generated by the derived memory incremental recalculation module is sent back to the recall index status synchronization module; and the arbitration result written back by the verification arbitration and audit module triggers the upstream status change monitoring and downstream derived memory location module to generate a status versioning event.

Images