Intelligent agent session data compression and loading method, computer device and storage medium

Abstract

This invention provides a method, computer device, and storage medium for compressing and loading intelligent agent session data. The method includes acquiring intelligent agent session events; parsing the session events into structured memory units and writing them into a replayable session event ledger; determining a set of degradable objects and their compression boundaries; compressing the session data corresponding to the degradable objects; if a received session request requires loading compressed target session data, generating a loading plan based on the ledger index, performing an access check on the data source; if the check passes, loading the memory fragment of the target session data into the context of the current session; if the check fails, rereading the corresponding original session event from the replayable session event ledger; and performing a recycling process on the loaded memory fragment when the session data compression processing conditions are met. This invention also provides a computer device and storage medium for implementing the above method. This invention can accurately read back historical session events.

Description

Technical Field

[0001] This invention relates to the field of intelligent agent data processing, and in particular to artificial intelligence technology. Specifically, it relates to a method for compressing and loading intelligent agent session data, as well as a computer device and a computer-readable storage medium for implementing this method. Background Technology

[0002] With the development of intelligent and digital technologies, artificial intelligence technology has been widely applied. Currently, intelligent agents can be applied in various scenarios such as code development, debugging and troubleshooting, document writing, and verification tasks. As users continuously interact with the intelligent agent, the agent's activity context continuously accumulates user constraints, tool results, model judgments, user corrections, and unfinished tasks. If the intelligent agent were to continuously stitch together the entire conversation history, it would consume a large amount of resources. However, since the intelligent agent's context budget is very limited, the intelligent agent usually compresses the historical conversation data and generates summaries or vector data from the historical conversation events. The corresponding summary or vector data is only retrieved when these historical conversation events are needed.

[0003] However, if all historical session events are compressed and stored as summaries or vector data, information such as source basis, dependencies, effective states, and task stages can easily be lost during retrieval. Therefore, long-link agents need a context memory management mechanism that can compress activity context occupancy and support historical state replay, verification, and on-demand recovery.

[0004] Some existing intelligent agents employ context compression and history filtering schemes. Through methods such as encoding or decoding by the large language model itself, attention value filtering, topic relevance calculation, semantic compression, vector similarity, or historical question-and-answer matching, they filter, compress, or reassemble text fragments relevant to the current request from long contexts or historical dialogues to reduce input length and maintain the continuity of multi-turn dialogues. A typical approach is to standardize multi-source heterogeneous data into context field objects with state tags and store them. When trigger conditions are met, the completed historical context is compressed into a structured summary. Then, a candidate set is formed from the active context and the summary context to perform dynamic pruning. This is combined with task routing and result aggregation to achieve multi-agent dialogue processing.

[0005] Other agents employ dialogue memory preservation and memory book update schemes. These schemes typically focus on the generation, preservation, retrieval, conflict detection, updating, deletion, and cross-session use of dialogue content or user information. For example, they may convert dialogue content into memory data, maintain the user's memory book, or call upon long-term memory in subsequent interactions to improve the continuity of responses.

[0006] Some agents employ hierarchical, hot / cold, or vector memory management schemes. These typically organize memory according to the hotness or coldness of the conversation, vector indexing, episodic memory, semantic memory, short-term memory, long-term memory, or working memory. They also incorporate context-aware retrieval, relevance scoring, or memory optimization mechanisms to provide agents or large language models with long-term information management capabilities. A typical approach involves receiving user commands to invoke the target agent within a unified dialogue interface, querying published agent information from a vector library and matching it to the target agent, obtaining the user-inputted target operation information and current context information, and then sending this information to the target agent for analysis and result display.

[0007] Existing solutions address the memory problem of long dialogues or agents from various angles, including context compression, historical filtering, dialogue memory preservation, memory book updates, and hierarchical memory management. However, these solutions remain at the level of text compression, memory entry maintenance, or memory storage and retrieval, and mainly suffer from the following problems: First, existing context compression, history filtering, or dialogue memory solutions mostly process text, summaries, vectors, or memory entries, lacking structured representation at the session event level, as well as source mapping between original session events, structured fields, derived summaries, and external text, making it difficult to replay, review, and regenerate historical states.

[0008] Second, even if existing hot and cold tiering or vector memory schemes have threshold migration, access popularity migration, or long-term memory optimization mechanisms, they are mainly oriented towards storage tiers, access popularity, or vector data correlation. They lack compressed boundary records, non-degradable object determination, recovery handle management, and load admission verification driven by a unified replayable session event ledger. It is difficult to explain which historical events have been structured and which content must still be retained in high-fidelity form.

[0009] Third, existing external memory or vector memory schemes mostly rely on semantic similarity, topic matching, or memory item retrieval, lacking on-demand loading mechanisms based on entity keys, dependency references, valid states, source mapping, and budget margins. They also lack consistency verification before loading and recycling and degradation processing mechanisms after use. Summary of the Invention

[0010] The first objective of this invention is to provide a method for compressing and loading intelligent agent session data that can accurately load historical session data.

[0011] A second objective of the present invention is to provide a computer device for implementing the above-described method for compressing and loading intelligent agent session data.

[0012] A third objective of this invention is to provide a storage medium for implementing the above-described method for compressing and loading intelligent agent session data.

[0013] To achieve the first objective of this invention, the intelligent agent session data compression and loading method provided by this invention includes the following steps performed by a processor: acquiring intelligent agent session events, parsing the session events into structured memory units, and writing them into a replayable session event ledger, generating a ledger index for the replayable session event ledger; determining the set of degradable objects in the session events and determining their compression boundaries, and compressing the session data corresponding to the degradable objects; if the received session request requires loading the compressed target session data, generating a loading plan based on the ledger index, and performing an admission verification of the data source; if the verification passes, loading the memory fragment of the target session data into the context of the current session; if the verification fails, rereading the corresponding original session event from the replayable session event ledger; when the session data compression processing conditions are met, recording the reference result of the session data, and performing recycling, degradation, or external loading processing on the loaded memory fragments, wherein the external loading processing is to move the loaded memory fragments back to external memory.

[0014] As can be seen from the above scheme, the present invention can parse session events such as user input, model output, tool calls, tool results, user corrections, and task status changes into structured memory units and write them into a replayable session event ledger. When retrieving historical session events later, key historical session events can be replayed based on event identifiers, source ranges, and version identifiers, rather than relying solely on natural language-generated summaries to search for historical session events, thus enabling more accurate replay of historical session events.

[0015] Furthermore, this invention requires identifying degradeable objects and thereby determining non-degradeable objects, so that the latest user constraints, incomplete items, referenced tool results, current decision basis, and user corrections can be preferentially retained, reducing the risk of critical states being covered by ordinary summaries.

[0016] A preferred approach is to write the structured memory units into the replayable session event ledger and then establish a source mapping relationship between the original session events, structured fields, derived summaries, and external text; when generating the load plan, the load plan is generated based on the ledger index and the source mapping relationship.

[0017] As can be seen, this invention establishes a correspondence between original session events and structured fields, derived summaries, and external text by establishing a source mapping relationship. When a loading plan needs to be generated subsequently, the source mapping relationship can quickly locate the structured memory unit, thereby improving the efficiency of session data loading.

[0018] A preferred approach is to determine the set of degradable objects in a session event, and also determine the set of non-degradable objects: non-degradable objects are determined based on at least one of the following: valid state of session data, dependent references, user corrections, unfinished items, and current decision criteria.

[0019] Therefore, it can be seen that the present invention determines non-degradable objects based on multiple indicators, which can effectively reduce the risk of critical states being covered by ordinary summary information.

[0020] A further approach is to compress the session data corresponding to the degradeable object, including: generating summary information for the degradeable object, which includes at least one of the following: the source range of the degradeable object, the overriding event identifier, the version identifier, the failure condition, and the recovery handle.

[0021] Because the summary object contains the overridden event identifier, source range, version identifier, and recovery handle, it can identify which historical session events have been structurally overridden. Furthermore, it can reread the original session event chain or regenerate a derived summary when the summary becomes invalid, conflicts occur, or versions are inconsistent. Moreover, the summary information generated by the degradeable object contains multiple parameters. When loading session data from the degradeable object, these parameters can be used to accurately load the corresponding session data, improving the accuracy of historical session data loading.

[0022] A further approach is to persist the source information of the original session after generating the summary information of the degradable object. The persistence process includes writing the source information into the persistence layer. When reading the original session event back from the replayable session event ledger, the original session event to be read back is obtained based on the source information recorded in the persistence layer.

[0023] Therefore, storing traceability information in an external persistent layer can achieve long-term preservation of traceability data. When it is necessary to read back the original session event, the traceability information can be obtained from the external persistent layer to obtain the original session event, thus achieving rapid retrieval of the original session event.

[0024] A further approach is to include at least one of the following in the source information of the original session: the original session event chain of the degradeable object, the tool result text, and the version snapshot.

[0025] Therefore, by recording the source information of the original session, accurate basic information can be provided for subsequent retrieval of the original session events, thus enabling the original session to be found quickly and accurately.

[0026] A further approach is to trigger session data compression processing under the following conditions: based on activity context budget, task phase, user explicit instruction, context object failure condition, or external resource constraint.

[0027] Therefore, when any of the above conditions are met, the session data compression process will be triggered to prevent the agent from accumulating a large amount of session data and reduce the amount of context accumulated in the agent.

[0028] A further proposed approach is to include at least one of the following in the loading plan: a description of the candidate event set, corresponding entity keys and dependency references, source fragments, summary objects, external text recovery handles, loading granularity, loading order, pre-loading verification items, and processing paths after verification failures.

[0029] Therefore, when determining the loading plan, it is necessary to determine several things, such as the set of candidate events, the corresponding entity keys, and the dependency references, and to determine the final loading operation based on these things, so as to make the loading operation more standardized.

[0030] A further approach involves determining the compression boundaries of degradable objects by: reading event dependencies, valid states, source coverage, version states, user correction states, and task phases from the replayable session event ledger; identifying historical events covered by structured memories, derived summaries, or external text; identifying historical events that must be retained in the activity context or active structure layer; and recording the covered event scope, covered event identifier, version identifier, source scope, and recovery path compression boundaries to determine the compression boundaries of degradable objects.

[0031] Therefore, the above steps can accurately determine the compression boundary range of degradable objects, avoiding the situation where the range is too large, which would result in the compression of data that should not be compressed, and also avoiding the situation where the range is too small, which would result in the compressed data failing to fully reflect the whole picture of historical session events.

[0032] A further proposed approach is to include at least one of the following in the admission verification: source verification, version matching verification, field coverage verification, dependency chain integrity verification, constraint conflict verification, and failure condition verification.

[0033] Therefore, the above admission verification can ensure the accuracy of historical session event data loaded into the context of the current session.

[0034] To achieve the second objective described above, the computer device provided by the present invention includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the various steps of the above-described intelligent agent session data compression and loading method.

[0035] To achieve the third objective mentioned above, the storage medium provided by the present invention stores a computer program, which, when executed by a processor, implements the various steps of the above-mentioned intelligent agent session data compression and loading method. Attached Figure Description

[0036] Figure 1 This is a framework diagram of a system applying the intelligent agent session data compression and loading method of the present invention.

[0037] Figure 2 This is a flowchart of an embodiment of the intelligent agent session data compression and loading method of the present invention.

[0038] Figure 3 This is a diagram showing the relationship between the event chain, structured memory unit, source mapping relationship, and recovery handle in an embodiment of the intelligent agent session data compression and loading method of the present invention.

[0039] Figure 4 This is an illustration of the processing of degradeable and non-degradeable objects based on a replayable session event ledger in an embodiment of the intelligent agent session data compression and loading method of the present invention.

[0040] The present invention will be further described below with reference to the accompanying drawings and embodiments. Detailed Implementation

[0041] The intelligent agent session data compression and loading method of the present invention is applied to intelligent agents, particularly to realize the compression and subsequent loading of historical session events by intelligent agents. The method of the present invention can be implemented on a computer device having a processor and a memory, the memory being a readable storage medium of the present invention, on which a computer program is stored, and which, when executed by the processor, performs the various steps of the aforementioned intelligent agent session data compression and loading method.

[0042] Example of a method for compressing and loading intelligent agent session data: This embodiment implements context memory compression and on-demand loading of agent session data based on a replayable session event ledger. It establishes a replayable session event ledger and source mapping relationship, and determines degradeable objects, non-degradeable objects, and recovery handles based on ledger fields, thereby determining the compression boundary of degradeable objects. When historical session events need to be loaded later, an on-demand loading plan is generated based on the ledger index. Admission verification is performed before loading, and the session data of historical session events is recycled after use, forming a closed-loop process of ledger recording, compression boundary, non-degradeable protection, recovery handle, loading plan, admission verification, and post-use recycling.

[0043] See Figure 1The system applying the intelligent agent session data compression and loading method of this embodiment involves an input side 10, a session event ledger control module 20, an output side 30, and a post-processing module 40. The input side 10 mainly includes data input to the session event ledger control module 20, including user / model events 11, tool calls / results 12, corrections / task states 13, etc. The session event ledger control module 20 is used to compress and replay session events based on the input data. It manages the replayable session event ledger 21 and source mapping relationship 22, and can set compression boundary strategies 23 for degradeable objects. When historical session data needs to be used, it can generate a loading plan 24. The compression triggering module 25 triggers the compression operation when session data compression is required, such as recycling, downgrading, or externally loading the relevant data after using the relevant data of historical session events. The output side 30 stores the compressed session event data externally based on the processing result of the session event ledger control module 20, and loads the corresponding historical session events when needed. This mainly involves the management of the activity context 31, the structured memory unit 32, and the external persistence layer 33. After the memory segment being read back is used up, the post-processing module 40 performs operations such as recycling, downgrading, or external loading on the memory segment. In this embodiment, the external loading process involves moving the loaded memory segment back to the external storage.

[0044] This embodiment can write user input data, model output data, tool calls and tool output results, user corrections, and task state changes during agent sessions into a replayable session event ledger 21. This transforms historical session events from simply compressed summaries or searchable text into an event chain that serves as the basis for compression, external loading, loading, verification, and retrieval control. The replayable session event ledger 21 generates compression and loading control decisions based on the event identifier, entity key, dependency references, source scope, validity status, and version identifier of the session events. Therefore, the activity context budget, task stage, and current request can serve as prior conditions for triggering session data compression, rather than solely determining the core rules for memory migration.

[0045] This embodiment can be implemented by a computing device, which includes a processor and a memory. The processor executes a computer program stored in the memory, causing the computing device to perform... Figure 2 The individual steps are shown. See also... Figure 2 The present invention first executes step S11 to obtain the conversation events of the agent. The obtained conversation events include user input data, agent responses, tools called by the agent, and analysis results of the called tools, etc.

[0046] Then, step S12 is executed to parse the session events into structured memory units and write the structured memory units sequentially into the replayable session event ledger in chronological order, and then generate a ledger index. When generating the ledger index, the session identifier or event identifier, event type, and storage path corresponding to each structured memory unit in the replayable session event ledger are recorded. When it is necessary to load or read back the data of the structured memory unit later, the storage path corresponding to the structured memory unit can be obtained through the session identifier or event identifier, and then the data of the structured memory unit can be read according to the storage path.

[0047] In this embodiment, a replayable session event ledger is established for each session event. Since each session event includes at least user input, model output, tool call, tool result, user correction, and task status change data, in step S12, the above data is parsed into structured memory units and written into the replayable session event ledger in the order of event occurrence.

[0048] See Figure 3 The agent's session events can form an event chain 41, which includes user constraints 411, tool constraints 412, and user corrections 413. Through parsing the session events, the structured memory unit 32 contains constraint memory 321 and result memory 322. The information types that each structured memory unit 32 needs to express include at least session identifier, round identifier, event identifier, event type, entity key, dependency reference, source range, validity state, persistent location information, and version identifier. Within the structured memory unit 32, the above information types are represented by the fields session_id, turn_id, event_id, event_type, entity_key, dependency_ref, source_span, validity_state, persist_path, and version_id, respectively. The above field names are not a closed fixed list; as long as compression, recovery, verification, and playback are supported, the field names can be flexibly adjusted. Among them, the event identifier is the unique identifier of the session event, the entity key is used to represent the task object, file path, interface name, constraint subject or to-do item involved in the structured memory unit 32, the dependency reference is used to record the previous event, tool result or decision basis of the memory dependency, the source range is used to point to the text range, tool output result range or event fragment in the original session event, the valid state is used to represent the state of the session event, such as the state can be valid, corrected, conflicted, expired or invalid, the persistent location information is used to locate the external persistent text or snapshot, and the version identifier is used to distinguish the versions of the same entity at different stages.

[0049] Next, step S13 is executed to establish the source mapping relationship between the original session event, structured fields, derived summary, and external text, and to record the overriding event identifier and recovery handle. In this embodiment, the system maintains a structured session memory control file under the session persistence path for unified management of source mapping and external persistence index. The replayable session event ledger maintains the correspondence between the original session event content, structured fields, derived summary, and external text through source mapping relationship 22, see [link to relevant documentation]. Figure 3 The source mapping relationship 22 includes at least the following key elements: event range 431, overlay identifier 432, version identifier 433, and source fragment 434. The recovery handle 44 is used to quickly point to the relevant fragment, external text 442, or version snapshot 443 of the original session event 441 when it is necessary to read back the original session event. The logical structure of the recovery handle 44 includes source fragment location, external persistent location, version identifier, and failure condition. The source fragment location mainly points to the original session event range, the external persistent location points to the external storage location of the session event, the version identifier is used for version consistency verification, and the failure condition is used to determine whether the summary information of the session event is still valid.

[0050] When rereading historical session events later, if the summary object becomes invalid, conflicts, or the versions are inconsistent, this embodiment can still obtain the event chain 41 of the session event based on the source mapping relationship 22, and can reread the external text 442 or regenerate the derived summary, thereby avoiding relying solely on natural language summaries or semantic similarity to determine whether a memory segment is related to the session event, thus improving the accuracy of historical session loading.

[0051] Next, step S14 is executed to determine the set of non-degradable objects based on valid status, dependency references, user corrections, outstanding items, and current decision criteria, thereby determining the set of degradable objects. See also Figure 4In this embodiment, the ledger control plane 51 is used to identify and manage non-degradable objects 53 and degradable objects 54. The ledger control plane 51 records data such as event dependencies, validity status, source coverage, version status, user correction, and task stage of session events. In step S14, after reading the data such as event dependencies, validity status, source coverage, version status, user correction status, and task stage, it is determined which historical session events have been covered by structured memory, derived digests, or external text, and which historical session events must still be retained in the activity context or active structure layer. Historical session events that have been covered by structured memory, derived digests, or external text can be identified as degradable objects, and the set of these degradable objects constitutes the degradable object set. Historical session events that must still be retained in the activity context or active structure layer are identified as non-degradable objects, and the set of these non-degradable objects constitutes the non-degradable object set. Specifically, non-degradable objects include the latest user constraints, incomplete tasks, tool results referenced by subsequent messages, current decision bases, memory items with conflict risks, and recently modified flags, etc. These objects are not downgraded to low-fidelity summary information due to budget pressure alone, unless explicitly confirmed by the user, the dependency is removed, or its validity status has changed to invalid. Otherwise, all of the above objects are identified as non-degradable objects 53. Non-degradable objects 53 are not compressed, thus forming the active / active retained data 55 in the context. Through this mechanism, key constraints, tool results, and user modifications in session events can be preferentially retained in the activity context or active structure layer.

[0052] Then, step S15 is executed. For degradable objects that do not belong to the non-degradable object set and have been covered by the ledger source mapping, the compression boundary of the degradable object set is determined based on the replayable session event ledger, and session data compression processing is performed. Specifically, summary information is generated for the corresponding session data of the degradable objects. The compression boundary of the degradable object set is used to record the scope, overriding event identifier, version identifier, source scope, failure condition, and recovery handle of the historical session events that have been covered. The above content is synchronously written into the summary information to form summary and recovery data 56, which is written to the external persistent layer 33. When it is necessary to read back the data of historical session events later, the original historical scope of the historical session event can be quickly determined by obtaining the summary information. Among them, the recovery handle is used to locate the scope, external text, tool result snapshot, or retrieval index of the original session event later, and can recover content with higher fidelity than the summary information when needed.

[0053] Furthermore, step S15 also persists the source information of the original session, that is, writes the source information to an external persistence layer. The source information of the original session event includes at least one of the following: the original session event chain of the degradable object, the tool result text, and the version snapshot. During persistence, the original event chain, tool result text, historical text, or version snapshot is written to the external persistence layer 33. This embodiment maintains a control file for the structured memory unit through a session persistence path. This session persistence path represents the persistent storage space corresponding to each session event. The persistent storage space is used to store the structured session memory control file for that session event, as well as data such as the original event fragments, external text, and version snapshots related to that session event. The structured session memory control file maintains source mapping relationships and an external persistence index. The source mapping relationships are recorded in a source mapping relationship table, which records the correspondence between structured memory, summary information, and original session event fragments. The external persistence index records the location information of the external text, tool result snapshot, or version snapshot. The recovery handle is the core output of the source mapping table, used at the implementation layer to quickly locate the original session event, external text, or version snapshot via external persistent indexes. By associating the recovery handle with the source fragment location or the external persistent path (persist_path), the system can simultaneously locate the original session event range and the external persistent storage location when needed.

[0054] Furthermore, the structured session memory control file includes a session metadata area, an active memory area, a confirmed decision area, a critical constraint area, an incomplete item area, a compressed summary area, an external persistent index area, a loading strategy area, and a verification record area. The session metadata area records the session identifier, project identifier, model or tool environment, ledger version, and last update time. The active memory area records memory units that still need to directly participate in reasoning in the current context. The confirmed decision area records decisions confirmed by the user or task status and their source events. The critical constraint area records the latest user constraints, format requirements, security boundaries, and non-violation conditions. The incomplete item area records unfinished tasks, blocking items, and next-step dependencies. The active memory area, critical constraint area, and incomplete item area together output a set of non-degradable objects. The compressed summary area stores derived summaries or preview objects generated from degradable objects; the external persistent index area stores location information and recovery handles for external text, original session event fragments, tool result snapshots, or version snapshots; the loading strategy area outputs candidate loading plans and can record entity hits, dependency hits, task phases, activity context capacity constraints, or other loading triggering conditions; the verification record area records status information such as admission, rejection, failure, regeneration, source hash, version matching, field coverage, dependency chain integrity, and conflict checking. Budget conditions can be retained in the loading strategy area; their function is to trigger compressed boundary assessments or limit loading capacity, and they are not used for determining degradable and non-degradable objects.

[0055] Thus, when a historical session event needs to be read back later, the source mapping table or external persistent index in the structured session memory control file is first read, and the corresponding source fragment or external persistent path is obtained based on the recovery handle. The source fragment is used to locate the original event scope, the external persistent index is used to locate the external text, tool result snapshot, or version snapshot, and the recovery handle is used to associate the memory object to be recovered with the location information, thereby supporting subsequent recovery and location. Therefore, the structured session memory control file is not a free-form natural language summary, but a memory carrier driven by the session event ledger control module 20.

[0056] Then, step S16 is executed to determine whether a new session request has been received and whether the session request needs to load compressed target session data. The target session data is the session data that the current session request needs to load; therefore, the target session data is the compressed session data from the session data corresponding to historical session events. If the current session request needs to load the target session data, a loading plan is generated based on the ledger index. For example, in subsequent sessions, if a new session request hits an entity, constraint, tool result, incomplete item, or dependency reference, it is considered that the session request needs to load compressed target session data. In this case, instead of directly retrieving the corresponding historical session event and adding the retrieval result to the activity context, a loading plan is first generated based on the replayable session event ledger and source mapping relationship. The loading plan generated in this embodiment includes at least one of the following: a description of the candidate event set, corresponding entity keys and dependency references, source fragments, a summary object, an external text recovery handle, loading granularity, loading order, pre-loading verification items, and a processing path after verification failure. During the retrieval process, semantic similarity, keyword matching, or vector recall are used as candidate ranking methods, but they do not replace ledger indexing, dependency referencing, and admission verification. Ledger indexing, dependency referencing, and admission verification still have their own functions.

[0057] Then, step S17 is executed to perform data source access verification on the retrieved data. This access verification includes at least one of the following: source verification, version matching verification, field coverage verification, dependency chain integrity verification, constraint conflict verification, and failure condition verification. If the data source verification passes, step S18 is executed to load the memory fragments of the relevant session data into the context of the current session. For example, a memory preview object is generated for memory fragments loaded on demand. This memory preview object at least includes summary information, source range, recovery handle, entity key, dependency reference, version identifier, and loading conditions. The memory preview object is used to describe the readable range and recovery method of the external memory in the activity context. If the verification fails, step S19 is executed to read back the corresponding original session events from the replayable session event ledger. For example, information such as the original session event chain is obtained based on the tracing information recorded in the persistence layer, thereby obtaining the original session events to be read back. Furthermore, data that fails verification needs to be marked, and summary information is regenerated for the corresponding historical session events. If the original session events cannot be read back, loading the session data that failed verification is rejected.

[0058] Finally, in step S20, the compression triggering module 25 determines whether the current conditions meet the conditions for session data compression processing. If so, it performs session data recycling processing. Preferably, the conditions for triggering data compression processing can be at least one of the following: triggered by the activity context budget, triggered by the task phase, triggered by an explicit user instruction, triggered by the context object expiration condition, or triggered by external resource constraints. For example, after loading the memory fragment in step S18, if the current task is completed, the expiration condition is met, or the activity context capacity is limited again, it is considered that the conditions for session data compression processing have been triggered. At this time, it is necessary to record the reference result of this loading, and the external memory can be downgraded back to summary information or migrated back to the external persistent layer, thereby forming a closed loop of loading, use, and recycling.

[0059] As can be seen, when the activity context approaches the budget limit, data compression will be automatically triggered. The compression boundary needs to be evaluated to determine the appropriate range for data compression. When the budget drops or the current request requires relevant historical data, the corresponding memory segments can be loaded on demand. Preferably, when the budget is within a preset hysteresis range, repeated compression or recovery operations are delayed to reduce state fluctuations in the critical range.

[0060] The following example illustrates this embodiment using a tool call in an agent session that produces a relatively long tool result. Assuming the tool result is a code scan result, simulation log, or document comparison result, after writing the tool call and tool result into the replayable session event ledger, the event identifier, entity key, dependency reference, source scope, validity status, and version identifier are also recorded. Simultaneously, the source mapping records the correspondence between the original event fragment, structured fields, possible generated summary objects, and external text.

[0061] Subsequently, when the task phase changes or the activity context capacity is limited, the compression boundary assessment will be triggered. Specifically, it will first check whether the tool result is still directly dependent on the current unfinished items, the latest user constraints, or the current decision basis. If the tool result is a non-degradable object, it will continue to be retained in the activity context or active structure layer. If the tool result is not a non-degradable object and has been covered by structured fields and source mapping, a summary object or preview object will be generated, and the source range, coverage event identifier, version identifier, failure condition, and recovery handle will be recorded. At the same time, the full text of the tool result or a version snapshot will be loaded to the external persistence layer.

[0062] When subsequent requests hit the same entity key, dependency reference, unfinished item, or critical constraint again, a load plan needs to be generated based on the ledger index. This load plan determines the set of candidate events to be restored, the necessary source fragments, the restoration handle, the load granularity, and the load order, and lists the source, version, field overriding, dependency chain, constraint conflict, and failure condition checks that need to be performed before loading.

[0063] Finally, the external text or original event fragment is read back based on the recovery handle, and an admission check is performed. If the check passes, only the tool result fragments, summary descriptions, or source descriptions required by the current task are loaded into the context of the current session. If the check fails, the original event chain is read back, the old summary is marked as invalid, a derived summary is regenerated, or the loading of conflicting memories is rejected. When the current task is completed or the invalidation condition is met, the reference result of this memory loading is recorded, and it is downgraded back to summary information or migrated to the external persistence layer. Therefore, this embodiment, through the above end-to-end process, can complete the compression, recovery, verification, and recycling of session data for session events based on the ledger control plane 51 of session events.

[0064] In design applications, the present invention can also be implemented in other ways. For example, the fields of the structured memory unit can be expanded according to the task type to file path, interface name, test number, patent chapter number, log timestamp, tool call parameters or user confirmation mark, as long as event identifier, entity key, dependency reference, valid status, source location, version identifier and recovery location capability are still retained.

[0065] Additionally, the replayable session event ledger can be implemented using Markdown, JSON Lines, SQLite, append-only event streams, object storage indexes, dependency graphs, state machine tables, or other persistence formats, as long as it maintains the source mapping between original session events, structured fields, derived digests, external body, overriding event identifiers, and version snapshots. The external persistence layer can be a local file system, a project-level cache directory, a database, object storage, or a retrieval index.

[0066] Recovery handles can point to the original message range, tool result snapshot, external text, structured memory unit, summary object, object storage path, or retrieval index. Source verification can use hashes, signatures, checksums, version vectors, event sequence numbers, overriding event identifiers, or combinations thereof. Field coverage verification can be performed by field list, structured schema, dependency graph, or task state machine; constraint conflict verification can be performed by combining the latest user constraints, system policies, and task phase status.

[0067] Furthermore, compression triggers can be initiated by the activity context budget, task phase, explicit user instructions, context object failure conditions, or external resource constraints. High and low thresholds can be configured based on model window limits, task type, tool result size, or user policies, and can apply to the total activity context budget, tool result budget, historical summary budget, or output reserved budget, respectively. However, their role is to trigger or delay the evaluation timing of the ledger control plane, and they do not replace compression boundaries and non-degradable object determinations.

[0068] This invention parses user input, model output, tool calls, tool output results, user corrections, and task state changes into structured memory units and writes them into a replayable session event ledger. When it is necessary to read back historical session events later, key historical session events can be replayed based on event identifiers, source ranges, and version identifiers, rather than relying solely on natural language summaries for recall, which can improve the accuracy of historical session event replay.

[0069] Because the summary information includes the event identifier, source range, version identifier, and recovery handle, it is possible to quickly determine which historical session events have been structured overwritten, and to reread the original event chain or regenerate the derived summary when the summary is invalid, conflicting, or inconsistent with the version.

[0070] Since this invention identifies non-degradable objects based on ledger status, the latest user constraints, incomplete items, results of referenced tools, current decision-making basis, and user corrections are all identified as non-degradable objects and can be preferentially retained, reducing the risk of critical statuses being covered by ordinary summaries.

[0071] Because this invention generates a loading plan based on the ledger index and performs admission checks on source, version, field coverage, dependency chain, constraint conflict, and failure conditions before external memory enters the active context, it can reduce the situation where expired or conflicting memories are re-injected into the context.

[0072] Since external memory loads memory fragments according to entity keys, dependency references, valid states, source mappings, and recovery handles, semantic similarity is only used as an auxiliary sorting factor, thus enabling more stable recovery of memory fragments that are truly dependent on the current task.

[0073] Finally, because the memory segments loaded on demand record reference results and are reclaimed, downgraded, or migrated back to external memory when the task is completed, the failure condition is met, or the active context capacity is limited again, forming a closed loop of memory lifecycle governance, this invention can prevent external memory segments from occupying the active context for a long time once they are restored. High and low threshold hysteresis can be used as an operational stability strategy to reduce repeated compression and restoration in critical intervals.

[0074] Computer device embodiment: The computer device in this embodiment can be various types of computer devices, such as desktop computers, laptops, data processing servers, etc. The computer device has a processor, a memory, and a computer program stored in the memory and executable on the processor, such as an information processing program for implementing the above-described information processing method. When the processor executes the computer program, it implements each step of the above-described intelligent agent session data compression and loading method.

[0075] For example, a computer program can be divided into one or more modules, one or more of which are stored in memory and executed by a processor to complete the various modules of the present invention. One or more modules can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in a terminal device.

[0076] The processor referred to in this invention can be a Central Processing Unit (CPU). A general-purpose processor can be a microprocessor or any conventional processor, etc. The processor is the control center of the terminal device, connecting various parts of the terminal device through various interfaces and lines.

[0077] Memory can be used to store computer programs and / or modules. The processor implements various functions of the terminal device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital cards (SD cards), flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0078] Storage medium examples: If a computer program stored in a computer device is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the various steps of the above-described intelligent agent session data compression and loading method.

[0079] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc. It should be noted that the content contained in computer-readable media can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction.

[0080] Finally, it should be emphasized that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for compressing and loading intelligent agent session data, characterized in that, This includes the following steps performed by the processor: Acquire intelligent agent conversation events, parse the conversation events into structured memory units, write them into a replayable conversation event ledger, and generate the ledger index of the replayable conversation event ledger; Determine the set of degradable objects in the session event and determine the compression boundary of the degradable objects, and compress the session data corresponding to the degradable objects; If the received session request requires loading compressed target session data, a loading plan is generated based on the ledger index, and an admission verification of the data source is performed. If the verification passes, the memory fragment of the target session data is loaded into the context of the current session. If the verification fails, the original session event is read back from the replayable session event ledger; When the session data compression processing conditions are met, the session data citation results are recorded, and the loaded memory segments are recycled, downgraded, or externalized.

2. The method for compressing and loading intelligent agent session data according to claim 1, characterized in that: After writing the structured memory unit into the replayable session event ledger, a source mapping relationship is also established between the original session event, structured fields, derived summary and external text; When generating the loading plan, the loading plan is generated based on the ledger index and the source mapping relationship.

3. The method for compressing and loading intelligent agent session data according to claim 1 or 2, characterized in that: When determining the set of degradable objects in the session event, a set of non-degradable objects is also determined: non-degradable objects are determined based on at least one of the following: valid state of the session data, dependency references, user corrections, unfinished items, and current decision criteria.

4. The method for compressing and loading intelligent agent session data according to claim 1 or 2, characterized in that, Also includes: Compression of the session data corresponding to the degradeable object includes: generating summary information for the degradeable object, the summary information including at least one of the following: the source range of the degradeable object, the overwrite event identifier, the version identifier, the failure condition, and the recovery handle.

5. The method for compressing and loading intelligent agent session data according to claim 1 or 2, characterized in that: After generating the summary information of the degradeable object, the source information of the original session is also persisted. The persistence process includes writing the source information into the persistence layer. When reading back an original session event from the replayable session event ledger, the original session event to be read back is obtained based on the tracing information recorded in the persistent layer.

6. The method for compressing and loading intelligent agent session data according to claim 5, characterized in that: The source information of the original session includes at least one of the following: the original session event chain of the degradeable object, the tool result text, and the version snapshot.

7. The method for compressing and loading intelligent agent session data according to claim 1 or 2, characterized in that: Conditions that trigger session data compression processing include: triggering based on activity context budget, triggering based on task phase, triggering based on explicit user instructions, triggering based on context object failure conditions, or triggering based on external resource constraints.

8. The method for compressing and loading intelligent agent session data according to claim 1 or 2, characterized in that: Determining the compression boundary of a degradable object includes: reading the event dependencies, valid status, source coverage, version status, user correction status, and task stage from the replayable session event ledger; identifying historical events that have been covered by structured memories, derived summaries, or external text; identifying historical events that must be retained in the activity context or active structure layer; and recording the covered event range, covered event identifier, version identifier, source range, and recovery path compression boundary to determine the compression boundary of the degradable object.

9. A computer device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the various steps of the intelligent agent session data compression and loading method as described in any one of claims 1 to 8.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the various steps of the intelligent agent session data compression and loading method as described in any one of claims 1 to 8.

Images