A memory management method and system of an end-side agent, an electronic device and a storage medium

Abstract

The application relates to the technical field of artificial intelligence interaction, and discloses a memory management method and system of an end-side intelligent agent, electronic equipment and a storage medium, and the method for applying a unified memory management service in an end-side operating system comprises the following steps: in response to receiving a memory interaction request of a calling party for memory data, obtaining the identity of the calling party and the data access level declared by the calling party when writing; based on the identity and the data access level, assigning an access permission domain to the memory data and performing permission verification; performing semantic segmentation processing on the memory data in the memory data writing stage or when the device is idle; and based on the device running state, dynamically scheduling the execution time of a semantic feature extraction task and dynamically adjusting a memory retrieval strategy. The system-level decoupling and controllable sharing of the memory data are realized through the permission domain isolation driven by the system-level unified entrance and the data access level, the end-side power consumption and foreground response delay are reduced through pre-segmentation and dynamic scheduling according to the device state.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence interaction technology, and in particular to a memory management method, system, electronic device and storage medium for edge-side intelligent agents. Background Technology

[0002] With the development of large language models and intelligent agent technology, intelligent agents in terminal devices can perform tasks such as system control, application operation, information query, device debugging, and in-vehicle interaction based on user commands. To improve the processing capability of continuous tasks, intelligent agents usually need to store a certain historical context, such as user preferences, application usage habits, device status, historical task results, and problem-solving experience, and read this data as memory context in subsequent tasks.

[0003] Currently, the memory data of edge-side intelligent agents is typically maintained by individual applications. For example, a smart assistant application can save user's historical conversations, task summaries, or preference settings in its own application data directory and retrieve this data in subsequent conversations. Some solutions upload the memory data to a cloud account, where cloud services store and retrieve it.

[0004] However, in edge operating systems such as Android / AOSP, applications are isolated from each other through mechanisms such as UID, package name, and user ID. If each agent or application maintains its own memory data, memory silos can easily form, making it difficult for different applications, system agents, and third-party agents to securely and controllably share and reuse memory data through a unified system-level entry point. Since memory data may contain sensitive content such as user privacy, device information, application behavior, and debugging information, the lack of a unified system-level permission isolation and data access level declaration mechanism can easily lead to unclear access boundaries and the risk of cross-application data leakage when each application manages its own memory data.

[0005] Therefore, improvements to existing technologies are necessary. Summary of the Invention

[0006] This invention provides a memory management method, system, electronic device, and storage medium for edge-side intelligent agents to solve the problems existing in the prior art.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A memory management method for edge-side intelligent agents, applied to a unified memory management service in an edge-side operating system, includes:

[0009] In response to receiving a memory interaction request from a caller for memory data, the system obtains the caller's identity identifier and the data access level corresponding to the memory data, wherein the data access level is declared by the caller when writing the memory data;

[0010] Based on the caller's identity and the data access level, an access permission domain is assigned to the memory data, and permission verification is performed on the memory interaction request based on the access permission domain;

[0011] During the memory data writing phase or when the device is idle, semantic segmentation processing is performed on the memory data to obtain multiple semantic segments;

[0012] Based on the operating status of the device, the execution timing of the semantic feature extraction task for the semantic segment is dynamically scheduled, and the memory retrieval strategy for the memory data is dynamically adjusted.

[0013] In one possible implementation, the data access levels include at least public level, application privacy level, agent privacy level, user-authorized sharing level, de-identified sharing level, and system level;

[0014] The step of performing permission verification on the memory interaction request based on the access permission domain includes:

[0015] When the memory interaction request is a memory retrieval request:

[0016] If the data access level is public, authorized callers who meet the preset query conditions are allowed to recall the memory data;

[0017] If the data access level is application privacy level or agent privacy level, only the caller belonging to the access permission domain is allowed to access the memory data;

[0018] If the data access level is the user-authorized sharing level, only user-authorized callers are allowed to access the memory data within the authorized scope;

[0019] If the data access level is the de-identified sharing level, perform de-identification processing on the memory data and return it;

[0020] If the data access level is system level, only system services or system agents are allowed to access the memory data.

[0021] In one possible implementation, the access permission domain includes at least one of the following basic access permission domains: private memory domain, application memory domain, agent memory domain, public sharing domain, user sharing domain, de-identified sharing domain, and system memory domain;

[0022] The access permission domain is also bound to a project identifier or tenant identifier, which serves as an organizational isolation attribute superimposed on the basic access permission domain.

[0023] In one possible implementation, the semantic segmentation process performed on the memory data yields multiple semantic segments, including:

[0024] Based on topic rounds, time windows, and / or task chains, the memory data in long text form is split into multiple independent semantic segments;

[0025] Generate summary information, classification labels, sensitivity levels, and confidence levels for the semantic segments, and bind related semantic segments to the same task identifier.

[0026] In one possible implementation, the operating state of the device includes at least one of the following: device load status, device power status, and device temperature status;

[0027] The dynamic scheduling of the execution timing of the semantic feature extraction task for the semantic segment includes:

[0028] When the operating state meets the preset high load condition, preset low power condition, or preset high temperature condition, the semantic feature extraction task is executed with a delay or asynchronously.

[0029] When the running state meets the preset idle condition or preset charging condition, the semantic feature extraction task is executed in batches.

[0030] The dynamic adjustment of the memory retrieval strategy for the memory data includes:

[0031] When the operating state meets the preset high load condition, the preset low power condition, or the preset high temperature condition, a lightweight recall is performed using a structured query, keyword matching, or tag matching strategy.

[0032] When the operating state meets the preset idle condition or the preset charging condition, a deep semantic recall is performed using a semantic vector retrieval and / or relation graph expansion strategy.

[0033] In one possible implementation, the memory retrieval strategy includes:

[0034] A candidate memory set is obtained by performing structured filtering based on the access permission domain, memory type, time range, or sensitivity level.

[0035] Semantic vector retrieval is performed on the candidate memory set, and multi-hop association expansion retrieval is performed through the relation graph;

[0036] The recall results are ranked by combining semantic similarity, memory confidence, timeliness, graph relationship distance, and energy cost.

[0037] In one possible implementation, the method further includes:

[0038] When writing new memory data, retrieve similar historical memories within the same access permission domain or fusionable access permission domain;

[0039] If a content conflict is detected between the new memory data and the historical similar memory, the historical similar memory will be subject to downweighting, merging, expiration marking, or pending confirmation processing based on time information, source information, or confidence assessment indicators.

[0040] In response to the task execution result, update the confidence level of the relevant memory data.

[0041] In one possible implementation, the method further includes:

[0042] When the caller's access permissions do not meet the original content access conditions, or when the data access level is the de-identified sharing level, the memory data is digested or de-identified and returned, and an operation audit record for the memory interaction request is generated.

[0043] In one possible implementation, the unified memory management service is deployed in the system service process of the terminal operating system, or deployed as a privileged application with system permissions;

[0044] The unified memory management service receives the memory interaction request through the Binder / AIDL interface and provides a unified calling interface to the caller through the framework layer API of the terminal operating system.

[0045] The unified memory management service authenticates the caller through at least one of the following permission control methods: system signature permission, privileged permission, system application whitelist, application role permission, and device policy.

[0046] On the other hand, the present invention also provides a memory management method for a terminal-side intelligent agent, applied to a caller in a terminal-side operating system, comprising:

[0047] A memory write request is generated, which carries the identity of the caller and the data access level declared for the memory data, and the memory write request is sent to the unified memory management service in the terminal operating system.

[0048] Generate a memory retrieval request and send the memory retrieval request to the unified memory management service;

[0049] The system receives the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. The recall result includes the original memory content, de-identified content, or summary content.

[0050] On the other hand, the present invention also provides a memory management system for edge-side intelligent agents, applied to a unified memory management service in an edge-side operating system, including a unified memory management service deployed on the system side of the edge-side operating system, the unified memory management service including:

[0051] The request processing module is used to respond to a caller's memory interaction request for memory data, and to obtain the caller's identity identifier and the data access level corresponding to the memory data.

[0052] The permission isolation module is used to allocate access permission domains to the memory data based on the identity identifier of the caller and the data access level, and to perform permission verification on the memory interaction request based on the access permission domains;

[0053] The segmentation processing module is used to perform semantic segmentation processing on the memory data during the memory data writing phase or when the device is idle, to obtain multiple semantic segments.

[0054] The dynamic scheduling module is used to dynamically schedule the execution timing of the semantic feature extraction task for the semantic segment based on the operating status of the device, and to dynamically adjust the memory retrieval strategy for the memory data.

[0055] On the other hand, the present invention also provides a memory management system for edge-side intelligent agents, applied to callers in edge-side operating systems, including:

[0056] The request generation module is used to generate a memory write request, which carries the identity identifier of the caller and the data access level declared for the memory data, as well as generate a memory recall request;

[0057] The sending module is used to send the memory write request and the memory recall request to the unified memory management service in the terminal operating system;

[0058] The receiving module is used to receive the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. The recall result includes the original memory content, de-identified content, or summary content.

[0059] The processing module is configured to perform task processing based on the recall results.

[0060] On the other hand, the present invention also provides an electronic device, comprising:

[0061] At least one processor; and,

[0062] A memory communicatively connected to the at least one processor; wherein,

[0063] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0064] On the other hand, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the preceding claims.

[0065] Compared with the prior art, the present invention has the following beneficial effects:

[0066] First, by receiving memory interaction requests for memory data from callers through a unified memory management service deployed on the operating system side, different applications, system agents, and third-party agents no longer maintain their own memory banks independently. Instead, they complete memory interaction through a unified system-level entry point, thereby reducing the duplication of memory data storage, avoiding the formation of memory silos, and providing a unified and controllable interaction foundation for memory sharing across applications and agents.

[0067] Second, by obtaining the caller's identity and the data access level declared by the caller during writing, and assigning access permission domains to the memory data based on the caller's identity and data access level, and performing permission verification on memory interaction requests based on the access permission domains, each piece of memory data has a clear ownership scope and access boundaries at the system level. Therefore, the system can determine the set of accessible subjects for memory data during the writing phase, avoiding unauthorized cross-application reading, reducing the risk of privacy leaks, and establishing a clear technical boundary between the shareability of memory data and privacy protection.

[0068] The present invention has other features and advantages, which will be apparent from or will be set forth in detail in the accompanying drawings and the following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

[0069] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0070] Figure 1 This is a flowchart illustrating the memory management process executed by the caller on the caller side in a memory management method for an edge-side intelligent agent provided in an embodiment of the present invention.

[0071] Figure 2 This is a memory retrieval / recall process architecture in a memory management method for edge-side intelligent agents provided by an embodiment of the present invention, which starts from the unified memory management service receiving a memory recall request initiated by the caller;

[0072] Figure 3 This is a flowchart illustrating the method of executing the memory management process in the unified memory management service on the unified memory management service side, as provided in an embodiment of the present invention.

[0073] Figure 4 This is a memory writing workflow in a memory management method for an edge-side intelligent agent provided in an embodiment of the present invention, which starts from the unified memory management service receiving a memory writing request initiated by the caller;

[0074] Figure 5 This is a structural block diagram of a memory management system for an edge-side intelligent agent provided in an embodiment of the present invention;

[0075] Figure 6 This is another structural block diagram of a memory management system for an edge-side intelligent agent provided in an embodiment of the present invention.

[0076] Attached reference numerals: 11. Request processing module; 12. Permission isolation module; 13. Segmentation processing module; 14. Dynamic scheduling module; 21. Request generation module; 22. Sending module; 23. Receiving module; 24. Processing module. Detailed Implementation

[0077] To illustrate in detail the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of the embodiments of the present invention, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of the embodiments of the present invention and are therefore only examples, and should not be construed as limiting the scope of protection of the embodiments of the present invention.

[0078] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment can be included in at least one embodiment of the present invention. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in the embodiments of the present invention, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0079] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this invention pertain; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit the embodiments of this invention.

[0080] In the description of the embodiments of this invention, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " in this document generally indicates that the preceding and following objects have an "or" logical relationship.

[0081] In embodiments of the present invention, terms such as “first” and “second” are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy, or order relationship between these entities or operations.

[0082] Without further limitations, in embodiments of the present invention, the use of terms such as “comprising,” “including,” “having,” or other similar expressions is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a series of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0083] Similar to the understanding in the Examination Guidelines, in this embodiment of the invention, expressions such as "greater than," "less than," and "exceeding" are understood to exclude the number itself; expressions such as "above," "below," and "within" are understood to include the number itself. Furthermore, in the description of this embodiment of the invention, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times," unless otherwise explicitly specified.

[0084] In the description of the embodiments of the present invention, the spatial related expressions used, such as "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "vertical," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," indicate the orientation or positional relationship based on the orientation or positional relationship shown in the specific embodiments or drawings. They are only for the purpose of facilitating the description of the specific embodiments of the present invention or for the reader's understanding, and do not indicate or imply that the device or component referred to must have a specific position, a specific orientation, or be constructed or operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of the present invention.

[0085] Unless otherwise explicitly specified or limited, the terms "installation," "connection," "linking," "fixing," and "setting," as used in the description of the embodiments of this invention, should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral arrangement; it can be a mechanical connection, an electrical connection, or a communication connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal connection of two components or the interaction between two components. Those skilled in the art to which these embodiments pertain can understand the specific meaning of the above terms in the embodiments of this invention according to the specific circumstances.

[0086] The following is in conjunction with the appendix Figures 1 to 6 The embodiments of the present invention will be described in further detail below.

[0087] This invention discloses a long-term memory management method for edge-side intelligent agents, particularly a system-level decoupling management method for the long-term memory of intelligent agents under edge-side operating systems such as Android / AOSP. Specifically, the edge-side operating system can be Android, a customized AOSP system, or other operating systems compatible with the Android architecture, and can be deployed on devices such as in-vehicle display terminals, intelligent cockpit systems, and industrial intelligent terminals.

[0088] It should be noted that the method in this embodiment of the invention involves two cooperating execution entities: one is a unified memory management service deployed on the terminal operating system side, and the other is a caller initiating memory interaction. The caller can be an application running on the terminal device, a system agent, a third-party agent, or a system service.

[0089] Among them, the unified memory management service serves as the unified memory interaction entry point between different applications, system intelligent agents, third-party intelligent agents, and system services. It is responsible for writing, recalling, updating, deleting, verifying permissions, and auditing access to memory data. The caller completes the writing, recalling, updating, and deleting of memory data by sending memory interaction requests to the unified memory management service.

[0090] Please refer to Figure 1 In this embodiment, on the caller side, the caller executes the following memory management process:

[0091] S11. Generate a memory write request. The memory write request carries the caller's identity and the data access level declared for the memory data, and sends the memory write request to the unified memory management service in the end-side operating system.

[0092] S12. Generate a memory retrieval request and send the memory retrieval request to the unified memory management service;

[0093] S13. Receive the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. The recall result includes the original memory content, desensitized content, or summary content.

[0094] Specifically, when a caller needs to save memory data, it generates a memory write request. This request carries the caller's identity and the declared data access level for the memory data, and is sent to the unified memory management service in the client-side operating system. The data access level is actively declared by the caller when writing the memory data, indicating the scope within which the memory data is allowed to be shared and the format of the content returned upon sharing. When a caller needs to retrieve memory data, it generates a memory retrieval request and sends it to the unified memory management service. The caller then receives the retrieval result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. This retrieval result can be the original memory content, anonymized content, or digested content. By having the caller declare the data access level during writing, and having the unified memory management service uniformly perform permission verification and return format control on the system side, the caller does not need to maintain the memory database itself, nor does it need to implement cross-application access control logic, thus achieving decoupling of memory management at the system level.

[0095] Reference Figure 2 , Figure 2The memory retrieval / recall process architecture in this embodiment is illustrated. The process begins with the unified memory management service receiving a memory recall request initiated by a caller, and proceeds sequentially as follows: identifying the caller's identity; determining the caller's accessible permission domains; filtering by permissions, type, time, and sensitivity level based on a structured database to obtain a candidate memory set; determining whether the device status allows high-overhead retrieval; if not, keyword or tag recall is used; if allowed, vector similarity retrieval and graph relationship expansion are performed sequentially; ranking the candidate memories based on confidence, timeliness, similarity, graph distance, and power consumption cost; performing anonymization or summarization processing on the ranked candidate memories before returning them; and finally, updating the confidence of the relevant memories based on the task execution results. Through this process, the recall process first narrows the candidate range through structured coarse screening, then switches between lightweight retrieval and deep semantic retrieval based on device status, and finally returns the results after multi-dimensional ranking and anonymization processing, achieving efficient, secure, and intelligent memory recall.

[0096] Please refer to Figure 3 In this embodiment, on the unified memory management service side, the unified memory management service executes the following memory management process:

[0097] S21. In response to receiving a memory interaction request from the caller for the memory data, obtain the caller's identity and the data access level corresponding to the memory data. The data access level is declared by the caller when writing the memory data.

[0098] S22. Based on the caller's identity and data access level, assign access permission domains to the memory data, and perform permission verification on the memory interaction request based on the access permission domains;

[0099] S23. When the memory data is being written or the device is in an idle state, semantic segmentation processing is performed on the memory data to obtain multiple semantic segments.

[0100] S24. Based on the device's operating status, dynamically schedule the execution timing of semantic feature extraction tasks for semantic segments, and dynamically adjust the memory retrieval strategy for memory data.

[0101] Specifically, upon receiving a memory interaction request from a caller for memory data, the unified memory management service first obtains the caller's identity identifier corresponding to the memory interaction request and the data access level corresponding to the memory data. The caller's identity identifier can be obtained through process call context parsing provided by the operating system, such as the caller's UID, application package name, system user ID, and agent identifier. By simultaneously obtaining the caller's identity identifier and data access level, a basis is provided for subsequent permission domain allocation and permission verification.

[0102] After obtaining the caller's identity and data access level, the unified memory management service assigns access permission domains to the memory data based on these domains and performs permission checks on memory interaction requests accordingly. Access permission domains define the scope and access boundaries of the memory data, ensuring that each piece of memory data has a clearly defined set of accessible subjects at the system level. Because permission domains are uniformly assigned and verified on the system side, each application and agent no longer maintains its own private access control logic, thus avoiding issues of inconsistent permission standards and unauthorized access, and reducing the risk of privacy leaks caused by cross-application reading. When the memory interaction request is a memory write request, permission checks determine whether the caller has the permission to write memory data at that data access level; when the memory interaction request is a memory recall request, permission checks determine whether the caller is within the set of accessible subjects for that memory data.

[0103] Furthermore, during the memory data writing phase or when the device is idle, the unified memory management service performs semantic segmentation on the memory data, resulting in multiple semantic fragments. Unlike the method of real-time segmentation of the complete memory data during each recall, this embodiment of the invention performs semantic segmentation beforehand during the writing phase or when the device is idle, allowing the recall phase to directly reuse already generated semantic fragments without needing to split the complete historical context in real time. As a result, the real-time computation load during the recall phase is significantly reduced, and the foreground response latency is shortened.

[0104] After semantic segmentation is completed, the unified memory management service dynamically schedules the execution timing of semantic feature extraction tasks for semantic segments based on the device's operating status, and dynamically adjusts the memory retrieval strategy for memory data.

[0105] Specifically, semantic feature extraction is used to generate vector representations for semantic fragments, which is the foundation for subsequent semantic similarity retrieval. However, semantic feature extraction has a large computational overhead, and if it is always executed immediately during writing or recall, it can easily cause lag when device resources are scarce. Therefore, this embodiment of the invention determines when and how the semantic feature extraction task is executed based on the device's operating status, and switches between lightweight retrieval and deep semantic retrieval based on the device's operating status, thereby achieving a balance between retrieval performance and device power consumption.

[0106] Please refer to Figure 4 , Figure 4The memory writing workflow in this embodiment is illustrated. The process begins with the unified memory management service receiving a memory writing request from a caller, and proceeds sequentially as follows: identifying the caller's identity; assigning access permission domains to the memory data based on the caller's identity and data access level; performing record pre-segmentation for memory data in the form of long text, logs, code, etc.; generating summaries, tags, sensitivity levels, and confidence scores for the segmented semantic fragments; retrieving similar memories and detecting conflicts within the same access permission domain; determining whether a conflict has occurred; if a conflict has occurred, performing de-weighting, merging, expiration, or pending confirmation processing on historical similar memories; if no conflict has occurred, writing the memory data and its metadata into a structured database; subsequently, determining whether the device is in a charging or low-load state based on its status; if it is in a charging or low-load state, establishing entity relationships and updating the graph index, generating and updating the vector index, and completing vectorization processing; otherwise, only saving the state to be vectorized, and delaying the semantic feature extraction task to be executed asynchronously during the device's idle period. Through this process, memory writing, structured processing, conflict resolution, and vectorized scheduling form a complete closed loop. High-computing operations such as vectorization are limited to execution when the device is idle or charging, thereby ensuring that the memory data is stored in the database in a timely manner while reducing the real-time power consumption on the device side.

[0107] In this embodiment, the unified memory management service has multiple optional deployment modes.

[0108] In one alternative implementation, the unified memory management service is deployed in the system service process of the terminal operating system, such as the system_server process of the Android system. As a core system service, it runs with the system startup, has system-level permissions, a stable lifecycle, and strong permission control capabilities.

[0109] In another optional implementation, the unified memory management service is deployed as a privileged application with system permissions, i.e., a privileged app. This privileged app carries the Binder service and provides memory management capabilities externally. This approach requires no modification to the core system framework code, resulting in lower development and verification costs, making it suitable for rapid deployment and scenario verification. Both deployment models can effectively achieve a unified memory interaction entry point; the choice can be made based on device type, system customization depth, and version maintenance costs.

[0110] The unified memory management service receives memory interaction requests through the Binder / AIDL interface. The calling process and the process where the service resides communicate across processes via Binder, and requests for memory writing, recall, updating, and deletion are passed using structured parameters defined by AIDL.

[0111] In one alternative implementation, a dedicated API for managing the long-term memory of edge-side agents can be added to the Framework layer, such as interface classes like AgentMemoryManager, MemoryRecord, MemoryWriteRequest, MemoryRecallRequest, and MemoryAccessPolicy. After the application layer initializes the management object through the system's standard service acquisition method, it calls interfaces such as remember(), recall(), forget(), and updatePolicy() to complete the entire lifecycle interaction of the memory.

[0112] Optionally, the AIDL interface can also define memory enumeration interfaces such as listMemories, which are used to enumerate memory data in batches according to query conditions.

[0113] The AIDL standardized interface definition corresponding to this embodiment is as follows:

[0114] interface IAgentMemoryService {

[0115] long remember(in MemoryWriteRequest request);

[0116] List <memoryrecord>recall(in MemoryRecallRequest request);

[0117] boolean forget(long memoryId);

[0118] boolean updatePolicy(in MemoryPolicy policy);

[0119] List <memoryrecord>listMemories(in MemoryQuery query);

[0120] };

[0121] The `MemoryWriteRequest` request structure can include the caller's identity, user ID, agent ID, memory type, original memory content, business metadata, data access level, sensitivity level, write policy, and access control policy. The `MemoryRecallRequest` request structure can include the search query text, current task type, maximum number of returned records, memory type filtering conditions, maximum allowed sensitivity level, and whether mandatory de-identification is required. Through the unified encapsulation of the Framework layer API, third-party applications, system applications, and agent applications do not need to implement their own underlying storage and permission logic; they can complete memory interactions simply by calling standardized interfaces.

[0122] To control which callers can invoke the unified memory management service, the system authenticates callers through at least one of the following permission control methods: system signature permissions, privileged permissions, system application whitelist, application role permissions, and device policies.

[0123] In one alternative implementation, the system can define exclusive permissions.

[0124] Ordinary third-party applications only have access to write public memory and read their own private memory. System agents can access user-authorized shared memory and de-identified shared memory. System management applications have the capabilities to clean up memory, migrate data, and configure policies. Through hierarchical permission control, the system implements the principle of least privilege, preventing unauthorized access and unauthorized tampering from the entry point level.

[0125] Specifically, data access levels include at least the public level, application privacy level, agent privacy level, user-authorized sharing level, de-identified sharing level, and system level.

[0126] Among them, the public level indicates that the memory data is qualified to be shared across applications and agents under authorized conditions; the application privacy level indicates that the memory data is only accessible to the application it belongs to; the agent privacy level indicates that the memory data is only accessible to the agent it belongs to; the user-authorized sharing level indicates that the memory data can only be accessed across applications after user authorization; the anonymized sharing level indicates that external callers can only view the summary, tags, or anonymized results; and the system level indicates that the memory data is only accessible to system services or system agents.

[0127] The data access level is declared by the caller when writing, and the unified memory management service uses this to bind basic access rules to the memory data.

[0128] It should be noted that the public level is not unconditionally open, but rather indicates that the stored data is qualified to be shared across entities under authorized conditions; in actual recall, the caller's identity verification, system signature permission or privilege permission verification, user ID and project / tenant ID verification, data sensitivity level verification, and access policy verification are still required, and audit records are retained.

[0129] When a memory interaction request is a memory retrieval request, the unified memory management service implements differentiated access control according to the data access level. If the data access level is public, authorized callers who meet the preset query conditions are allowed to retrieve memory data; if the data access level is application private or agent private, only callers belonging to that access permission domain are allowed to access memory data; if the data access level is user-authorized sharing, only user-authorized callers are allowed to access memory data within the authorized scope; if the data access level is de-identified sharing, the memory data is de-identified before being returned; if the data access level is system level, only system services or system agents are allowed to access memory data.

[0130] The preset query conditions can include at least one of the following: caller identity verification, signature permission or privileged permission verification, user ID and project / tenant ID verification, data sensitivity level verification, and access policy verification. Through this access control differentiated by data access level, a clear boundary is established between public data, private data, authorized shared data, anonymized shared data, and system-level data, avoiding the risks of insufficient sharing or leakage caused by a one-size-fits-all approach of opening or closing data.

[0131] Specifically, access permission domains include at least one of the following basic permission domains: private memory domain, application memory domain, agent memory domain, public sharing domain, user sharing domain, de-identified sharing domain, and system memory domain.

[0132] Among them, the private memory domain is only accessible to specific ownership entities; the application memory domain is bound to the application UID, package name, or application signature; the agent memory domain is bound to the agent identifier; the public shared domain is used to store public memories that are accessible across applications and agents within the scope of system authorization; the user shared domain is bound to the user ID and user authorization scope; the de-identified shared domain is only allowed to return summaries, tags, or de-identification results; and the system memory domain is only accessible to system services, system agents, or entities with system-level permissions.

[0133] There is a correspondence between data access levels and basic permission domains, as detailed below:

[0134] The public level defaults to the public shared domain, the application private level defaults to the application memory domain, the agent private level defaults to the agent memory domain, the user authorized sharing level defaults to the user shared domain, the de-identified sharing level defaults to the de-identified shared domain, and the system level defaults to the system memory domain.

[0135] It should be noted that the data access level determines the sharing nature and return format of the memory data, while the access permission domain determines the ownership scope and access boundary of the memory data. A piece of memory data can have one data access level and one or more access permission domain attributes at the same time.

[0136] In addition, the access permission domain is also bound to a project identifier or tenant identifier, which serves as an organizational isolation attribute superimposed on the basic access permission domain. Authorized callers within the same project or tenant access memory data according to data access levels, while memory data between different projects or different tenants is isolated from each other.

[0137] For example, in the R&D scenarios of in-vehicle terminals or industrial display equipment, a fault repair memory can be simultaneously bound to the project ID, product model, software version, tenant ID, and debugging agent ID, thereby restricting the memory to be recalled and used only within the corresponding project or tenant scope; cross-project or cross-tenant access requires additional authorization. Through the superimposed isolation at the project or tenant level, the system can prevent the leakage of fault experience or sensitive configurations across projects in an environment with multiple projects, multiple customers, and multiple product lines.

[0138] For user-authorized shared memory data, the system performs authorization verification during both the write and recall phases.

[0139] During the write phase, the system verifies whether the caller is qualified to share the claim and whether the user has authorized it, and determines the authorized object, authorization period, authorization scope, and whether access to the original content is allowed. If the caller has not yet obtained user authorization, the system can refuse to write, downgrade the memory data to the caller's private data, or save it in a pending authorization state, prohibiting other callers from accessing it until authorization is completed. During the recall phase, even if the memory data has been authorized by the user during writing, the system still re-verifies the current system user ID, caller UID, application package name, agent ID, current user authorization status, authorization period, and authorization scope to ensure that the authorization is still valid at the time of recall.

[0140] To ensure the revocability and traceability of user authorizations, the system assigns an authorization version identifier to each user authorization. This identifier is updated each time an authorization is added, modified, or revoked. The recall cache carries the authorization version identifier; if the authorization version identifier in the recall cache differs from the current authorization version identifier, the recall cache becomes invalid and its use is prohibited. After a user revokes an authorization, the system invalidates the caches within the scope of the unified memory management service and reclaims external copies through revocation notifications or data reclamation interfaces. This authorization version mechanism ensures that authorization revocation is immediately reflected in the generated recall results, preventing the continued use of historical caches after authorization revocation.

[0141] Specifically, when performing semantic segmentation on memory data, different segmentation methods are selected based on the content and form of the memory data.

[0142] In one alternative implementation, the dialogue content is segmented according to topic rounds, so that each semantic segment corresponds to a complete topic unit.

[0143] In another alternative implementation, the system log is segmented according to time windows and fault keywords, so that each semantic segment corresponds to a log interval with independent meaning.

[0144] In another alternative implementation, the device debugging process or code change record is segmented according to the task chain, and the complete task process is broken down into problem phenomenon segment, log segment, code path segment, root cause analysis segment, solution segment and verification result segment.

[0145] The segmentation methods described above are merely examples. Alternative methods include fixed-length sliding window segmentation, keyword-based rule-based segmentation, or semantic segmentation based on embedding models. The choice depends on the text type, device computing power, and semantic integrity requirements. Semantic segmentation breaks down long text data into multiple independent semantic segments, avoiding the problem of difficulty in accurately matching entire long texts during retrieval.

[0146] After segmentation, the unified memory management service generates summary information, classification labels, sensitivity levels, and confidence levels for each semantic segment, and binds semantic segments with related relationships to the same task identifier.

[0147] For example, multiple segments generated by a single equipment debugging task can be uniformly bound to the same task identifier to form a complete task memory link; during subsequent recall, as long as any one of the segments is hit, other segments of the same task can be associated along the task identifier.

[0148] Furthermore, the system performs structured processing on the memory data, generating standardized metadata for each memory data point. This metadata includes at least a memory summary, classification label, memory type, sensitivity level, initial confidence level, effective duration, and source evidence.

[0149] Among them, memory type is used to distinguish different categories such as user preference memory, error repair memory, and task process memory; sensitivity level is used for subsequent de-identification return and recall ranking; initial confidence level is used to characterize the credibility of memory data at the time of writing; validity period is used to support time decay and expiration marking; source evidence is used to trace the source of memory data. The generation of summaries, tags, and metadata can be achieved by means of local small model structuring, rule engine combined with keyword extraction, or cloud large model structuring, etc.

[0150] In this embodiment, by replacing the crude direct storage of original dialogues, logs, and task texts with structured metadata, the system significantly reduces storage resource consumption and provides standardized data support for subsequent permission filtering, conflict detection, recall sorting, and timeliness management.

[0151] Specifically, in terms of storage, the memory data adopts a hybrid storage structure of structured database, vector index, and relational graph. The structured database is used to store memory metadata, access permission domains, and audit records; the vector index is used to store the semantic features of semantic fragments and support semantic nearest neighbor retrieval; and the relational graph is used to store the associations between users, applications, devices, tasks, file paths, error types, and solutions.

[0152] In one optional implementation, the structured database is implemented using SQLite and can include core data tables such as a memory master table, a memory fragment table, a memory permission table, an audit table, and a vector reference table. These tables store core metadata, fragment information, permission domains and access policies, operation audit records, and the relationships between fragments and vector indexes. In small-scale data scenarios on the client side, the vector index stores semantic features in BLOB format in SQLite and achieves lightweight retrieval through cosine similarity calculation. In medium-to-large-scale scenarios, it uses near-nearest neighbor indexes such as HNSW, Faiss, or Annoy to achieve efficient retrieval. The relationship graph is implemented using SQLite node tables and edge tables in lightweight scenarios, and multi-hop association retrieval is achieved using in-memory graph indexes or lightweight graph databases in complex scenarios. Graph nodes can include users, terminal devices, hardware modules, applications, fault types, configuration files, solutions, and task records, while edge relationships can include occurrence, modification, resolution, dependency, and association with the same task. Through hierarchical hybrid storage, the structured database handles permission filtering and basic screening, the vector index handles semantic similarity retrieval, and the relation graph handles association-based extended retrieval. The three work together to balance data security on the device side, semantic retrieval accuracy, and computational resource consumption.

[0153] Semantic feature extraction tasks can be performed using a lightweight embedding model on the client side.

[0154] In one alternative implementation, a lightweight edge embedding model accelerated by TFLite, NNAPI, or a vendor's NPU is used to generate vector features for semantic fragments. The data does not leave the device, ensuring high privacy and security, and is suitable for in-vehicle offline scenarios.

[0155] In another alternative implementation, provided there is network access and user authorization, vector features can also be generated by a cloud-based embedding service. During model upgrades, incremental vector reconstruction is performed only on frequently used or affected segments, avoiding the high power consumption and latency associated with full recalculation.

[0156] Specifically, the operating status of the equipment includes at least one of the following: equipment load status, equipment power status, and equipment temperature status.

[0157] When dynamically scheduling the execution of semantic feature extraction tasks, if the running status meets the preset high load condition, preset low power condition, or preset high temperature condition, the semantic feature extraction tasks are executed with a delay or asynchronously; if the running status meets the preset idle condition or preset charging condition, the semantic feature extraction tasks are executed in batches.

[0158] In one optional implementation, the system can classify the device into multiple states, including normal, restricted, low-power, and background optimization. In the normal state, for example, when the battery level is above 30%, the temperature is below 40°C, and the load is below 60%, structured, vector, and graph retrieval are allowed. In the restricted state, for example, when the battery level is between 15% and 30%, the temperature is between 40°C and 45°C, and the load is between 60% and 80%, graph expansion is restricted while lightweight vector retrieval is retained. In the low-power state, for example, when any critical resource parameter exceeds a severe threshold or multiple resource parameters simultaneously exceed a restricted threshold, only structured queries, keyword, and tag retrieval are performed. In the background optimization state, for example, when the device is charging, screen off, under low load, and at a normal temperature, vectorization, graph updates, and summary merging are performed in batches. These thresholds can be configured or dynamically adjusted based on the device model, battery health, charging status, chip temperature, CPU / NPU model and computing power, foreground task priority, whether the user is in real-time interactive mode, system temperature control strategy, and the estimated computational load of the currently remembered task.

[0159] For example, the low battery threshold can be set to 20% or 15%, the severe low battery threshold to 10%, the device temperature threshold to 45°C to 50°C, the high temperature protection threshold to 50°C to 55°C, the CPU high load threshold to 70% to 80%, the NPU high load threshold to 70% to 85%, and the CPU / NPU low load threshold to 30% to 40%.

[0160] It should be noted that the above values ​​are only optional embodiments and not the only fixed conditions. The system can also use multi-level thresholds instead of a single switch threshold, and set normal, restricted, low power consumption and background optimization levels according to the resource status, and configure different memory writing, vectorization and recall strategies for different levels.

[0161] When dynamically adjusting the memory retrieval strategy, lightweight recall is performed using structured query, keyword matching, or tag matching strategies when the operating status meets preset high load, low battery, or high temperature conditions. Deep semantic recall is performed using semantic vector retrieval and / or relational graph expansion strategies when the operating status meets preset idle or charging conditions. Since lightweight recall relies solely on structured database index queries and text matching, its computational overhead is far lower than vector retrieval and graph expansion. Therefore, basic recall can be completed with lower power consumption when device resources are limited. Deep semantic recall, performed when the device is idle or charging, can fully utilize edge computing power to improve recall accuracy. By switching retrieval strategies according to device operating status, the system avoids the impact of high-computing operations on foreground tasks in low battery, high temperature, or high load scenarios.

[0162] Furthermore, memory retrieval strategies include multi-stage retrieval mechanisms.

[0163] In the first stage, a structured screening is performed based on access permission domains, memory types, time ranges, or sensitivity levels to obtain a set of candidate memories. The structured database is then used to perform permission filtering, type filtering, time filtering, and sensitivity level filtering to reduce the number of candidates entering vector retrieval and graph retrieval.

[0164] In the second stage, semantic vector retrieval is performed on the candidate memory set.

[0165] In the third stage, multi-hop association expansion retrieval is performed through the relationship graph to recall related devices, faults, configurations, solutions, and other extended memories. In the fourth stage, the recall results are ranked based on semantic similarity, memory confidence, timeliness, graph relationship distance, and energy consumption. Through a multi-stage retrieval mechanism of first structured coarse screening, then vector fine-tuning, then graph expansion, and finally multi-dimensional ranking, the system avoids the high computational overhead of full vector retrieval, significantly reducing the number of candidates entering vector retrieval and graph expansion, thereby saving edge computing resources while ensuring recall accuracy.

[0166] In one alternative implementation, recall ranking can incorporate multi-dimensional weighting factors, using the following scoring formula:

[0167] Score=α×SemanticSimilarity+β×KeywordMatch+γ×Confidence+δ×Freshness+ε×SourceTrust-ζ×SensitivePenalty-η×EnergyCostPenalty;

[0168] Wherein, SemanticSimilarity represents semantic similarity, KeywordMatch represents keyword matching degree, Confidence represents memory confidence, Freshness represents memory timeliness, SourceTrust represents source credibility, SensitivePenalty represents sensitivity level penalty, EnergyCostPenalty represents energy consumption penalty, and α, β, γ, δ, ε, ζ, and η are the weights of the corresponding factors.

[0169] The system dynamically adjusts its weighting strategy based on device status: in scenarios with low battery, high temperature, or high foreground load, it increases the weight of energy consumption penalty, disables high-overhead vector retrieval and graph expansion, and retains only keywords, tags, and structured retrieval; when the device is idle, charging, or screen-off, it reduces the weight of energy consumption penalty, enables full semantic retrieval and graph association retrieval, and improves recall accuracy.

[0170] Furthermore, when writing new memory data, the system searches for similar historical memories within the same access permission domain or fusion permission domain. If a content conflict is detected between the new memory data and the similar historical memories, the system performs de-weighting, merging, expiration marking, or pending confirmation processing on the similar historical memories based on time information, source information, or confidence assessment indicators.

[0171] It should be noted that the aforementioned mergeable permission domains refer to permission domains that have an inclusion relationship or are authorized to be accessed together. For example, the application memory domain and the public shared domain constitute mergeable permission domains after obtaining user authorization.

[0172] In addition, the system comprehensively considers factors such as the update time of new and old memories, the credibility of the memory source, the user's confirmation status, the actual execution results of related tasks, the confidence level of new and old memories, the validity period of the memory, whether new and old memories belong to the same fact, and whether new and old memories are complementary or contradictory. It can execute one of the processing methods or combine multiple processing methods.

[0173] For example, when the old and new memories belong to the same fact and their contents are complementary, the two memories are merged into one and their respective source evidence is retained; when the source of the new memory is more credible or has been confirmed by the user, the new memory is retained and the confidence of the old memory is reduced; when the old memory has expired or has been confirmed to be replaced, the old memory is marked as expired but not physically deleted in order to retain historical traceability information; when both the old and new memories have high confidence and it is impossible to determine which one is valid, the two are marked as conflicting and awaiting confirmation, and subsequent confirmation is carried out by the user, system intelligent agent or business rules.

[0174] Furthermore, the system updates the confidence level of relevant memory data in response to task execution results. For example, when the solution corresponding to a memory is verified as effective by subsequent tasks, its confidence level is increased; otherwise, its confidence level is decreased. Through rule-based conflict detection and resolution, and confidence feedback updates based on task results, erroneous memories, expired memories, and contradictory memories can be promptly downgraded or marked, while highly reliable memories can be continuously reinforced, reducing their misleading influence on the agent's decision-making.

[0175] Furthermore, when the caller's access permissions do not meet the original content access conditions, or the data access level is the de-identified sharing level, the system performs summary processing or de-identification processing on the memory data and returns it, and generates an operation audit record for the memory interaction request.

[0176] For example, when a caller only has access to a de-identified shared domain, the system does not return the original memory content, but only a summary and tag for that memory. For instance, a memory containing a user's private address might be replaced with a message stating, "There is a highly sensitive user information memory; access to the original text is currently prohibited." Simultaneously, the caller, time, request type, and return format of this access are written into the audit log. Through de-identified returns and audit logging, memory data is reusable while minimizing the exposure of sensitive information.

[0177] For access control policy updates, the system employs a versioning management mechanism. In response to an access control policy update request, the system retains the original access control policy, generates a new version, and sets the new version as the current valid policy. The stored data only updates the associated currently valid access control policy; the stored data itself does not need to be regenerated or copied due to the access control policy update. Audit logs are appended and not overwritten or modified. Each access control policy update records at least the operation time, caller UID, application package name, agent ID, original access control policy, new access control policy, reason for the access change, change in access scope, whether shared data is involved, whether cache invalidation is triggered, and the operation execution result. Because historical policies are fully preserved, any access control change can be traced back to the policy content and reason for the change, thus ensuring traceability while avoiding storage redundancy.

[0178] Furthermore, the system can also sense Android / AOSP system lifecycle events and link them to memory management. In response to the detection of multi-user switching, application uninstallation, user authorization revocation, system upgrade or factory reset events, the system performs permission domain refresh, data cleanup, permission domain reset, memory migration or invalidation marking on the memory data associated with the event.

[0179] For example, when a user switches system users, the system refreshes the scope of accessible permission domains; when an application is uninstalled, the system cleans up the memory data associated with that application or migrates it to the recycle bin; when a user revokes authorization, the system resets the permission domains and updates the authorized version for the corresponding shared memory; when the system is upgraded via OTA, the system performs compatibility checks and invalidation markers on the affected memory. By sensing system lifecycle events and linking them with memory management, long-term memory maintains consistent permission isolation and data validity in multi-user, multi-application, and multi-version environments.

[0180] The following example, a device debugging scenario, illustrates the process of multi-hop association extension recall based on relationship graphs.

[0181] In vehicle terminals or industrial display equipment, edge-side intelligent agents can assist R&D and maintenance engineers in troubleshooting equipment failures, system debugging, and problem review. After a single debugging task is completed, the intelligent agent automatically writes the fault phenomenon, root cause, code path, solution, and verification results into a long-term memory system, forming a reusable equipment debugging experience library. For example, in an equipment debugging scenario, after the equipment debugging intelligent agent completes the fault repair of a near-field communication module scanning anomaly, it generates a standardized long-term memory: the memory type is error repair memory, the summary is that the near-field communication module may be unable to continue scanning after continuous existence detection due to the RF transmission mute configuration item being triggered, the associated path is the configuration file of the near-field communication module, the solution is to invalidate the RF transmission mute configuration item or add a reliable unmute process, the tags are near-field communication, existence detection, mute configuration, the confidence level is 0.9, the permission domain is the intelligent agent memory domain, and the project identifier and tenant identifier are superimposed, and the source evidence is the debugging log and code modification record. This memory entry is simultaneously bound to the project ID, product model, software version, hardware platform, device batch, and debugging agent ID, thus restricting its use to the corresponding project or tenant. If maintenance personnel or agents encounter similar issues later, and enter vague queries such as "cannot scan after a few seconds of card placement," the query text may not directly contain precise keywords such as configuration parameters or file names. The system first retrieves the "cannot continue scanning" fault memory fragment using semantic vectors, and then uses multi-hop expansion of the relationship graph to retrieve associated hardware modules, configuration parameters, log keywords, and repair solutions, providing a complete fault location and repair chain. This significantly shortens the device fault troubleshooting cycle and enables the on-device accumulation and reuse of debugging experience.

[0182] Please refer to Figure 5 Based on the above embodiments, this invention also discloses a memory management system for edge-side intelligent agents, applied to an edge-side operating system, including a unified memory management service deployed on the system side of the edge-side operating system, comprising: a request processing module, a permission isolation module, a segmented processing module, and a dynamic scheduling module.

[0183] The request processing module is used to respond to the caller's memory interaction request for the memory data, and to obtain the caller's identity and the data access level corresponding to the memory data.

[0184] The permission isolation module is used to assign access permission domains to memory data based on the caller's identity and data access level, and to perform permission verification on memory interaction requests based on the access permission domains;

[0185] The segmentation processing module is used to perform semantic segmentation processing on the memory data during the memory data writing phase or when the device is idle, to obtain multiple semantic segments.

[0186] The dynamic scheduling module is used to dynamically schedule the execution timing of semantic feature extraction tasks for semantic segments based on the device's operating status, and to dynamically adjust the memory retrieval strategy for memory data.

[0187] Furthermore, the unified memory management service also includes functional modules such as an identity recognition module, a data level declaration module, an access control module, a public data publishing module, a conflict detection module, a hierarchical storage module, a structured processing module, a recall and sorting module, a de-identification module, an auditing module, a low-power scheduling module, and a lifecycle management module. These modules are used to parse the caller's identity identifier, receive the data access level declared by the caller, perform access control based on access permission domains, include public-level memory data into a globally shared candidate set, retrieve historical similar memories within the same access permission domain and perform conflict resolution, store memory data in a hybrid structure of structured database, vector index, and relational graph, generate metadata for memory data, perform multi-dimensional sorting of recall results, perform summary processing or de-identification processing on memory data, record write, read, delete, permission change, and cross-application access operation logs for memory data, dynamically schedule high-computing tasks based on device operating status, and perform permission domain refresh, data cleanup, migration, or invalidation marking on memory data in response to system events.

[0188] The above modules work together to enable the unified memory management service to fully support the entire process of memory writing, permission domain allocation, structured processing, hierarchical storage, semantic retrieval, de-identification return, low-power scheduling, and audit traceability.

[0189] Please refer to Figure 6 Based on the above embodiments, this invention also discloses a memory management system for edge-side intelligent agents, applied to a caller in an edge-side operating system. The caller can be an application, system intelligent agent, third-party intelligent agent, or system service running on a terminal device. The memory management system on the caller side is deployed within the process of the caller, and is located in a different process from the unified memory management service on the service side. The two communicate across processes via the Binder / AIDL interface.

[0190] The memory management system on the calling side includes a request generation module, a sending module, a receiving module, and a processing module.

[0191] The request generation module is used to generate a memory write request, which carries the caller's identity and the data access level declared for the memory data, as well as a memory recall request.

[0192] The data access level is declared by the caller when writing the memory data, and it is used to indicate the scope of the memory data that is allowed to be shared and the form of the content returned when it is shared.

[0193] In one optional implementation, the request generation module can generate structured requests based on the framework layer APIs provided by the unified memory management service. For example, it can generate memory write requests via the `remember()` interface of `AgentMemoryManager`, memory recall requests via the `recall()` interface, memory deletion requests via the `forget()` interface, and access permission policy update requests via the `updatePolicy()` interface. The request structure can use `MemoryWriteRequest`, `MemoryRecallRequest`, etc., and its fields correspond to the interface definitions on the unified memory management service side. The request generation module encapsulates the caller's identity and data access level within the request, enabling the service side to parse out information on who is accessing the data and who is allowed access when receiving the request.

[0194] Specifically, the sending module is used to send memory write requests and memory recall requests to the unified memory management service in the end-side operating system.

[0195] In one alternative implementation, the sending module passes the request with structured parameters to the process where the service resides via the Binder / AIDL interface, thus completing the cross-process call.

[0196] The receiving module receives the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. This recall result includes the original memory content, anonymized content, or summarized content. When the caller has the conditions to access the original content and the memory data does not belong to the anonymized sharing level, the receiving module receives the original memory content; when the caller lacks sufficient permissions or the data access level of the memory data is the anonymized sharing level, the receiving module only receives the anonymized content or summarized content.

[0197] The processing module is configured to perform task processing based on the recall results. For example, when the caller is an intelligent agent application, the processing module can use the recalled memory data as context input to the task decision-making process, assisting in completing tasks such as system control, application operation, information query, device debugging, or in-vehicle interaction.

[0198] In one optional implementation, the memory management system on the caller side may further include a declaration configuration module and a local caching module. The declaration configuration module receives the caller's declaration of data access levels before generating a memory write request and writes this declaration into the memory write request, allowing the caller to flexibly specify the memory data as public, application private, agent private, user-authorized shared, de-identified shared, or system-level during writing. The local caching module caches the recall results carrying the authorized version identifier and verifies whether the cached authorized version matches the current authorized version before using the cache. If they do not match, continued use is prohibited to prevent the continued use of historical caches after authorization revocation.

[0199] By collaborating between the caller-side memory management system and the server-side unified memory management service, the entire process of memory writing, retrieval, updating, and deletion can be completed in a closed loop within a cross-process scenario: the caller is responsible for declaring data access levels, initiating requests, and receiving return results, while the server is responsible for permission domain allocation, permission verification, segmented processing, retrieval scheduling, and anonymized return. The caller does not need to maintain its own memory repository or implement cross-application access control logic, thus achieving decoupling of memory management at the system level.

[0200] This invention also discloses an electronic device, including at least one processor and a memory communicatively connected to the at least one processor; the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the memory management method of the edge intelligent agent according to any of the above embodiments. This electronic device can be an in-vehicle display terminal, a smart cockpit host, an industrial intelligent terminal, or other edge devices running the Android / AOSP system.

[0201] This invention also discloses a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the memory management method of the edge-side intelligent agent described in any of the above embodiments. The computer-readable storage medium may include non-volatile storage media such as read-only memory, random access memory, magnetic disk, or optical disk.

[0202] The above are merely optional embodiments of the present invention and are not intended to limit the present invention. 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.

[0203] Finally, it should be noted that although the above embodiments have been described in the description and drawings of the embodiments of this invention, this should not be construed as limiting the scope of protection of the embodiments of this invention. Any technical solutions resulting from equivalent structural or procedural substitutions or modifications made based on the essential concepts of the embodiments of this invention, utilizing the content described in the description and drawings of the embodiments of this invention, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of protection of the embodiments of this invention.< / memoryrecord> < / memoryrecord>

Claims

1. A memory management method for edge-side intelligent agents, applied to a unified memory management service in an edge-side operating system, characterized in that, include: In response to receiving a memory interaction request from a caller for memory data, the system obtains the caller's identity identifier and the data access level corresponding to the memory data, wherein the data access level is declared by the caller when writing the memory data; Based on the caller's identity and the data access level, an access permission domain is assigned to the memory data, and permission verification is performed on the memory interaction request based on the access permission domain; During the memory data writing phase or when the device is idle, semantic segmentation processing is performed on the memory data to obtain multiple semantic segments; Based on the operating status of the device, the execution timing of the semantic feature extraction task for the semantic segment is dynamically scheduled, and the memory retrieval strategy for the memory data is dynamically adjusted.

2. The memory management method for edge-side intelligent agents according to claim 1, characterized in that, The data access levels include at least the public level, application privacy level, agent privacy level, user-authorized sharing level, de-identified sharing level, and system level; The step of performing permission verification on the memory interaction request based on the access permission domain includes: When the memory interaction request is a memory retrieval request: If the data access level is public, authorized callers who meet the preset query conditions are allowed to recall the memory data; If the data access level is application privacy level or agent privacy level, only the caller belonging to the access permission domain is allowed to access the memory data; If the data access level is the user-authorized sharing level, only user-authorized callers are allowed to access the memory data within the authorized scope; If the data access level is the de-identified sharing level, perform de-identification processing on the memory data and return it; If the data access level is system level, only system services or system agents are allowed to access the memory data.

3. The memory management method for edge-side intelligent agents according to claim 1, characterized in that, The access permission domains include at least one of the following basic access permission domains: private memory domain, application memory domain, agent memory domain, public sharing domain, user sharing domain, de-identified sharing domain, and system memory domain; The access permission domain is also bound to a project identifier or tenant identifier, which serves as an organizational isolation attribute superimposed on the basic access permission domain.

4. The memory management method for an edge-side intelligent agent according to claim 1, characterized in that, The semantic segmentation process performed on the memory data yields multiple semantic segments, including: Based on topic rounds, time windows, and / or task chains, the memory data in long text form is split into multiple independent semantic segments; Generate summary information, classification labels, sensitivity levels, and confidence levels for the semantic segments, and bind related semantic segments to the same task identifier.

5. The memory management method for an edge-side intelligent agent according to claim 1, characterized in that, The operating status of the device includes at least one of the following: device load status, device power status, and device temperature status; The dynamic scheduling of the execution timing of the semantic feature extraction task for the semantic segment includes: When the operating state meets the preset high load condition, preset low power condition, or preset high temperature condition, the semantic feature extraction task is executed with a delay or asynchronously. When the running state meets the preset idle condition or preset charging condition, the semantic feature extraction task is executed in batches. The dynamic adjustment of the memory retrieval strategy for the memory data includes: When the operating state meets the preset high load condition, the preset low power condition, or the preset high temperature condition, a lightweight recall is performed using a structured query, keyword matching, or tag matching strategy. When the operating state meets the preset idle condition or the preset charging condition, a deep semantic recall is performed using a semantic vector retrieval and / or relation graph expansion strategy.

6. The memory management method for an edge-side intelligent agent according to claim 5, characterized in that, The memory retrieval strategy includes: A candidate memory set is obtained by performing structured filtering based on the access permission domain, memory type, time range, or sensitivity level. Semantic vector retrieval is performed on the candidate memory set, and multi-hop association expansion retrieval is performed through the relation graph; The recall results are ranked by combining semantic similarity, memory confidence, timeliness, graph relationship distance, and energy cost.

7. The memory management method for an edge-side intelligent agent according to claim 1, characterized in that, The method further includes: When writing new memory data, retrieve similar historical memories within the same access permission domain or fusionable access permission domain; If a content conflict is detected between the new memory data and the historical similar memory, the historical similar memory will be subject to downweighting, merging, expiration marking, or pending confirmation processing based on time information, source information, or confidence assessment indicators. In response to the task execution result, update the confidence level of the relevant memory data.

8. The memory management method for an edge-side intelligent agent according to claim 1, characterized in that, The method further includes: When the caller's access permissions do not meet the original content access conditions, or when the data access level is the de-identified sharing level, the memory data is digested or de-identified and returned, and an operation audit record for the memory interaction request is generated.

9. The memory management method for an edge-side intelligent agent according to claim 1, characterized in that, The unified memory management service is deployed in the system service process of the terminal operating system, or deployed as a privileged application with system permissions; The unified memory management service receives the memory interaction request through the Binder / AIDL interface and provides a unified calling interface to the caller through the framework layer API of the terminal operating system. The unified memory management service authenticates the caller through at least one of the following permission control methods: system signature permission, privileged permission, system application whitelist, application role permission, and device policy.

10. A memory management method for a terminal-side intelligent agent, applied to a caller in a terminal-side operating system, characterized in that, include: A memory write request is generated, which carries the identity of the caller and the data access level declared for the memory data, and the memory write request is sent to the unified memory management service in the terminal operating system. Generate a memory retrieval request and send the memory retrieval request to the unified memory management service; The system receives the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. The recall result includes the original memory content, de-identified content, or summary content.

11. A memory management system for edge-side intelligent agents, applied to a unified memory management service in an edge-side operating system, characterized in that, This includes a unified memory management service deployed on the operating system side of the endpoint, the unified memory management service comprising: The request processing module is used to respond to a caller's memory interaction request for memory data, and to obtain the caller's identity identifier and the data access level corresponding to the memory data. The permission isolation module is used to allocate access permission domains to the memory data based on the identity identifier of the caller and the data access level, and to perform permission verification on the memory interaction request based on the access permission domains; The segmentation processing module is used to perform semantic segmentation processing on the memory data during the memory data writing phase or when the device is idle, to obtain multiple semantic segments. The dynamic scheduling module is used to dynamically schedule the execution timing of the semantic feature extraction task for the semantic segment based on the operating status of the device, and to dynamically adjust the memory retrieval strategy for the memory data.

12. A memory management system for a terminal-side intelligent agent, applied to a caller in a terminal-side operating system, characterized in that, include: The request generation module is used to generate a memory write request, which carries the identity identifier of the caller and the data access level declared for the memory data, as well as generate a memory recall request; The sending module is used to send the memory write request and the memory recall request to the unified memory management service in the terminal operating system; The receiving module is used to receive the recall result returned by the unified memory management service after performing permission verification based on the access permission domain corresponding to the data access level. The recall result includes the original memory content, de-identified content, or summary content. The processing module is configured to perform task processing based on the recall results.

13. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 11.

Images