Multi-agent personal context encapsulation and cross-terminal persistence method

Abstract

The application discloses a multi-agent personal context encapsulation and cross-end persistence method in the technical field of intelligent agent interaction, which comprises the following steps: collecting permission identification, current working state and operation preference characteristics in cross-end intelligent interaction of a user; encapsulating into a personal context container and configuring a data domain isolation label; configuring a non-unloading label for agent memory data meeting the reservation condition and reserving locally; generating memory incremental update data based on state changes; uploading to a remote end and performing context state consistency verification; performing isolated retrieval based on the data domain isolation label and access mask, recalling target personalized memory and injecting into the intelligent agent running context. By encapsulating the permission identification, current working state, operation preference characteristics and intelligent agent memory data into the personal context container and combining the data domain isolation label to limit access, the personal context can be called by range in multi-agent cooperation, and the risk of mixed reading of personal memory and unauthorized calling is reduced.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent interaction technology, specifically to a method for encapsulating personal contexts and cross-platform persistence for multiple intelligent agents. Background Technology

[0002] Multi-agent systems are intelligent interactive systems in which multiple agents with different functional roles jointly participate in user task processing. As intelligent interactive applications operate collaboratively across mobile devices, desktops, and remote servers, information such as user permission status, current working status, operation preferences, and historical interaction memories are gradually becoming important contextual data affecting the continuous processing of tasks. Existing multi-agent systems typically store user historical interaction content, preference information, or task status in local caches, remote memory banks, or vector retrieval libraries, respectively, and call relevant memory data based on session content or retrieval results when the agent executes a task.

[0003] However, in current technology, the aforementioned personal context information lacks a unified encapsulation structure and data domain isolation mechanism. When different agents call the user context, they are prone to mixing data such as permission status, working status, and operation preferences. There may also be cases where agents unrelated to the current task obtain personal memory data beyond the scope of their task, affecting the boundary control and data isolation reliability of personal context calls during multi-agent collaboration. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a method for encapsulating personal contexts and persisting them across multiple agents, solving the problems of lack of unified encapsulation of personal contexts, unclear call boundaries, and insufficient reliability of memory data isolation during cross-entity collaboration among multiple agents.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for encapsulating personal contexts and persisting cross-platform data for multiple agents, comprising:

[0006] S1. Collect personal dimension information of users during cross-terminal intelligent interaction, including permission identifiers, current working status and operation preference characteristics;

[0007] S2. Encapsulate the personal dimension information into a personal context container, and configure a data domain isolation label for the personal context container;

[0008] S3. In the local intelligent interaction subprocess, configure the agent memory data that meets the retention conditions in the personal context container with a non-unload tag, so that the agent memory data with the non-unload tag is retained in the local callable storage area when the local cache is recycled.

[0009] S4. Monitor the state changes of the personal context container, and generate memory increment update data based on the changed fields and the agent memory data configured not to unload the tag;

[0010] S5. Upload the memory incremental update data to the remote node through the cross-end synchronization link, and perform context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent to complete the local and remote layered persistence of memory data.

[0011] S6. Responding to the task instructions of the remote multi-agent cluster, perform isolated retrieval in the remote unified vector retrieval architecture based on the data domain isolation label and access mask, recall the target personalized memory and inject the corresponding agent's running context.

[0012] Preferably, the step of structurally encapsulating the personal dimension information into a personal context container and configuring data domain isolation labels specifically includes:

[0013] Construct a hierarchical container data structure, dividing the personal context container into a static permission area and a dynamic business area;

[0014] The permission identifier is written into the static permission area, and the current working status and operation preference features are encapsulated into the dynamic business area according to the time sequence to support the dynamic update mechanism of the dynamic business area;

[0015] Based on the functional categories of multiple agents, data domain isolation labels are configured for the static permission area and the dynamic business area respectively, so as to define the fine-grained read and write permissions of different agents to the personal context container.

[0016] Preferably, the dynamic update mechanism specifically includes:

[0017] The intelligent interaction subprocess listens for real-time interaction events and updates the current working status in the dynamic business area using a sliding window mechanism.

[0018] When a change in business scenario is detected, a silent flag is configured for the expired state data in the dynamic business area;

[0019] Based on the new interaction intent after the switch, a new working status node is generated and written to the dynamic business area.

[0020] Preferably, configuring the agent memory data within the personal context container that meets the retention conditions to not unload tags and executing a non-unloading priority strategy specifically includes:

[0021] A memory state machine is configured in the intelligent interaction subprocess, and the memory state machine includes at least an active state, a dormant state, and a frozen state.

[0022] When it is detected that the intelligent interaction subprocess has retreated to the background or a business scenario has changed, the intelligent agent memory data configured with non-unloaded tags in the personal context container will be switched to the frozen state.

[0023] Upon receiving a local cache reclamation event, the agent's memory data that is in a frozen state is removed from the normal elimination queue, and the corresponding survival flag is maintained.

[0024] Preferably, the step of extracting and generating memory incremental update data based on the changed fields in the personal context container and the agent's memory data configured to not unload tags specifically includes:

[0025] Obtain the most recently synchronized agent memory snapshot from local storage and use the agent memory snapshot as the comparison benchmark version;

[0026] The memory data of the agent in the active or frozen state is compared with the comparison benchmark version according to the field identifier, and the differential field set in which the state has changed is extracted;

[0027] The differentiated field set is serialized into a lightweight difference log, and the lightweight difference log is used as the memory incremental update data for uploading.

[0028] Preferably, the completion of local and remote hierarchical persistence of memory data specifically includes:

[0029] The memory data of high-frequency intelligent agents that belong to the currently active task and are configured not to be uninstalled reside in the memory space of the local intelligent interaction subprocess;

[0030] Unload and archive the historical agent memory data that is not configured to be unloaded and is accessed infrequently to the remote node for long-term storage.

[0031] A lightweight retrieval index is generated and retained in the local intelligent interaction subprocess to store the historical agent memory data.

[0032] Preferably, the step of performing context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent specifically includes:

[0033] Parse the memory incremental update data and extract the bound local version identifier;

[0034] Perform a sequence comparison between the local version identifier and the global version identifier recorded by the remote node;

[0035] When the comparison results indicate a version conflict, the conflicting data is merged by executing priority-based conflict resolution and merging rules, and a consistent state snapshot is generated.

[0036] Preferably, the step of merging conflicting data by executing priority-based conflict resolution and merging rules specifically includes:

[0037] The conflict data is parsed using data classification tags, which include security permission tags and temporary business tags.

[0038] When the data classification label is the security permission category label, the global version data recorded by the remote node is used as the merged permission status;

[0039] When the data classification label is the temporary business category label, the version data carrying the latest locally generated timestamp is used as the merged business status;

[0040] When the conflicting data carries a non-unload tag, a copy of the current state in the local intelligent interaction subprocess is retained before the merging is performed.

[0041] Preferably, the execution of the isolated retrieval protocol in the remote unified vector retrieval architecture specifically includes:

[0042] The agent's memory data to be stored is converted into vector feature data, and the data domain isolation label is written into the metadata bound to the vector feature data;

[0043] According to the data domain isolation label, the vector feature data is written into the corresponding index partition or namespace;

[0044] Receive a retrieval request initiated by a remote intelligent agent, and extract the user identity identifier and intelligent agent identity identifier carried in the retrieval request;

[0045] Based on the user identity identifier, agent identity identifier, and data domain isolation label, the target index partition or namespace is determined, and an access mask for metadata matching is dynamically generated.

[0046] Preferably, the personalized memory of the recall target specifically includes:

[0047] Before executing the vector similarity calculation instruction, the access mask is matched with the metadata stored in the remote unified vector retrieval architecture using Boolean logic to filter out the exclusive vector data clusters that match the access mask;

[0048] Within the defined scope of the dedicated vector data cluster, a corresponding target vector is generated according to the retrieval request, and distance calculation is performed between the target vector and the dedicated vector data cluster to recall personalized memories of targets that meet the similarity threshold.

[0049] This invention provides a method for encapsulating personal contexts for multiple agents and persisting them across platforms. It offers the following advantages:

[0050] 1. This invention encapsulates permission identifiers, current working status, operation preference features, and agent memory data into a personal context container, and combines it with data domain isolation tags to restrict access, enabling the personal context to be invoked within a scope in multi-agent collaboration, reducing the risk of mixed reading of personal memory and unauthorized access.

[0051] 2. This invention configures the intelligent agent memory data that meets the retention conditions to not unload the tag, and retains it in the local callable storage area when the local cache is recycled, so that key contexts such as incomplete tasks, valid permission status and high-frequency preferences are not easily lost when switching between cross-terminals or business scenarios.

[0052] 3. This invention performs state consistency verification by memorizing incrementally updated data, local version identifiers and remote global version identifiers, avoiding overall overwrite synchronization of personal context containers, and reducing the risk of version conflicts and inconsistencies between local and remote context states in cross-device synchronization.

[0053] 4. This invention improves the isolation and accuracy of personalized memory retrieval by setting data domain isolation labels, index partitions or namespaces and access masks in a remote unified vector retrieval architecture, enabling remote intelligent agents to recall target personalized memories within a dedicated vector data cluster. Attached Figure Description

[0054] Figure 1 This is a flowchart of a multi-agent personal context encapsulation and cross-platform persistence method according to the present invention;

[0055] Figure 2 This is an architectural diagram of Embodiment 1 of the present invention;

[0056] Figure 3 This is a schematic diagram of Embodiment 2 of the present invention. Detailed Implementation

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

[0058] Please see the appendix Figure 1 This invention provides a method for encapsulating personal contexts and persisting cross-platform data for multiple agents, comprising:

[0059] S1. Collect personal dimension information of users during cross-terminal intelligent interaction. Personal dimension information includes permission identifiers, current working status and operation preference characteristics.

[0060] Specifically, during the process of a user accessing a remote multi-agent cluster through different terminals, the local intelligent interaction subprocess continuously receives user input, interface operations, agent call records, and terminal switching events, and extracts personal dimension information related to the user's personal context from the above interaction data. Among these, the permission identifier can be determined by the user's login identity, authorization token, list of accessible tools, or scope of business data access, used to characterize the user's access boundaries in the current cross-terminal intelligent interaction; the current working status can be determined based on the task identifier, task stage, most recent operation node, and whether there are any incomplete interactions, used to characterize the user's current position in the business process; and operation preference characteristics can be determined based on the user's actions within a preset time range. The system generates records of user choices regarding agents, tools, display formats, or operation paths to characterize stable user habits in intelligent interactions. For example, if a user initiates a document processing task on a mobile device through a local intelligent interaction subprocess and then switches to the desktop to continue calling a remote writing agent, the system can collect the user's login permissions, current work status in the "document modification" stage, and preferred operation habits (displaying modification results in a table format) as personal dimension information. This step provides basic data for the subsequent structured encapsulation of personal context containers, enabling multiple agents to identify user permission boundaries, current task progress, and interaction preferences during cross-device collaboration, avoiding reliance on isolated session content when subsequent agents are invoked.

[0061] S2. Encapsulate personal dimension information into a personal context container and configure a data domain isolation label for the personal context container;

[0062] Furthermore, the personal dimension information is structured and encapsulated into a personal context container, and data domain isolation labels are configured, specifically including:

[0063] Construct a layered container data structure, dividing the personal context container into a static permission area and a dynamic business area;

[0064] Write the permission identifier into the static permission area, and encapsulate the current working status and operation preference characteristics into the dynamic business area according to the time sequence, so as to support the dynamic update mechanism of the dynamic business area;

[0065] Based on the functional categories of multiple agents, data domain isolation labels are configured for the static permission area and the dynamic business area respectively, so as to define the fine-grained read and write permissions of different agents to the personal context container.

[0066] Specifically, after obtaining the user's permission identifier, current working status, and operation preference characteristics, the local intelligent interaction subprocess constructs a hierarchical container data structure to form a personal context container. The hierarchical container data structure can include a static permission area and a dynamic business area. The static permission area is used to store relatively stable permission data within an interaction session or a business cycle, while the dynamic business area is used to store business status data and preference data that change with the user's interaction process. By dividing the personal context container into a static permission area and a dynamic business area, the mixed storage of permission data and dynamic business data can be avoided. This allows multiple agents to determine the permission boundaries before reading the dynamic content related to the current task when calling the personal context, thereby reducing the risk of different types of context data overwriting or being called incorrectly.

[0067] When writing personal dimension information, the user's permission identifier is written to the static permission area. The permission identifier may include one or more of the following: user identity identifier, authorization token, accessible intelligent agent category, scope of accessible tools, and scope of accessible business data. At the same time, the current working status and operation preference characteristics are encapsulated into the dynamic business area according to the time series. This allows the data in the dynamic business area to reflect the order of user status changes during cross-platform intelligent interaction. For example, when a user initiates a task on the mobile terminal and switches to the desktop terminal to continue processing, the dynamic business area can sequentially record working status nodes such as "task creation", "material reading", "remote intelligent agent collaborative processing", and "result confirmation", and record the user's preferences for result display method, invoked tools or response format during the process. After adopting the time series encapsulation method, the remote intelligent agent can not only read the current status when accessing, but also obtain the context change trajectory before the current status, thereby improving the accuracy of status continuation when continuing cross-platform interaction.

[0068] When configuring data domain isolation labels, based on the functional categories of multiple agents, separate data domain isolation labels are configured for the static permission area and the dynamic business area. Specifically, agents can be categorized according to their functions, such as permission verification agents, task execution agents, content generation agents, retrieval agents, or management and scheduling agents. Corresponding data domain isolation labels are then configured for the static permission area and the dynamic business area based on these different functional categories. For the static permission area, the data domain isolation label primarily restricts which agents can read or verify permission identifiers. For the dynamic business area, the data domain isolation label primarily restricts which agents can read the current working status, add new status nodes, or update operation preference features. In this way, the same person's context container can be invoked by multiple agents on demand, but each agent can only perform read or write operations within the scope defined by the data domain isolation label. This achieves fine-grained permission isolation of the personal context, preventing irrelevant agents from accessing personal dimension information beyond their functional scope.

[0069] Furthermore, the dynamic update mechanism specifically includes:

[0070] The intelligent interaction subprocess listens for real-time interaction events and uses a sliding window mechanism to update the current working status in the dynamic business area.

[0071] When a change in business scenario is detected, a silent flag is configured for expired state data in the dynamic business area;

[0072] Based on the new interaction intent after the switch, a new working status node is generated and written to the dynamic business area.

[0073] Specifically, during the update of the current working status in the dynamic business area, the intelligent interaction subprocess continuously monitors real-time interaction events such as user input, intelligent agent invocation, tool execution, result confirmation, and terminal switching, and aggregates these events according to a preset time window to avoid misjudging the user's current working status based solely on a single instantaneous event. Specifically, the current time frame can be... The sliding window event set consists of interactive events that occur within a preset time range:

[0074] ;

[0075] And update the current working state based on the sliding window event set and the working state at the previous moment:

[0076] ;

[0077] in, Indicates the current time The corresponding set of real-time interactive events within the sliding window. Indicates the first A real-time interactive event, Represents real-time interactive events The time of occurrence, Indicates the length of the sliding window. This indicates the current working status of the data being written to the dynamic business area. This indicates the working status at the time of the last update. This represents the work status update function, used to determine the new work status based on the interactive events within the window and the previous work status. For example, after the user executes the three events "upload materials, call the summary agent, and confirm the summary result" consecutively, the event set in the sliding window can indicate that the user has moved from the "material preparation" stage to the "content processing" stage. The intelligent interaction subprocess updates the current work status in the dynamic business area accordingly. In this way, the dynamic business area can be continuously updated with the real-time interaction process, enabling the remote agent to obtain a context state that matches the current task stage when accessing across terminals.

[0078] When detecting whether a business scenario has changed, the intelligent interaction subprocess can determine whether the current business scenario is different from the business scenario to which existing state data in the dynamic business area belongs, based on the current interaction intent, task identifier, type of intelligent agent being invoked, or changes in the business entry point triggered by the user. When a business scenario change is detected, state data that no longer corresponds to the current business scenario and exceeds a preset silent time threshold is not directly deleted, but instead configured with a silent flag, so that the state data no longer actively participates in the current working state update or context injection, but is still retained in the dynamic business area for subsequent recovery or retrieval. The silent flag can be determined according to the following formula:

[0079] ;

[0080] in, Indicates the first Silent markers for each state data, Indicates the current business scenario identifier. Indicates the first The business scenario identifier to which each status data belongs. Indicates the current moment. Indicates the first The most recent update time of each status data. Indicates the silent time threshold, when When, it indicates that the status data is configured with a silent flag, when When the state data is marked as such, it indicates that the state data can still participate in the current interaction state update or context injection. Using silent marking instead of directly deleting the old state can prevent the user from losing the original context when returning to the original business scenario in a short period of time.

[0081] When generating a new working state node, the intelligent interaction subprocess determines the new task identifier, business scenario identifier, current task stage, and state generation time based on the new interaction intent after the switch, and writes it as a new working state node into the dynamic business area. The new working state node can be stored in association with the original state node in a time sequence, so that the dynamic business area forms a traceable state change trajectory. For example, if a user first processes the "contract review" task on the mobile terminal and then switches to the desktop terminal to initiate the "meeting minutes generation" task, the original "contract review" related state data can be configured to be silently marked, while the new working state node corresponding to "meeting minutes generation" is written into the dynamic business area. When the user returns to the "contract review" task later, the system can restore the original task context based on the silent state data. Through this mechanism, the dynamic business area can not only reflect the current working state under the new business scenario in a timely manner, but also retain the historical state basis of the switched scenario, thereby improving the context continuity and state recovery capability of multi-agent cross-terminal collaboration.

[0082] S3. In the local intelligent interaction subprocess, configure the agent memory data that meets the retention conditions in the personal context container to not unload the tag, so that the agent memory data configured to not unload the tag is retained in the local callable storage area when the local cache is reclaimed.

[0083] Furthermore, for agent memory data within the personal context container that meets the retention conditions, the tag is configured not to be unloaded and a non-unloading priority strategy is executed, specifically including:

[0084] Configure a memory state machine in the intelligent interaction subprocess. The memory state machine should include at least an active state, a sleeping state, and a frozen state.

[0085] When it is detected that the intelligent interaction subprocess has retreated to the background or a business scenario has changed, the intelligent agent memory data configured not to unload the tag in the personal context container will be switched to a frozen state.

[0086] Upon receiving a local cache reclamation event, the memory data of the agent in a frozen state is removed from the normal elimination queue, and the corresponding survival flag is maintained.

[0087] Specifically, when configuring the "do not uninstall" tag, the local intelligent interaction subprocess performs retention condition checks on the agent memory data within the personal context container. Agent memory data can include historical interaction summaries related to the current task, user-confirmed preference information, intermediate results of the current task, permission verification results, and context fragments required for cross-platform recovery. For agent memory data associated with currently active tasks, frequently invoked within a pre-designed statistical period, or associated with valid permission states, the "do not uninstall" tag is configured so that this type of data is no longer directly evicted as ordinary cached data when the local cache is reclaimed. Specifically, the following formula can be used to determine whether the k-th agent memory data should be configured with the "do not uninstall" tag:

[0088] ;

[0089] in, This indicates the label that is not unloaded from the memory of the k-th agent. This indicates that the configuration does not uninstall the tag. This indicates that the tag will not be configured or uninstalled. This indicates whether the data memorized by the k-th agent belongs to the currently active task; a value of 1 indicates it belongs, and a value of 0 indicates it doesn't. This indicates the number of times the k-th agent's memory data is accessed within a pre-designed statistical period. Indicates the high-frequency call threshold. This indicates whether the memory data of the kth agent is associated with a valid permission status. If associated, the value is 1; otherwise, the value is 0. This judgment method can distinguish the memory data necessary for the continuous execution of the current task, frequently used operation preferences, and permission-related data that are still valid from ordinary cache data, providing an identification basis for subsequent priority processing of non-uninstalled data.

[0090] When executing the non-unload priority strategy, a memory state machine is configured in the intelligent interaction subprocess to record the state of different agents' memory data in the local callable storage area. The memory state machine includes at least an active state, a dormant state, and a frozen state. The active state represents memory data that is currently being accessed by the intelligent interaction subprocess or a local task. The dormant state represents memory data that is not yet accessed by the current task but can still be accessed. The frozen state represents memory data that has been configured with a non-unload tag and needs to remain alive during cache reclamation. For different memory data, their state can be determined based on the non-unload tag, whether the intelligent interaction subprocess is in the background, and whether the business scenario has changed. Specifically, the state switching can be performed according to the following formula:

[0091] ;

[0092] in, This represents the memory state of the k-th agent's stored data. Indicates an active state. Indicates a dormant state. Indicates a frozen state. This indicates the label that is not unloaded from the memory of the k-th agent. This indicates whether the intelligent interaction subprocess has moved to the background; a value of 1 indicates it has moved to the background, and a value of 0 indicates it has not. This indicates whether a business scenario switch has occurred; a value of 1 indicates a switch, and a value of 0 indicates no switch. This indicates the number of times the k-th agent's memory data is accessed within a pre-designed statistical period. This indicates the high-frequency call threshold. By using a memory state machine, the local retention state of the memory data can be made explicit, avoiding the premature release of critical contexts caused by relying solely on ordinary caching strategies.

[0093] When the intelligent interaction subprocess is detected to be in the background or a business scenario is switched, the local intelligent interaction subprocess switches the agent memory data with the configured non-unload tag in the personal context container to a frozen state. This switch does not mean that the memory data is stopped or deleted, but rather that the memory data enters a protected local callable storage state. For example, when a user processes a report generation task through the intelligent interaction subprocess on a mobile device, the system has recorded the data range selected by the user, the authorization status, and the preferred chart display format. When the user switches to other applications or switches to the desktop to continue the operation, the aforementioned memory data related to the report task can be switched from an active state to a frozen state, so that the remote agent can still obtain the context basis of the task when it subsequently accesses the system. Through this processing, the continuity of key personal context can be maintained when the local subprocess state changes or the business scenario is switched.

[0094] Upon receiving a local cache reclamation event, the intelligent interaction subprocess does not perform a unified eviction of all cached data. Instead, it first identifies the frozen agent memory data and removes it from the ordinary eviction queue. At the same time, it maintains the survival flag corresponding to the memory data. The survival flag indicates that the memory data still belongs to the data object that can be referenced by the local intelligent interaction subprocess or subsequent cross-platform synchronization processes. For ordinary historical memory data that is not configured with a non-unload tag and is in a dormant state, it can be entered into the ordinary eviction queue according to access time, call frequency, or cache capacity limits. By separating the management of frozen memory data from ordinary cache data, it is possible to ensure that key memory data such as incomplete tasks, valid permission status, and high-frequency preferences continue to be retained in the local callable storage area without blocking local cache reclamation, thereby reducing the risk of context breakage during cross-platform switching or agent collaboration.

[0095] S4. Monitor the state changes of the personal context container and generate memory increment update data based on the changed fields and the agent's memory data configured not to unload the label;

[0096] Furthermore, based on the changed fields in the personal context container and the agent's memory data configured not to unload tags, incremental memory update data is extracted and generated, specifically including:

[0097] Retrieve the agent's memory snapshot that was most recently synchronized in local storage, and use the agent's memory snapshot as the comparison baseline version;

[0098] The memory data of the agent in an active or frozen state is compared with the benchmark version according to the field identifier, and the differential field set that has changed state is extracted;

[0099] The differential field set is serialized into a lightweight differential log, and the lightweight differential log is used as memory for incremental update data for uploading.

[0100] Specifically, when generating incremental memory update data, the local intelligent interaction subprocess first reads the agent memory snapshot from the most recently synchronized data in local storage and uses this snapshot as the comparison benchmark. The agent memory snapshot can include information such as the field identifier, field content summary, field version number, update time, and whether the "do not unload" tag is configured for each memory field in the personal context container at the time of the most recent successful synchronization. The field content summary can be represented by a hash value, checksum, or digest encoding to quickly determine whether the corresponding field has changed during subsequent comparisons. For example, if the user's operation preference during the last synchronization was "display results in list format," this preference field and its summary value would be written into the agent memory snapshot. When the user changes the preference to "display results in table format" in subsequent interactions, the local intelligent interaction subprocess can identify that the operation preference field has changed based on this snapshot. By setting a comparison benchmark, the complete personal context container can be avoided every time there is a cross-device synchronization, thereby reducing the amount of synchronized data and reducing the risk of remote overwriting of local state.

[0101] During the field comparison process, the local intelligent interaction subprocess compares the memory data of the agent in an active or frozen state with the comparison benchmark version according to the field identifier, and extracts the differential field set that has changed state. For each field, the system can calculate the field check value in the current version and the comparison benchmark version respectively. When the two are inconsistent, the field is identified as a differential field. For memory data configured not to uninstall tags and in a frozen state, even if it is not on the current interaction page, it still participates in the field comparison to ensure that incomplete tasks, valid permission states, or high-frequency operation preferences are not missed during cross-platform synchronization. The differential field set can be determined according to the following formula:

[0102] ;

[0103] Where D represents the set of differentiated fields. This represents the i-th field in the personal context container or agent's memory data. This represents the current version of the agent's memory data. This indicates the most recently synchronized benchmark version. Indicates the field in the current version The hash value or checksum of the corresponding content. This indicates the fields in the comparison benchmark version. The hash value or checksum of the corresponding content can be used to filter out the permission fields, work status fields, preference fields or memory fragment fields that have actually changed, providing a data foundation for the subsequent generation of lightweight difference logs.

[0104] When generating incremental update data for memory, the local intelligent interaction subprocess serializes the differentiated field set according to the field identifier, the field's region, the changed field value, the current version identifier, the comparison base version identifier, the generation time, and the non-uninstall tag status to obtain a lightweight difference log. This lightweight difference log is then used as incremental update data for memory and uploaded to the remote node. The lightweight difference log can be generated according to the following formula:

[0105] ;

[0106] Where L represents a lightweight differential log, which is a log that remembers incrementally updated data; D represents the serialization function, and D represents the set of differential fields. Indicates the current version identifier. The reference version identifier is used for comparison. U represents the non-unloaded tag state corresponding to each field in the differential field set. By serializing the differential field set into a lightweight differential log, the remote node can receive only the changed memory content and its version information without having to re-receive the complete personal context container, thereby improving cross-terminal synchronization efficiency and providing traceable data for subsequent context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent.

[0107] S5. Upload the incremental update data of memory to the remote node through the cross-end synchronization link, and perform context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent to complete the local and remote layered persistence of memory data.

[0108] Furthermore, the local and remote hierarchical persistence of memory data is completed, specifically including:

[0109] Memory data of high-frequency agents that belong to the currently active task and are configured not to be unloaded will reside in the memory space of the local intelligent interaction subprocess.

[0110] Unload and archive historical agent memory data that is not configured to be unloaded and is accessed infrequently to a remote node for long-term storage.

[0111] Generate and retain a lightweight retrieval index of historical agent memory data in the local intelligent interaction subprocess.

[0112] Specifically, during the local and remote layered persistence process, the local intelligent interaction subprocess first performs a layered judgment on the incremental update data and the agent memory data in the personal context container. For agent memory data that belongs to the currently active task, has been configured with a non-uninstall tag, and is frequently called within a preset statistical period, it continues to reside in the memory space of the local intelligent interaction subprocess to ensure that it can be quickly read when the current task continues to execute. Specifically, the local residency identifier can be determined based on the task association status, the non-uninstall tag, and the call frequency.

[0113] ;

[0114] in, Indicates the first Local resident identifier for each agent's memory data This indicates that the agent's memory data resides in the memory space of the local intelligent interaction subprocess. This indicates that the agent's memory data will not be processed as locally resident data. Indicates the first The value of a smart agent's memory data is 1 if it belongs to the currently active task, and 0 otherwise. Indicates the first Whether the agent's memory data is configured not to unload the tag; if configured, the value is 1; otherwise, the value is 0. Indicates the first The number of times each agent remembers data within a preset statistical period. This indicates the high-frequency call threshold. For example, when a user is processing a report generation task across devices, the data range, authorization status, selected statistical caliber, and preferred chart display method related to the task may all belong to the currently active task and be called multiple times. Such memory data is retained in the local memory space so that the local intelligent interaction subprocess does not need to be repeatedly recalled from the remote end when the task continues to be executed.

[0115] For historical agent memory data that is not configured with a "do not unload" tag and is accessed infrequently, the local intelligent interaction subprocess unloads it from the local memory space and archives it to a remote node for long-term storage via a cross-end synchronization link. Infrequent access can be determined based on whether the number of calls within a preset statistical period is lower than the access threshold. The absence of a "do not unload" tag indicates that the historical memory data does not currently belong to data that needs to be continuously maintained locally, such as incomplete tasks, valid permission status, or high-frequency operation preferences. For this type of data, the remote node can save its complete memory content, field identifier, archiving time, source agent, and corresponding database domain isolation tag so that it can be retrieved through the remote unified vector retrieval architecture when needed later. By archiving low-frequency historical memory data to the remote node, the memory usage of the local intelligent interaction subprocess can be reduced, while preserving the long-term traceability of historical memory and avoiding the complete loss of historical context due to local cache cleanup.

[0116] After unloading and archiving the historical agent memory data to the remote node, the local intelligent interaction subprocess does not completely delete its access basis. Instead, it generates and retains the corresponding lightweight retrieval index locally. The lightweight retrieval index may include one or more of the following: the memory identifier of the historical memory data, summary information, remote archive address or index pointer, the business scenario to which it belongs, the most recent access time, and the database domain isolation label. This is used to quickly locate the remote archive data when the user re-enters the relevant business scenario. For example, when the user reopens the aforementioned report generation task several days later, the local intelligent interaction subprocess can determine the location of the corresponding historical memory data in the remote node based on the retained lightweight retrieval index, and then initiate a remote recall based on the current permission status. Through this layered approach of "retaining key memories locally, archiving historical memories remotely, and retaining lightweight indexes locally", the response speed of the current interaction, the long-term preservation of historical memories, and the continuity of cross-terminal state recovery can be balanced.

[0117] Furthermore, the context state consistency check between the local intelligent interaction subprocess and the remote intelligent agent is performed, specifically including:

[0118] Parse the incremental update data from memory and extract the bound local version identifier;

[0119] Perform a sequence comparison between the local version identifier and the global version identifier recorded on the remote node;

[0120] When the comparison results indicate a version conflict, the conflicting data is merged by executing priority-based conflict resolution and merging rules, and a consistent state snapshot is generated.

[0121] Specifically, during context state consistency verification, after receiving the memory incremental update data uploaded by the local intelligent interaction subprocess, the remote node first parses the bound local version identifier. The local version identifier can be written by the local intelligent interaction subprocess when generating a lightweight difference log, and is used to characterize the update order of the local personal context container corresponding to the memory incremental update data. At the same time, the memory incremental update data can also carry field identifiers, differential field sets, generation time, and source terminal identifier, enabling the remote node to determine which local update batch the uploaded data belongs to. For example, after a user modifies the operation preference of a certain task on the desktop, the local intelligent interaction subprocess generates the corresponding memory incremental update data and binds the local version identifier to the data. After receiving it, the remote node can determine whether the update follows the already saved global version. By parsing the local version identifier, a verification basis can be provided for subsequent version sequence comparison, avoiding the remote node from directly merging memory update data of unknown origin or unknown order.

[0122] During sequence alignment, the remote node compares its local version identifier with the global version identifier recorded by the remote node. The global version identifier represents the global state of the personal context container currently stored by the remote node and is typically updated after a successful merging of memory incremental update data on the remote end. If the local version identifier and the remote global version identifier are continuous, it means that the memory incremental update data can be directly merged. If they are not continuous, it indicates that there may be cross-terminal concurrent updates, missing incremental updates, or the remote state may have been updated by other terminals, requiring the conflict resolution process to be initiated. Version consistency can be determined using the following formula:

[0123] ;

[0124] Where G represents the version consistency check result, This indicates the local version identifier bound to the incremental update data. Represents the global version identifier of the remote node record, when When this occurs, it indicates that the local version identifier and the remote global version identifier are consecutive, allowing the incremental update data of this memory to be merged into the remote node. When this occurs, it indicates that there is a version conflict or version missing, and priority-based conflict resolution and merging rules need to be executed. Through this sequence comparison method, the context synchronization process between the local intelligent interaction subprocess and the remote intelligent agent can have a clear version boundary, reducing the risk of old version data overwriting the new version state.

[0125] When the comparison results indicate a version conflict, the remote node does not directly discard the locally uploaded incremental update data, nor does it simply overwrite the local state with the remote global state. Instead, it extracts the conflicting fields as conflict data and calls a priority-based conflict resolution and merging rule for processing. The conflict data can include different values ​​of the same field in the local version and the remote global version, the corresponding data classification label, the generation timestamp, and whether it carries an "uninstall" label. After the conflict is resolved, the remote node generates a consistency snapshot based on the merged field state, the local version identifier, the global version identifier, and the conflict processing result. This consistency snapshot is used as the remote context state record after this verification. For example, if a user is still in a temporary working state of a task on the mobile device, and the desktop device updates the display preferences of the same task, the remote node can identify updates from different sources for the same container field through version conflicts and generate a unified consistency snapshot after the conflict is resolved. Through this process, the individual context state can be kept traceable and recoverable during cross-device concurrent interaction or remote agent collaborative processing, reducing the risk of agents calling incorrect memories due to inconsistencies between local and remote context states.

[0126] Furthermore, priority-based conflict resolution and merging rules are executed to merge conflicting data, specifically including:

[0127] The data classification tags for parsing conflicting data include security permission tags and temporary business tags.

[0128] When the data classification label is a security permission label, the global version data recorded by the remote node is used as the merged permission status;

[0129] When the data classification label is a temporary business category label, the version data carrying the latest locally generated timestamp is used as the merged business status;

[0130] When conflicting data carries a non-unload tag, retain a copy of the current state in the local smart interaction subprocess before performing the merge.

[0131] Specifically, when performing conflict resolution and merging, the remote node first parses the data classification labels of the conflicting data to determine whether it belongs to security permission data or temporary business data. Security permission data includes user identity permissions, authorization token status, and scope of accessible tools, while temporary business data includes the current task stage, temporary working status, operation preference changes, or intermediate results of agent processing. By classifying and processing, the same merging rule can be avoided for data of different natures, thereby improving the accuracy of conflict resolution.

[0132] When the data category label is security permission, the global version data recorded by the remote node is used as the merged permission status. For example, if the local cache still retains the permission to call a certain tool, but the remote node has recorded that the permission has been revoked, then the remote global version will prevail, preventing the remote agent from continuing to access tools or data based on expired permissions. This rule is used to ensure that the permission class context remains consistent during cross-device synchronization.

[0133] When the data classification label is a temporary business category label, the version data with the latest locally generated timestamp is used as the merged business state. For example, if the user advances the task to the "result confirmation" stage on the mobile terminal, but the remote node still records it as the "content generation" stage, if the mobile terminal version has a newer locally generated timestamp, then that version is used as the merged business state. This rule is used to enable the remote agent to obtain a task state that is closer to the user's latest operation.

[0134] When conflicting data carries a "do not unload" tag, a copy of the current state in the local intelligent interaction subprocess is retained before merging. The copy of the current state may include conflict field values, local generation timestamps, the task identifier, and the local cache location. Retaining this copy does not necessarily mean that it will be the final merge result, but rather it is used for subsequent task recovery or state rollback to avoid the local active task context being directly overwritten.

[0135] In one specific implementation, conflict resolution and merging can be performed as follows:

[0136] ;

[0137] When conflicting data carries tags that are not unloaded, retain a local copy of the current state:

[0138] ;

[0139] in, Indicates the first The state after merging conflicting data. This represents the global version data recorded on the remote node. This represents the local version data within the local intelligent interaction subprocess. Indicates the first Data classification labels for conflicting data. Tags indicating security permissions This indicates a temporary business category tag. This indicates the timestamp used to generate the local version of the data. This represents the timestamp used to generate the remote global version data. Indicates the first Does the conflicting data carry a non-unloaded tag? This indicates that a copy of the current local state is retained, thus maintaining the continuity of local active tasks while keeping the permission state consistent.

[0140] S6. Respond to the task instructions of the remote multi-agent cluster, perform isolated retrieval in the remote unified vector retrieval architecture based on data domain isolation labels and access masks, recall the target personalized memory and inject the corresponding agent's running context.

[0141] Furthermore, the isolated retrieval protocol is executed within the remote unified vector retrieval architecture, specifically including:

[0142] The agent's memory data to be stored is transformed into vector feature data, and the data domain isolation label is written into the metadata bound to the vector feature data;

[0143] According to the data domain isolation label, write the vector feature data into the corresponding index partition or namespace;

[0144] Receive retrieval requests initiated by remote intelligent agents and extract the user identity identifier and intelligent agent identity identifier carried in the retrieval request;

[0145] Based on user identity identifiers, agent identity identifiers, and data domain isolation labels, the target index partition or namespace is determined, and an access mask for metadata matching is dynamically generated.

[0146] Specifically, in the remote unified vector retrieval architecture, the remote node first performs vectorization processing on the agent memory data to be stored. The agent memory data can come from locally uploaded incremental update data, or from historical interaction summaries, task processing results, or user confirmation information generated by the remote agent during task execution. After extracting semantic content from the above memory data, the remote node generates vector feature data and writes the data domain isolation label corresponding to the memory data into the metadata bound to the vector feature data. The metadata can include information such as user identity, data domain isolation label, source agent identity, business scenario, permission level, and update time. By binding the data domain isolation label to the vector feature data, the subsequent retrieval process can not only recall based on semantic similarity, but also isolate and filter based on personal data domain and permission range, avoiding the mixed retrieval of memory data from different users or different agents within their permission range.

[0147] When writing to the remote vector retrieval layer, the remote node writes the vector feature data to the corresponding index partition or namespace according to the data domain isolation label. The index partition or namespace can be divided according to user identity, business data domain, agent function category, or permission level, so that memory data belonging to different personal context containers or different access scopes are stored in different retrieval spaces. For example, even if user A's writing preference memory and user B's writing preference memory are similar in semantic content, they are written to their respective corresponding index partitions or namespaces. Under the same user, permission verification memory and ordinary business preference memory can also be written to different retrieval spaces according to different data domain isolation labels. Through this process, a data domain-based isolated storage foundation can be formed under the unified vector retrieval architecture.

[0148] When a remote agent needs to access personal memory, the remote node receives the retrieval request initiated by the agent and extracts the user identifier and agent identifier from the request. The user identifier is used to determine the personal context to which the retrieval request belongs, and the agent identifier is used to determine the type of agent that initiated the request and its access permissions. The retrieval request can also carry information such as task instructions, the current business scenario, retrieval text, or retrieval vectors. For example, when a remote writing agent requests to obtain a user's result display preferences, the retrieval request includes the user's ID card and the writing agent's identifier. Based on this, the remote node determines whether the request can enter the corresponding user's personal memory data domain and determines the scope of memory that can be accessed.

[0149] When generating the access mask, the remote node determines the target index partition or namespace based on the user identity, agent identity, and data domain isolation label, and dynamically generates an access mask for metadata matching. The access mask represents the range of data domains that the remote agent is allowed to access under the current task instruction, and is used for subsequent matching with metadata bound to vector feature data. The access mask can be generated according to the following formula:

[0150] ;

[0151] in, Indicates the access mask. Indicates user identity identifier, Indicates the identity of the intelligent agent. Indicates a data domain isolation label. This represents the access mask generation function, which generates mask data that can be used for metadata matching based on user identity, agent identity, and data domain isolation label. In other words, before performing vector retrieval, the remote agent is first restricted to the target index partition or namespace, and the range of matching metadata is limited by the access mask, thereby realizing personal memory isolation retrieval and permission-controlled invocation in the remote unified vector retrieval architecture.

[0152] Furthermore, the recall of personalized memories of the target population specifically includes:

[0153] Before executing the vector similarity calculation instruction, the access mask is matched with the metadata stored in the remote unified vector retrieval architecture using Boolean logic to filter out the exclusive vector data clusters that match the access mask;

[0154] Within the scope of the dedicated vector data cluster, a corresponding target vector is generated based on the retrieval request, and the distance between the target vector and the dedicated vector data cluster is calculated to recall the personalized memory of the target that meets the similarity threshold.

[0155] Specifically, when recalling personalized memories of a target, the remote unified vector retrieval architecture first performs Boolean logic matching between the access mask and the metadata bound to the vector feature data. The metadata can include user identification, data domain isolation labels, agent access range, permission level, and business scenario identifiers. The access mask represents the range of data domains that the remote agent is allowed to access under this task instruction. Through this matching process, specific vector data clusters matching the access mask can be filtered out before performing vector similarity calculations, avoiding direct retrieval by the remote agent in the full memory data. This filtering process can be represented as:

[0156] ;

[0157] in, This represents a dedicated vector data cluster that matches the access mask. In the remote unified vector retrieval architecture, the first... Vector feature data, Indicates the access mask. Indicates the first Metadata bound to vector feature data, This represents the Boolean logic matching result between the access mask and the metadata. A value of 1 indicates a match, and a value of 0 indicates a no match.

[0158] After obtaining the dedicated vector data cluster, the remote unified vector retrieval architecture generates the target vector based on the retrieval request. And only in dedicated vector data clusters Perform similarity calculations within the specified range and recall personalized memories that meet the similarity threshold:

[0159] ;

[0160] in, This refers to the personalized memory set of the target being recalled. Indicates the relationship with the first Personalized memory corresponding to each vector feature data This represents the target vector generated based on the search request. Represents the target vector With vector feature data Similarity between them This represents the similarity threshold. By first performing access mask matching and then calculating similarity within the dedicated vector data cluster, the recall results can simultaneously satisfy personalized relevance and access permission restrictions.

[0161] For example, when a remote writing agent performs the task of "generating a summary report in a format commonly used by the user", it can first filter the writing preference data clusters that the user can access through the writing agent by using an access mask, then recall the target personalized memory related to the report format in the data cluster, and inject the recall result into the running context of the writing agent. This way, the agent can continue the user's historical preferences and avoid recalling memory data from other users or those with different permissions.

[0162] Example 1

[0163] Cross-device office intelligent agent collaboration scenarios:

[0164] In this embodiment, the user first initiates the "Generate Meeting Minutes" task on the mobile device through a local intelligent interaction subprocess, and then switches to the desktop to continue processing. The local intelligent interaction subprocess collects the user's permission identifier, current working status, and operation preference characteristics, encapsulates them into a personal context container, and writes the user's identity, authorization token, and accessible document range into the static permission area. It writes status nodes such as "material upload, document parsing, summary generation, and to-do list organization" and the user's preferred output format into the dynamic business area. At the same time, it configures data domain isolation labels for different intelligent agents. For intelligent agent memory data such as incomplete summary, confirmed output format, and valid authorization status in the meeting minutes task, the system configuration does not unload it. The system uses tags to retain these tags in locally accessible storage when the local cache is reclaimed. When a user switches terminals, the system generates incremental update data for the changed work status and preference fields and uploads it to the remote node. The remote node performs version consistency verification. When the remote writing agent requests to access historical preferences, the remote unified vector retrieval architecture filters exclusive vector data clusters based on user identity, agent identity, data domain isolation tags, and access masks. It retrieves the target personalized memory related to the meeting minutes format and injects it into the writing agent's runtime context. This allows users to continue processing tasks across terminals without having to repeat format preferences and task progress, while also preventing other agents from unauthorizedly accessing personal contexts.

[0165] Example 2

[0166] Development and maintenance multi-agent collaborative scenarios:

[0167] In this embodiment, developers initiate a task to "analyze anomaly logs and provide rollback suggestions" on their local terminal. The local intelligent interaction subprocess collects their project access permissions, log platform authorization status, current investigation stage, and preferred processing step format, and encapsulates this information into a personal context container. The static permission area records access permissions to the project repository, log platform, and deployment tools, while the dynamic business area records anomaly log identifiers, service versions, risk level confirmation status, and rollback suggestion preferences. Data domain isolation labels are configured based on the functional categories of the code analysis agent, log diagnosis agent, deployment suggestion agent, and security audit agent. For critical memory data such as the current service version number, incomplete diagnosis results, valid deployment authorization, and user-confirmed rollback windows, the system is configured not to unload the labels and retains them in the local callable storage area when the local cache is recycled or the business is switched. When the user continues to process the same anomaly task on another terminal, the system generates a lightweight difference log for the changed fields and uploads it to the remote node. The remote node then performs consistency checks and conflict merging based on the local version identifier and the global version identifier. When the remote deployment suggestion agent retrieves historical processing experience, it first filters the developer's exclusive vector data clusters within the corresponding project's permission scope by matching access masks and metadata. Then, it recalls the target personalized memory that meets the similarity threshold and injects it into the deployment suggestion agent's runtime context, thereby ensuring project permission isolation while continuing the developer's historical processing habits.

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

Claims

1. A method for encapsulating personal contexts and persisting data across multiple agents, characterized in that, include: S1. Collect personal dimension information of users during cross-terminal intelligent interaction, including permission identifiers, current working status and operation preference characteristics; S2. Encapsulate the personal dimension information into a personal context container, and configure a data domain isolation label for the personal context container; Specifically, the step of structuring and encapsulating the personal dimension information into a personal context container and configuring data domain isolation labels includes: Construct a hierarchical container data structure, dividing the personal context container into a static permission area and a dynamic business area; The permission identifier is written into the static permission area, and the current working status and operation preference features are encapsulated into the dynamic business area according to the time sequence to support the dynamic update mechanism of the dynamic business area; Based on the functional categories of multiple agents, the data domain isolation label is configured for the static permission area and the dynamic business area respectively, so as to define the fine-grained read and write permissions of different agents to the personal context container. S3. In the local intelligent interaction subprocess, configure the agent memory data that meets the retention conditions in the personal context container with a non-unload tag, so that the agent memory data with the non-unload tag is retained in the local callable storage area when the local cache is recycled. S4. Monitor the state changes of the personal context container, and generate memory increment update data based on the changed fields and the agent memory data configured not to unload the tag; S5. Upload the memory incremental update data to the remote node through the cross-end synchronization link, and perform context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent to complete the local and remote layered persistence of memory data. S6. Responding to the task instructions of the remote multi-agent cluster, perform isolated retrieval in the remote unified vector retrieval architecture based on the data domain isolation label and access mask, recall the target personalized memory and inject the corresponding agent's running context.

2. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 1, characterized in that, The dynamic update mechanism specifically includes: The intelligent interaction subprocess listens for real-time interaction events and updates the current working status in the dynamic business area using a sliding window mechanism. When a change in business scenario is detected, a silent flag is configured for the expired state data in the dynamic business area; Based on the new interaction intent after the switch, a new working status node is generated and written to the dynamic business area.

3. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 1, characterized in that, The step of configuring the agent's memory data within the personal context container that meets the retention conditions to not unload tags and executing a non-unloading priority strategy specifically includes: A memory state machine is configured in the intelligent interaction subprocess, and the memory state machine includes at least an active state, a dormant state, and a frozen state. When it is detected that the intelligent interaction subprocess has retreated to the background or a business scenario has changed, the intelligent agent memory data configured with non-unloaded tags in the personal context container will be switched to the frozen state. Upon receiving a local cache reclamation event, the agent's memory data that is in a frozen state is removed from the normal elimination queue, and the corresponding survival flag is maintained.

4. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 3, characterized in that, The process of extracting and generating incremental memory update data based on the changed fields in the personal context container and the agent's memory data configured to not unload tags specifically includes: Obtain the most recently synchronized agent memory snapshot from local storage and use the agent memory snapshot as the comparison benchmark version; The memory data of the agent in the active or frozen state is compared with the comparison benchmark version according to the field identifier, and the differential field set in which the state has changed is extracted; The differentiated field set is serialized into a lightweight difference log, and the lightweight difference log is used as the memory incremental update data for uploading.

5. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 1, characterized in that, The completion of local and remote hierarchical persistence of memory data specifically includes: The memory data of high-frequency intelligent agents that belong to the currently active task and are configured not to be uninstalled reside in the memory space of the local intelligent interaction subprocess; Unload and archive the historical agent memory data that is not configured to be unloaded and is accessed infrequently to the remote node for long-term storage. A lightweight retrieval index is generated and retained in the local intelligent interaction subprocess to store the historical agent memory data.

6. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 1, characterized in that, The process of performing context state consistency verification between the local intelligent interaction subprocess and the remote intelligent agent specifically includes: Parse the memory incremental update data and extract the bound local version identifier; Perform a sequence comparison between the local version identifier and the global version identifier recorded by the remote node; When the comparison results indicate a version conflict, the conflicting data is merged by executing priority-based conflict resolution and merging rules, and a consistent state snapshot is generated.

7. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 6, characterized in that, The execution of priority-based conflict resolution and merging rules to merge conflicting data specifically includes: The conflict data is parsed using data classification tags, which include security permission tags and temporary business tags. When the data classification label is the security permission category label, the global version data recorded by the remote node is used as the merged permission status; When the data classification label is the temporary business category label, the version data carrying the latest locally generated timestamp is used as the merged business status; When the conflicting data carries a non-unload tag, a copy of the current state in the local intelligent interaction subprocess is retained before the merging is performed.

8. The method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 1, characterized in that, The execution of the isolated retrieval protocol in the remote unified vector retrieval architecture specifically includes: The agent's memory data to be stored is converted into vector feature data, and the data domain isolation label is written into the metadata bound to the vector feature data; According to the data domain isolation label, the vector feature data is written into the corresponding index partition or namespace; Receive a retrieval request initiated by a remote intelligent agent, and extract the user identity identifier and intelligent agent identity identifier carried in the retrieval request; Based on the user identity identifier, agent identity identifier, and data domain isolation label, the target index partition or namespace is determined, and an access mask for metadata matching is dynamically generated.

9. A method for encapsulating personal contexts and cross-platform persistence for multiple agents according to claim 8, characterized in that, The personalized memory of the recall target specifically includes: Before executing the vector similarity calculation instruction, the access mask is matched with the metadata stored in the remote unified vector retrieval architecture using Boolean logic to filter out the exclusive vector data clusters that match the access mask; Within the defined scope of the dedicated vector data cluster, a corresponding target vector is generated according to the retrieval request, and distance calculation is performed between the target vector and the dedicated vector data cluster to recall personalized memories of targets that meet the similarity threshold.

Images