A task-oriented agent hierarchical memory management and active intervention method, system, device and storage medium

Abstract

This invention discloses a hierarchical memory management and proactive intervention method and system for task-oriented intelligent agents, relating to the fields of artificial intelligence intelligent agents and computer memory management technology. This invention sets up a memory processing system outside the main intelligent agent executing the task. Based on observable operational evidence and the problem lifecycle status generated during the main intelligent agent's operation, such as task requirements, tool results, errors, current plans, and evaluation results, it decides whether to construct memory, retrieve memory, or remain silent. Working memory and long-term memory are stored hierarchically with different write thresholds. Memory retrieval triggering and final memory injection are separated into independent decision-making processes. Repeated triggering and error closure are suppressed through evidence fingerprints and direct completion evidence. This invention reduces invalid memory retrieval and operational costs, improves the accuracy of memory construction, reduces long-term memory contamination and erroneous intervention, and enhances the stability and delivery quality of long-running intelligent agents.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence agents and computer memory management technology, and in particular to a hierarchical memory management and active intervention method, system, device and storage medium for task-oriented intelligent agents. Background Technology

[0002] When a long-duration intelligent agent performs a multi-step task, it continuously generates task requirements, environmental information, failure records, problem diagnoses, and unfinished items. As the interaction trajectory grows, this decision-related information may gradually be obscured by subsequent content. Although it still exists in the historical context, it cannot continue to influence the agent's behavior during critical decisions. This phenomenon leads to the agent easily forgetting fine-grained constraints, repeating similar failed operations, or lacking direct verification of task requirements when submitting deliverables during long task execution, resulting in delivery defects and decreased execution efficiency.

[0003] A similar approach is found in the paper "Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents" (published on the arXiv preprint platform on July 9, 2026, arXiv:2607.08716). This paper refers to the aforementioned problem as "behavioral state decay" and proposes setting up an independent auxiliary agent outside the main agent. The auxiliary agent maintains a structured memory bank composed of task states, knowledge, and procedural experience based on recent operational trajectories, and determines whether to inject memory-related prompts into the main agent or remain silent. This module does not require modification of the main agent itself and can be integrated into existing agent execution frameworks as an add-on component. This approach demonstrates that "actively choosing the timing of intervention" is superior to always injecting or passively exposing all memories.

[0004] However, the existing solution's memory maintenance and intervention judgment are mainly completed by the auxiliary agent model, which has the following shortcomings: First, memory operations are triggered at fixed intervals. Regardless of whether there are important constraints, failures, verification, or forgetting risks, they will run according to fixed steps, resulting in unnecessary model calls, token consumption, and execution delays. Second, memory maintenance and intervention judgment are coupled. Each trigger usually performs memory maintenance and information intervention judgment simultaneously. Third, there is a lack of clear triggering criteria. Whether to save or inject mainly depends on the auxiliary agent's free judgment of recent trajectories. There is no gating based on specific events such as errors, repeated failures, missing sources, and acceptance gaps, which easily leads to false triggers and missed triggers. Fourth, there is a lack of problem lifecycle management, which cannot continuously differentiate between different issues. The problem is categorized into three levels: newly emerged, awaiting evidence, under repair, or already resolved. Therefore, the same problem may be repeatedly saved, or related memories may be injected even after the problem is resolved. Fifth, conversational and cross-conversational memories are not stratified. Temporary states, local facts, and experiences reusable across tasks lack distinct writing thresholds, making it easy for one-time task information to enter long-term memory and affect subsequent tasks. Unverified experiences may be prematurely saved as procedural experiences. Sixth, retrieval hits and final intervention lack independent gates; finding relevant memories does not necessarily mean that the memory has added value to the current plan. Seventh, memories lack complete evidence tracing; there is a lack of stable correlation between memories and original events, source steps, and subsequent verification results, which is detrimental to deduplication, revision, auditing, and determining whether experiences form a complete closed loop.

[0005] Therefore, those skilled in the art are dedicated to developing a hierarchical memory management and proactive intervention method, system, device, and storage medium for task-oriented intelligent agents that can accurately determine the triggering time of memory construction and memory retrieval based on specific events that occur during the operation of the intelligent agent, decompose the main intelligent agent of memory maintenance, memory retrieval, and intervention into mutually independent decision-making processes, and hierarchically manage working memory and long-term memory. Summary of the Invention

[0006] In view of the above-mentioned deficiencies of the prior art, the technical problem to be solved by the present invention is: how to provide a hierarchical memory management and active intervention mechanism based on runtime event triggering for task agents, under the premise of maintaining the original main agent's execution capabilities and runtime interface unchanged, and ensuring that the main task can continue to execute when the memory module is abnormal, accurately determining the triggering timing of memory construction and memory retrieval, separating memory maintenance, memory retrieval and intervention of the main agent into mutually independent decision-making processes, distinguishing between working memory and long-term memory, preserving reusable experience based on a complete evidence closed loop of "error occurrence - successful verification", and judging the decision value of the retrieved memory in combination with the main agent's current plan, observable evidence and problem status, thereby realizing memory tracking, deduplication, updating and on-demand injection.

[0007] To achieve the above objectives, the first aspect of the present invention provides a hierarchical memory management and active intervention method for task-oriented intelligent agents. The method is applied to a memory processing system set up outside the main intelligent agent performing the task, and includes the following steps:

[0008] S1: Before the main intelligent agent performs the operation for the first time, the task requirement generation unit extracts the task requirements from the task description, constructs the task profile, and writes the current task requirements into the working memory.

[0009] S2: After each step is completed by the main intelligent agent, the running event collection unit collects the running events of the main intelligent agent and saves and processes them according to their source;

[0010] S3: The problem status management unit associates current events with historical problems to form problem evidence, and performs semantic confirmation on events that require semantic judgment, thereby managing the lifecycle status of problems;

[0011] S4: The triggering judgment unit generates a memory construction request or a memory retrieval request based on the problem status;

[0012] S5: When the triggering condition is met, the working memory management unit and the long-term memory management unit retrieve candidate memories from working memory and long-term memory;

[0013] S6: The intervention decision unit compares the candidate memories, current evidence, and the main agent's current plan to decide whether to inject the memory into the main agent or remain silent.

[0014] Preferably, in step S1, deliverables, constraints, prohibitions, and acceptance criteria are extracted from the task description, and the original source and direct verification conditions are retained for each task requirement; wherein, only rules that are clearly applicable to subsequent tasks are used to generate long-term memory candidates with applicable scope.

[0015] Preferably, in step S2, the task description, tool return results, command exit status, error information, the main intelligent agent's analysis of the results, the next step plan, and deliverable information are obtained from the main intelligent agent and saved and processed according to the source of the original task text, tool output, analysis, plan, and evaluation.

[0016] Preferably, in step S3, problem evidence is directly formed for objective events, and problem candidates are first generated for events that require semantic judgment and then semantic confirmation is performed; the confirmed problems are in the life cycle states of observed, awaiting evidence, processable, under repair, verified and resolved or closed in sequence, and the evidence fingerprint is used to determine whether the evidence has changed substantially. If the evidence fingerprint has not changed, it will not be triggered repeatedly due to the increase of steps.

[0017] Preferably, in step S4, explicit and cross-step effective task constraints and facts that have been confirmed and affect subsequent steps are entered into working memory, while temporary states, currently visible outputs and unverified guesses are not constructed into long-term memory; fault recovery experience starts from the first failure and is only constructed into procedural memory when the main agent subsequently adopts a substantially different strategy and confirms through direct results that the strategy has solved the original problem.

[0018] Preferably, in step S5, a memory retrieval request is generated when any of the following triggering conditions are met:

[0019] (1) The current plan contradicts the evidence of failure;

[0020] (2) The main agent fails to repeat the same type of failure;

[0021] (3) Delivery requirements lack direct verification;

[0022] (4) The current results have source and mapping risks;

[0023] Working memory retrieves information from the requirements, state, knowledge, and procedural experience of the current task, while long-term memory generates queries and recalls candidate memories based on the current task, problem evidence, and plan, excluding records generated by the current task itself.

[0024] Preferably, in step S6, when the main agent has not yet identified the error, is preparing a repeated failure strategy, or still lacks direct evidence for the task requirements before submission, relevant memories are selected for injection; when the main agent has already adopted the correct solution and is verifying it, the problem has been solved, or the candidate memories cannot provide new information for the current decision, the agent remains silent.

[0025] Preferably, step S2 is executed by the running event acquisition unit, which obtains task description, tool output, errors, analysis, and plan from the main agent; step S3 is executed by the problem status management unit, which associates the current event with historical problems; step S4 is executed by the trigger judgment unit, which generates a memory construction request or retrieval request based on the problem status, and the memory access operation is executed by the working memory management unit and the long-term memory management unit; step S6 is executed by the intervention decision unit, which decides whether to provide memory to the main agent based on candidate memories and the current plan.

[0026] Preferably, each issue record includes at least an issue identifier, issue type, associated object, lifecycle status, evidence, evidence fingerprint, and attribute to be verified; each memory includes at least a memory type, content, scope of application, source event, source steps, verification evidence, and success criteria.

[0027] Preferably, in step S3, objective events such as non-zero exit status and non-existent file are directly used to form problem evidence; for events such as unreliable source, mapping deviation or insufficient acceptance that require semantic judgment, problem candidates are first generated and then confirmed by rules, classification models or language models. If the confirmation fails or the evidence is insufficient, no problem is created and no memory operation is performed.

[0028] Preferably, in step S3, the evidence fingerprint is generated by standardizing and hashing the key elements of the problem evidence, and is used to identify whether the evidence for the same problem has undergone substantial changes; when the evidence fingerprint of a newly collected event is consistent with the evidence fingerprint of an existing problem record, it is determined that the evidence has not undergone substantial changes, and the memory construction request or retrieval request is not repeatedly generated due to the increase in the number of steps; when the evidence fingerprint changes, the evidence in the problem record is updated and re-enters the corresponding lifecycle state processing.

[0029] Preferably, in step S4, the content of the procedural memory includes failure conditions, invalid strategies, correction strategies, verification actions, success criteria, and scope of application; errors or repair plans alone cannot form this type of procedural memory; after the task is completed, if the reward or evaluation results indicate that the verification method adopted by the main agent cannot prove the actual requirements, then an independent correction memory is constructed, which is formed separately from the runtime fault recovery memory.

[0030] Preferably, the same verified event generates both working memory and long-term memory: the working memory retains the current task object and execution state; the long-term memory deletes the specific task name, file name and temporary environment information, and only retains the reusable triggering conditions, resolution principles, success criteria and scope of application; both share the source event and source step identifier, and the long-term memory is not a direct copy of the working memory.

[0031] Preferably, in step S5, long-term memory is stored in a cross-session database and is not fully loaded into the main agent context when a new task begins. After a long-term memory retrieval is triggered, the system generates a query based on the current task, problem evidence, and plan, recalls similar records, excludes records of the current task itself, and then obtains candidate memories through relevance rearrangement and threshold filtering. The retrieval uses vectors, keywords, knowledge graphs, or a combination of these methods, and the rearrangement uses a dedicated model, rule scoring, or language model scoring.

[0032] Preferably, in step S6, the injected content includes currently observable evidence, a suggested action, and a corresponding success criterion; the main agent's completion declaration, planned checks, file existence, or file openability cannot replace direct completion evidence corresponding to specific task requirements; when multiple search conditions are hit simultaneously, they are judged separately, and duplicate candidates are removed and merged into one injection.

[0033] Preferably, when the maintenance and retrieval conditions are met simultaneously in the same step, the problem status is updated first and memory construction or revision is performed, then candidates are retrieved from the updated memory, and finally it is determined whether to inject; no intervention judgment is performed when only the construction condition is met, and no new memory is constructed when only the retrieval condition is met; neither memory construction nor memory injection itself can prove that the problem is solved, and only subsequent direct verification of the results can close the problem.

[0034] Preferably, the method further includes an exception handling step: when the long-term memory database, vector service, or reordering service fails, the current long-term memory operation fails and is shut down, the main agent continues to execute the task, and the system does not use unreordered candidates as replacement results; startup errors such as missing configuration or mismatched vector dimensions are terminated before the task starts.

[0035] A second aspect of the present invention provides a hierarchical memory management and proactive intervention system for task-oriented intelligent agents, the system being located outside the main intelligent agent performing the task, the system comprising:

[0036] The task requirement generation unit is used to extract task requirements from the task description, construct a task profile, and write the current task requirements into working memory before the main intelligent agent performs the operation for the first time.

[0037] The event acquisition unit is used to collect the running events of the main intelligent agent and save and process them according to their source.

[0038] The problem status management unit is used to associate current events with historical problems to form problem evidence, and to perform semantic confirmation on events that require semantic judgment, thereby managing the lifecycle status of problems.

[0039] The triggering judgment unit is used to generate a memory construction request or a memory retrieval request based on the problem status;

[0040] The working memory management unit is used to manage access to working memory and retrieve candidate memories from working memory when a retrieval is triggered.

[0041] The long-term memory management unit is used to manage the access to long-term memory and retrieve candidate memories from long-term memory when a retrieval is triggered.

[0042] The intervention decision unit is used to compare candidate memories, current evidence, and the main agent's current plan to decide whether to inject the memory into the main agent or remain silent.

[0043] Preferably, the task requirement generation unit extracts deliverables, constraints, prohibitions, and acceptance criteria from the task description, retains the original source and direct verification conditions for each task requirement, and generates long-term memory candidates with applicable scope only for rules that are clearly applicable to subsequent tasks.

[0044] Preferably, the runtime event acquisition unit obtains the task description, tool return results, command exit status, error information, the main intelligent agent's analysis of the results, the next step plan, and deliverable information from the main intelligent agent, and saves and processes them according to the source of the original task text, tool output, analysis, plan, and evaluation.

[0045] Preferably, the problem status management unit directly generates problem evidence for objective events, generates problem candidates for events that require semantic judgment and then performs semantic confirmation, manages the lifecycle status of problems as observed, awaiting evidence, processable, under repair, verified resolved or closed, and judges whether the evidence has changed substantially through evidence fingerprints. If the evidence fingerprint has not changed, it will not be triggered repeatedly due to the increase of steps.

[0046] Preferably, in the triggering judgment unit, clear and effective task constraints across steps and facts that have been confirmed and affect subsequent steps are entered into working memory. Temporary states, currently visible outputs and unverified guesses are not constructed into long-term memory. Fault recovery experience is taken as the starting point of the first failure, and procedural memory is only constructed when the main agent subsequently adopts a substantially different strategy and confirms through direct results that the strategy has solved the original problem.

[0047] Preferably, when the long-term memory management unit is triggered, it generates a query and recalls candidate memories based on the current task, problem evidence, and plan, while excluding records generated by the current task itself.

[0048] Preferably, the intervention decision unit selects relevant memories to inject into the main agent when the main agent has not yet identified the error, is preparing a strategy to repeat the failure, or still lacks direct evidence for the task requirements before submission. When the main agent has adopted the correct solution and is verifying it, the problem has been solved, or the candidate memories cannot provide new information for the current decision, the intervention decision unit remains silent.

[0049] A third aspect of the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the aforementioned hierarchical memory management and active intervention method for task-oriented intelligent agents.

[0050] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned hierarchical memory management and active intervention method for task-oriented intelligent agents.

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

[0052] (1) This invention triggers memory operations based on observable evidence such as errors, verification, sources, and task status, rather than calling the memory model at each step or fixed interval. Therefore, when the main agent is running normally, the current information does not need to be saved, or there is no decision risk, it can remain silent, reducing the number of model calls, input / output token consumption, interface costs, and additional waiting time.

[0053] (2) This invention uses the problem life cycle and evidence changes to determine the timing of memory. Fault experience is only allowed to be saved after a complete closed loop of "original failure, strategy change, and direct verification success" is formed. Unverified guesses, temporary states, and single errors will not directly enter long-term memory. At the same time, working memory and long-term memory adopt different writing conditions and expression methods. Working memory retains the specific objects and progress of the current task, while long-term memory only saves verified, de-tasking experience with a clear scope of application, thereby reducing the impact of erroneous experience and noise information on subsequent tasks and avoiding the propagation of temporary files, current progress, and task-specific information to other tasks.

[0054] (3) The present invention separates the retrieval trigger and memory injection. After the retrieval hits, it is necessary to combine the current plan of the main agent and the problem status to determine whether the candidate memory has new decision value. When the main agent has taken the correct measures, is verifying, or the problem has been solved, the system remains silent. The evidence fingerprint and problem status can also prevent the same evidence from being repeatedly triggered in consecutive steps.

[0055] (4) The system of the present invention converts the delivery requirements into separately trackable task requirements at the start of the task and records the corresponding direct verification conditions; before submission, the completion of the declaration, the existence of the file or the file being open cannot automatically replace the real acceptance evidence, which helps to reduce delivery defects caused by forgetting fine-grained constraints or using incorrect verification methods.

[0056] (5) The long-term memory of the present invention is stored in an independent cross-session storage and is not fully loaded at the start of the task. The system only performs candidate recall, relevance rearrangement and threshold filtering when a retrieval is triggered. It can control the context length and the number of candidates when the long-term memory grows. Working memory and long-term memory are associated through source events, source steps and triggering reasons. The system can trace back why a memory was generated, what evidence it was based on, when it was retrieved and whether it was actually injected. Active triggering, working memory and long-term memory can be enabled separately. When the relevant service fails, the memory operation can be closed without blocking the execution of the main agent, which reduces the risk of modifying existing agents to access active memory capabilities.

[0057] (6) This invention separates memory retrieval triggering and final memory injection into two independent decision-making processes, avoiding unconditional injection after a successful retrieval and preventing erroneous interventions that conflict with the current plan when the main agent has already adopted the correct solution and is in the verification stage; through a repeated triggering suppression mechanism based on the problem lifecycle state and evidence fingerprint, it avoids the same evidence for the same problem from repeatedly triggering memory construction and retrieval operations in multiple consecutive steps, controlling the expansion of memory entries and the increase in the number of model calls with the task duration; through the strict three conditions for procedural memory construction, it prevents speculative solutions without direct result confirmation from entering long-term memory and being retrieved and injected in subsequent tasks, avoiding the solidification of erroneous experience and long-term memory pollution. The above three mechanisms are systematically combined in the three stages of triggering, suppression, and construction to jointly ensure the effectiveness of memory operations and the quality of the long-term memory bank.

[0058] The following will further explain the concept, specific structure, and technical effects of the present invention in conjunction with the accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the overall process of a hierarchical memory management and active intervention method for task-oriented intelligent agents according to a preferred embodiment of the present invention;

[0060] Figure 2 This is a schematic diagram of the memory processing system according to a preferred embodiment of the present invention. Detailed Implementation

[0061] The following description, with reference to the accompanying drawings, illustrates several preferred embodiments of the present invention to make its technical content clearer and easier to understand. The present invention can be embodied in many different forms, and the scope of protection of the present invention is not limited to the embodiments mentioned herein.

[0062] This invention provides an agent-based active memory method based on runtime evidence triggering and hierarchical storage. A memory processing system is set up outside the main agent executing the task. Based on task requirements, tool results, errors, current plans, and evaluation results generated during the main agent's operation, it determines whether to construct memories, retrieve memories, or remain silent. For clarity, the terminology used in this invention is first defined. In this invention, "Working Memory" (WM) refers to the requirements, state, and experience that serve only the current task; "Long-Term Memory" (LTM) refers to memory that, after verification and removal of specific information for the current task, can be retrieved by subsequent tasks; "Memory Injection" refers to adding filtered memories to the main agent's subsequent input; "Evidence Fingerprint" is an identifier generated based on the problem object and evidence, used to determine whether the evidence has undergone substantial change; "Trigger Gate" is a gating mechanism that determines memory operations based on evidence, problem state, and changes in evidence; "Task Profile" records task requirements, source, verification attributes, and success criteria; "Issue Status" represents the lifecycle of a problem from discovery to verification closure; and "Reward Evaluator" is a task reward signal or task evaluator used to determine whether the final result and verification criteria are correct.

[0063] Example 1

[0064] This embodiment provides a hierarchical memory management and proactive intervention method for task-oriented intelligent agents. This method is applied to a memory processing system set up outside the main intelligent agent performing the task, and includes steps S1 to S6. The following provides a detailed description of the method's setup and operation.

[0065] (1) System structure

[0066] like Figure 1 and Figure 2 As shown, the memory processing system includes a task requirement generation unit, a runtime event acquisition unit, a problem status management unit, a trigger judgment unit, a working memory management unit, a long-term memory management unit, and an intervention decision unit. The runtime event acquisition unit obtains task descriptions, tool outputs, errors, analyses, and plans from the main agent; the problem status management unit associates current events with historical problems; the trigger judgment unit generates memory construction requests or retrieval requests based on the problem status; the working memory management unit and the long-term memory management unit perform access operations; and the intervention decision unit decides whether to provide memory to the main agent based on candidate memories and the current plan.

[0067] Each issue record should include at least the issue identifier, issue type, associated objects, lifecycle status, evidence, evidence fingerprint, and attributes to be verified. Each memory should include at least the memory type, content, scope of application, source event, source steps, verification evidence, and success criteria.

[0068] (2) System initialization and implementation environment

[0069] In this implementation, WM (Working Memory) represents the memory used by the current task session; LTM (Long-Term Memory) represents the memory saved and retrieved across tasks; and Trigger Gate represents the trigger gate, used to determine when memory operations are allowed.

[0070] The system is configured with three independent switches: a trigger gating switch, a working memory switch, and a long-term memory switch. When the trigger gating is off, the system runs the original fixed-interval memory process; when the trigger gating is on, the system creates a trigger judgment unit, a problem status management unit, and a session memory controller; when long-term memory is also on, a long-term memory database, a vector generation service, and a relevance rearrangement service are further created. Working memory is established at the beginning of each task and saved or cleared after the task ends, without being loaded into the next unrelated task. Long-term memory is stored in a cross-session database and remains visible in subsequent tasks. This embodiment uses an SQLite database to store long-term memory and uses vector expansion to perform similarity retrieval. Each problem record includes a problem identifier, problem type, associated object, lifecycle state, first occurrence step, most recently updated step, evidence set, evidence fingerprint, and attribute to be verified. Each memory includes a memory identifier, memory type, content, scope of application, source event identifier, source step identifier, verification evidence, and success criteria.

[0071] (3) Step S1: Establish task requirements

[0072] Before the main agent executes its first operation, the memory processing system invokes the task requirement generation unit to convert the natural language task description into structured task requirements. Each task requirement includes at least the requirement content, source fragments from the original task text, attributes to be verified, and acceptance criteria. For example, when a task requires generating a file with a specific format, fields, and visual effects, the system records the format, fields, and visual requirements separately, rather than simply saving a summary of "generated file." The current task requirement is written to working memory. If the task description contains general rules that are clearly applicable to subsequent tasks, a long-term memory profile is generated simultaneously. The long-term memory profile removes the filename, path, and specific object of the current task and expands its scope. The working memory profile and the long-term memory profile share source event identifiers and source step identifiers. The vector generation operation required when writing the long-term memory profile to the database can be performed in parallel with historical long-term memory retrieval to reduce task startup time. This allows task requirements to be checked item by item before the task ends, avoiding the omission of fine-grained constraints in long tasks.

[0073] (4) Step S2: Collect running events

[0074] Each time the main agent completes an operation step, the event acquisition unit obtains the following information: current task description; tool return results and command exit status; main agent's analysis of the results; main agent's next plan; currently generated file or other deliverable information; and rewards and evaluation results after the task is completed. The system saves this information separately according to its source (task text, tool output, analysis, plan, and evaluation) to avoid misinterpreting error descriptions in example text, source code, or historical logs as current problems. The trigger judgment unit extracts structured signals such as failure, success, verification, source, mapping, and completion intent from the current step and generates associated objects. For example, file operation problems use files as associated objects, and command execution problems use standardized commands and error characteristics as associated objects.

[0075] (5) Step S3: Identify the problem and maintain the status

[0076] For objective events such as command exit with a non-zero value, file non-existence, and explicit tool failure, the system directly establishes evidence for the problem. For controversial events such as unreliable sources, mapping bias, insufficient acceptance testing, and unresolved boundaries, the system first generates candidate problems using keywords and structured fields, and then a semantic classifier confirms whether the problem actually exists. The semantic classifier only receives evidence fragments near the candidate problems and outputs whether the candidate problem is valid, the type of problem confirmed, and supporting evidence. If confirmation fails, the output format is incorrect, or supporting evidence cannot be found in the input fragment, the system uses a failure-closing method, neither establishing the problem nor performing related memory operations.

[0077] The confirmed issues are maintained by the status management unit, and are sequentially categorized into observed, awaiting evidence, processable, under repair, verified resolved, or closed states. Identical issues are associated through issue type, related objects, and evidence fingerprints. If the evidence fingerprint remains unchanged, the issue will not be repeatedly triggered with each additional step; when new errors, conflicts, or verification results occur, the status management unit updates the issue revision number and allows for reassessment. This design ensures that keywords are only responsible for discovering candidate events, and that changes in issue status and evidence determine whether to perform a memory operation, thereby reducing fixed-cycle calls and literal word triggering. In this embodiment, the same root can reach the repeated failure trigger condition after two repeated failures; temporary issues can be closed if no new evidence is obtained after two consecutive steps; a single task can retain a maximum of 128 unresolved issues. The above values ​​are configurable parameters and do not constitute a limitation of this invention.

[0078] (6) Step S4: Determine whether to construct a memory

[0079] After the state update is completed, a judgment unit is triggered to check whether the memory construction conditions are met. Constraints that are clearly stated in the original task text and will affect delivery across steps are saved as task requirements; facts that have been directly confirmed by the tool and clearly affect subsequent operations are saved as knowledge in working memory; unverified guesses, currently visible outputs, and one-off states are not saved as long-term memory.

[0080] For fault recovery experience, the system must observe the following complete process: the first strategy fails; the agent adopts a substantially different second strategy; the second strategy is directly verified and resolves the original problem. Once these conditions are met, the system stores procedural memories including failure conditions, invalid strategies, corrective strategies, verification actions, success criteria, and scope of application. If the agent only plans to change strategies, or the new strategy has not yet been verified, this memory is not built. Source protection memories are built when reliable sources are unavailable, and the agent further adopts unverified alternative information that may contaminate the delivery results. Simple network errors or access failures do not build such memories. After the task is completed, if the reward or evaluation results indicate that the verification method used by the agent cannot prove the actual task requirements, the system builds a verification correction memory. For example, the existence or ability to open a file does not prove that its content, format, and visual quality meet the task requirements. This memory is generated by the overall task evaluation and is handled separately from runtime fault recovery.

[0081] Regarding the determination of "substantially different strategies," this embodiment provides two configurable implementation methods. The first is a rule-based judgment based on the comparison of key strategy elements: The system extracts three key elements from the two strategies: command category (e.g., delete, rewrite, append, copy, format conversion), target object (e.g., file path, data table, interface address), and method path (e.g., processing order, tools used, parameter set). When at least one of the command category or method path elements changes, and the changed strategy is not a simple repetition or parameter fine-tuning of the original strategy, it is determined to be a substantially different strategy. For example, if the first strategy, "directly overwrite the target file," fails, and the second strategy is changed to "first write to a temporary file and then atomically rename," the command categories and execution paths of the two strategies are different, thus they are determined to be substantially different. The second strategy, which only changes the number of retries from one to two, is a parameter fine-tuning and is determined to be substantially the same, thus not meeting the conditions for constructing procedural memory. The second approach is semantic determination based on a language model: the descriptive texts of the two strategies are input into the language model, which outputs the degree of semantic difference between the two in terms of intent, means, and execution path. When the degree of semantic difference exceeds a preset threshold, they are judged to be substantially different. Both methods can be used individually, or rule-based judgment can be used first to filter out obviously identical cases, and then the language model can handle boundary cases, thus balancing the certainty and coverage of the judgment.

[0082] (7) Step S4 post-processing: Determine the memory storage level

[0083] For current task requirements, current problem status, and facts within the task, the system only writes to working memory. For fault recovery, protection rules, and evaluation corrections that have formed a closed loop, the system generates long-term memory candidates. The same closed-loop event can simultaneously generate two records: working memory retains the current error object, file, and actual operation; long-term memory deletes this task-specific information, retaining only reusable failure modes, correction principles, verification methods, and scope of application. Both records share the source event identifier and source step identifier.

[0084] This embodiment removes duplicates of the same type and content in working memory. When saving duplicates, the original memory identifier is retained and new source evidence is added. Long-term memory uses append-only writing, without automatically modifying existing records during writing, thus preserving the original chain of evidence. When revising memories, the system first saves the new record containing the new evidence, and then deletes or deactivates the old record to avoid loss of valid memories due to saving failure.

[0085] (8) Step S5: Determine whether to retrieve memory.

[0086] The decision unit generates a retrieval request when the following situations occur: the tool output indicates failure, but the main agent still plans the next step according to the success state; the failure strategy for the same root cause is about to be executed again; a deterministic error feature that can match historical recovery experience appears; high-risk conclusions lack reliable sources; the main agent is ready to submit, but the task requirements still lack direct evidence of completion; the mapping difference between the source data and the target deliverable may still affect the results; there are still unclosed verification items in the submission stage.

[0087] Working memory retrieval selects candidates from the task requirements, problem state, knowledge, and procedural memory of the current task. Long-term memory retrieval generates a query vector based on task profile, triggering evidence, problem type, and current plan, recalls similar memories from the database, and excludes records generated by the current task itself. Long-term memory identifiers already retrieved at the start of the task are added to the cooling-off set of the current session and are not retrieved again until the problem state and evidence change. On-demand retrieval reduces contextual occupancy and irrelevant information interference caused by the growth of long-term memory.

[0088] (9) Step S6: Determine whether to inject after retrieval

[0089] After acquiring candidate memories, the intervention decision unit compares the candidate content, current evidence, and the main agent's plan. A retrieval trigger only indicates that historical experience is currently worth querying; it does not equate to mandatory injection. This embodiment performs fault correction, source protection, acceptance testing, and mapping correction judgments according to the problem type: Fault correction judges whether the current plan contradicts the error or whether a repeated failure strategy is being prepared; source protection judges whether high-risk conclusions have reliable sources; acceptance testing judges whether task requirements and unclosed items have direct evidence of completion; and mapping correction judges whether the difference between the source data and the target result will still contaminate the deliverables.

[0090] If the main agent has adopted the correct solution and is validating it, the problem has been solved, or the candidate memory cannot provide new decision-making information, then a no-intervention result is output. When intervention is required, the intervention decision unit selects the corresponding memory identifier and generates injection content including current evidence, a suggested action, and success criteria. When multiple problem types are simultaneously identified, the system judges them separately and then merges the results in the order of acceptance risk, source risk, mapping risk, and failure risk. When the same memory is selected multiple times, only the highest priority result is retained, and a single injection is sent to the main agent to avoid continuously interrupting the main agent.

[0091] (10) Execution order and problem closing

[0092] When both maintenance and retrieval conditions are met in the same step, the system first updates the problem status and performs memory construction or revision, then retrieves candidates from the updated memory, and finally determines whether to inject. No intervention is performed if only the construction condition is met; no new memory is built if only the retrieval condition is met. Neither memory construction nor memory injection itself proves the problem is solved; only subsequent direct verification of the results can mark the problem as solved. The system records the problem status, triggering cause, memory source, retrieval candidates, and final intervention result, ensuring that each memory operation can be traced back to corresponding operational evidence.

[0093] (11) Task completion and exception handling

[0094] When the main agent prepares to submit, the system checks each task requirement. Completion declarations, file existence, file openability, and planned checks cannot be considered sole evidence that semantic, format, source, and quality requirements have been met. After the task is completed, working memory is saved as the memory file for the current task; the next task does not load this working memory. Long-term memory continues to be stored in the cross-session database. The system records each problem change, trigger result, suppression reason, memory operation, retrieval candidate, and final injection result. If the long-term memory database, vector service, or reordering service fails, the long-term memory operation fails and closes, and the main agent continues executing the task; the system does not use unreordered candidates as replacement results. Startup errors such as missing configuration or mismatched vector dimensions will terminate the task before it begins.

[0095] (12) Overall process

[0096] like Figure 1 As shown, the process includes three stages: task initialization, runtime loop, and submission evaluation. At the start of a task, the system constructs a task profile before the main agent's first execution. The working memory profile records the current task's requirements and acceptance baseline; the long-term memory profile describes rules that can be reused across tasks. Historical long-term memories are not fully loaded, but only invoked as needed when a retrieval trigger occurs. During task execution, the system continuously collects tool results, errors, analyses, and plans. Runtime events, after being confirmed by the evidence gate, are used to maintain the status of issues from discovery and repair to verification closure. The trigger gate, combined with current evidence, issue status, and evidence changes, decides whether to construct or maintain memories, retrieve candidate memories, or not perform any operation. After retrieving candidate memories, the system performs a secondary intervention judgment. Memory injection is only performed on the main agent if the candidate memory can provide additional decision-making value for the current plan; otherwise, it remains silent. Therefore, a retrieval trigger does not necessarily equate to intervention. When the main agent is ready to submit, the system jointly checks for unmet requirements and unclosed issues in the task profile. If direct evidence of completion is lacking, the system returns to runtime for further verification. Once all requirements are met, the system receives a reward or evaluation result and saves the verified closed-loop experience and global correction rules as cross-session long-term memory.

[0097] Example 2

[0098] This embodiment provides a hierarchical memory management and proactive intervention system for task-oriented intelligent agents. This system is located outside the main intelligent agent performing the task, such as... Figure 2 As shown, it includes a task requirement generation unit, a runtime event acquisition unit, a problem status management unit, a trigger judgment unit, a working memory management unit, a long-term memory management unit, and an intervention decision unit.

[0099] In this embodiment, the setup and operation of each unit are as follows. The task requirement generation unit is deployed during the task initiation phase. Before the main agent executes an operation for the first time, it extracts deliverables, constraints, prohibitions, and acceptance criteria from the task description. It retains the original source and direct verification conditions for each task requirement, constructs a task profile, and writes the current task requirement into working memory. Only rules explicitly applicable to subsequent tasks are generated as long-term memory candidates with applicable scope. The runtime event acquisition unit interfaces with the main agent at a step-by-step granularity. After the main agent completes each step, it obtains the task description, tool return results, command exit status, error messages, the main agent's analysis of the results, the next step plan, and deliverable information. These are then saved and processed according to their source: original task text, tool output, analysis, plan, and evaluation. The problem state management unit maintains a problem record database, associating current events with historical problems. It directly generates problem evidence for objective events, and for events requiring semantic judgment, it first generates problem candidates before submitting them to a semantic classifier for confirmation. It manages the lifecycle states of problems: observed, awaiting evidence, processable, under repair, verified resolved, or closed. It uses evidence fingerprints to determine if evidence has substantially changed; if the evidence fingerprint hasn't changed, it won't trigger repeatedly with additional steps. The trigger judgment unit generates memory construction or retrieval requests based on the problem state. Clear and cross-step effective task constraints and facts that have been confirmed and affect subsequent steps are entered into working memory. Temporary states, currently visible outputs, and unverified guesses are not built into long-term memory. Fault recovery experience is only built into procedural memory when the main agent adopts a substantially different strategy and confirms through direct results that it has solved the original problem. The working memory management unit manages the access to working memory, retrieving candidate memories from the requirements, state, knowledge, and procedural experience of the current task when a retrieval is triggered. Working memory is established at the start of each task and saved or cleared after the task ends. The long-term memory management unit manages the access to long-term memories across the session database. Upon retrieval trigger, it generates a query and recalls candidate memories based on the current task, problem evidence, and plan, excluding records generated by the current task itself. The intervention decision unit compares candidate memories, current evidence, and the agent's current plan. If the agent has not yet identified an error, is preparing a strategy to repeat failures, or lacks direct evidence before submission due to task requirements, it selects relevant memories to inject into the agent. If the agent has already adopted the correct solution and is validating it, the problem has been solved, or the candidate memories cannot provide new information for the current decision, it remains silent.

[0100] During operation, the system works collaboratively in the order of "state update, memory construction, candidate retrieval, and intervention judgment": when the same step simultaneously meets the maintenance and retrieval conditions, the problem state management unit first updates the problem state and the trigger judgment unit performs memory construction or revision; then, the working memory management unit and the long-term memory management unit retrieve candidates from the updated memory; finally, the intervention decision unit determines whether to inject. If the long-term memory database, vector service, or rearrangement service fails, the current long-term memory operation fails and is closed, the main agent continues to execute the task, and the system does not use unrearranged candidates as replacement results. Through the setup and collaboration of the above units, the system achieves the same technical effect as the method described in Example 1.

[0101] Example 3

[0102] This embodiment provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the hierarchical memory management and active intervention method for task-oriented intelligent agents as described in Embodiment 1.

[0103] In terms of hardware configuration, the computer device can be a server, workstation, or cloud computing instance. Its processor is a general-purpose central processing unit or a processor with parallel computing capabilities, and its memory includes volatile memory and non-volatile storage media. During deployment, the main intelligent agent and the memory processing system can be deployed on the same computer device or separately on different computer devices and communicate via a network. When deployed separately, the event acquisition unit obtains information such as task descriptions, tool outputs, errors, analyses, and plans from the main intelligent agent through inter-process communication interfaces or network interfaces.

[0104] During operation, the processor loads and executes the computer program, sequentially completing steps S1 to S6 in Example 1: constructing a task profile and writing it into working memory before the main agent performs its first operation; progressively collecting running events and maintaining the problem lifecycle state; performing memory construction or retrieval based on the problem state; recalling candidate memories from working memory and long-term memory after a retrieval is triggered and making independent intervention value judgments, ultimately deciding whether to inject the memory into the main agent or remain silent. The long-term memory database and vector retrieval service can be executed locally by the processor or completed by the processor calling external service interfaces. Therefore, when running a task agent for extended periods, this computer device can reduce invalid memory calls and operating costs, decrease long-term memory contamination and erroneous interventions, and improve task delivery quality.

[0105] Example 4

[0106] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the hierarchical memory management and active intervention method for task-oriented intelligent agents as described in Embodiment 1. The computer-readable storage medium includes a disk, optical disk, solid-state memory, or flash memory.

[0107] In terms of specific setup, the computer program is organized in a modular manner, including program modules corresponding to task requirement generation, runtime event acquisition, problem status management, trigger judgment, working memory management, long-term memory management, and intervention decision-making. Each program module, when executed by the processor, implements the function of the corresponding step in Example 1. The computer program in the storage medium also includes exception handling logic: when the long-term memory database, vector service, or reordering service fails, failure shutdown processing is performed, allowing the main agent to continue executing the task without using unreordered candidates as alternative results; when a startup error occurs due to missing configuration or mismatched vector dimensions, execution is terminated before the task begins.

[0108] During operation, the storage medium is connected to a computer device, and the processor reads and executes the computer program therein. This allows a memory processing system to be built outside the main intelligent agent that performs the task. Based on observable operational evidence such as task requirements, tool results, errors, current plans, and evaluation results generated during the operation of the main intelligent agent, as well as the problem lifecycle status, it is determined whether to build memory, retrieve memory, or remain silent. This achieves the same technical effect as in Example 1 in a software manner, which facilitates the distribution, deployment, and version upgrade of the method.

[0109] Example 5

[0110] This embodiment provides five alternative implementation methods for Embodiment 1.

[0111] (1) Trigger judgment can be based entirely on deterministic rules, or it can be directly judged by a classification model or a language model, or it can be the “rule discovery candidate, model confirmation semantics” method in this embodiment.

[0112] (2) The life cycle of a problem can be represented by a finite state machine, or by a combination of state labels, failure counts, confidence and timestamps; changes in evidence can be judged by hash fingerprints, structured field comparisons or semantic similarity.

[0113] (3) Working memory and long-term memory can be generated simultaneously after the same closed-loop event, or working memory can be generated first and then long-term memory can be filtered by an independent abstractor or a batch processing process after the task ends.

[0114] (4) Long-term memory can use keywords, vectors, structured conditions, knowledge graphs or hybrid retrieval; candidates can be sorted by rules, dedicated rearrangement models, language models or multiple scoring combinations.

[0115] (5) Intervention judgment can be completed by a unified judge or judged separately according to the problem type; the judgment results can be merged into natural language prompts or converted into structured constraints, to-do items or verification requests and provided to the main intelligent agent.

[0116] The aforementioned alternative methods can be used independently or in combination, and the common technical relationships they retain are: the timing of memory operations is determined by operational evidence; different access conditions are used for memories with different applicable scopes; and retrieval results must undergo independent intervention value judgment before being provided to the main agent. These alternative methods do not change the core processing relationship based on evidence-triggered events, hierarchical storage, and a subsequent determination of whether to inject the data after retrieval.

[0117] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A hierarchical memory management and active intervention method for task-oriented intelligent agents, characterized in that, The method is applied to a memory processing system set up outside the main intelligent agent performing the task, and the method includes the following steps: S1: Before the main intelligent agent performs the operation for the first time, the task requirement generation unit extracts the task requirements from the task description, constructs the task profile, and writes the current task requirements into the working memory. S2: After each step is completed by the main intelligent agent, the running event collection unit collects the running events of the main intelligent agent and saves and processes them according to their source; S3: The problem status management unit associates current events with historical problems to form problem evidence, and performs semantic confirmation on events that require semantic judgment, thereby managing the lifecycle status of problems; S4: The triggering judgment unit generates a memory construction request or a memory retrieval request based on the problem status; S5: When the triggering condition is met, the working memory management unit and the long-term memory management unit retrieve candidate memories from working memory and long-term memory; S6: The intervention decision unit compares the candidate memories, current evidence, and the main agent's current plan to decide whether to inject the memory into the main agent or remain silent.

2. The method as described in claim 1, characterized in that, In step S1, deliverables, constraints, prohibitions, and acceptance criteria are extracted from the task description, and the original source and direct verification conditions are retained for each task requirement; among them, only rules that are clearly applicable to subsequent tasks are used to generate long-term memory candidates with applicable scope.

3. The method as described in claim 1, characterized in that, In step S2, the task description, tool return results, command exit status, error information, the main intelligent agent's analysis of the results, the next step plan, and deliverable information are obtained from the main intelligent agent and saved and processed according to the source of the original task text, tool output, analysis, plan, and evaluation.

4. The method as described in claim 1, characterized in that, In step S3, problem evidence is directly formed for objective events, and problem candidates are first generated for events that require semantic judgment and then semantic confirmation is performed. The confirmed problems are in the life cycle states of observed, waiting for evidence, processable, under repair, verified and resolved or closed in sequence. The evidence fingerprint is used to determine whether the evidence has changed substantially. If the evidence fingerprint has not changed, it will not be triggered repeatedly due to the increase of steps.

5. The method as described in claim 1, characterized in that, In step S4, explicit and cross-step effective task constraints and facts that have been confirmed and affect subsequent steps are entered into working memory, while temporary states, currently visible outputs and unverified guesses are not constructed into long-term memory. Fault recovery experience begins with the first failure, and procedural memory is only built when the main agent subsequently adopts a substantially different strategy and confirms through direct results that the strategy solved the original problem.

6. The method as described in claim 1, characterized in that, In step S5, a memory retrieval request is generated when any of the following triggering conditions are met: (1) The current plan contradicts the evidence of failure; (2) The main agent fails to repeat the same type of failure; (3) Delivery requirements lack direct verification; (4) The current results have source and mapping risks; Working memory retrieves information from the requirements, state, knowledge, and procedural experience of the current task, while long-term memory generates queries and recalls candidate memories based on the current task, problem evidence, and plan, excluding records generated by the current task itself.

7. The method as described in claim 1, characterized in that, In step S6, when the main agent has not yet identified the error, is preparing a repeated failure strategy, or still lacks direct evidence for the task requirements before submission, relevant memories are selected for injection; when the main agent has already adopted the correct solution and is verifying it, the problem has been solved, or the candidate memories cannot provide new information for the current decision, the agent remains silent.

8. The method as described in claim 1, characterized in that, Step S2 is executed by the event acquisition unit, which obtains task description, tool output, errors, analysis, and plan from the main agent. Step S3 is executed by the problem status management unit, which associates the current event with historical problems. Step S4 is executed by the trigger judgment unit, which generates a memory construction request or retrieval request based on the problem status. The memory access operation is executed by the working memory management unit and the long-term memory management unit. Step S6 is executed by the intervention decision unit, which decides whether to provide memory to the main agent based on candidate memories and the current plan.

9. The method as described in claim 1, characterized in that, Each issue record should include at least the issue identifier, issue type, associated objects, lifecycle status, evidence, evidence fingerprint, and attributes to be verified; each memory should include at least the memory type, content, scope of application, source event, source steps, verification evidence, and success criteria.

10. The method as described in claim 1, characterized in that, In step S3, objective events such as non-zero exit status and non-existent files directly form problem evidence; for events that require semantic judgment, such as unreliable sources, mapping deviations, or insufficient acceptance, problem candidates are first generated and then confirmed through rules, classification models, or language models. If the confirmation fails or the evidence is insufficient, no problem is created and no memory operation is performed.

11. The method as described in claim 4, characterized in that, The evidence fingerprint is generated by standardizing and hashing the key elements of the evidence in question, and is used to identify whether the evidence for the same question has undergone substantial changes. When the evidence fingerprint of a newly collected event is consistent with the evidence fingerprint of an existing question record, it is determined that the evidence has not undergone substantial changes, and memory construction requests or retrieval requests are not repeatedly generated due to the increase in the number of steps. When the evidence fingerprint changes, the evidence in the question record is updated and the process re-enters the corresponding lifecycle state.

12. The method as described in claim 1, characterized in that, In step S4, the content of the procedural memory includes failure conditions, invalid strategies, correction strategies, verification actions, success criteria, and scope of application; errors or repair plans alone cannot form this type of procedural memory; after the task is completed, if the reward or evaluation results indicate that the verification method adopted by the main agent cannot prove the actual requirements, then an independent correction memory is constructed, which is formed separately from the runtime fault recovery memory.

13. The method as described in claim 1, characterized in that, The same verified event generates both working memory and long-term memory: working memory retains the current task object and execution state; long-term memory deletes the specific task name, file name and temporary environment information, and only retains the reusable triggering conditions, resolution principles, success criteria and scope of application; both share the source event and source step identifier, and long-term memory is not a direct copy of working memory.

14. The method as described in claim 1, characterized in that, In step S5, long-term memory is stored in a cross-session database and is not fully loaded into the main agent context when a new task begins. After a long-term memory retrieval is triggered, the system generates a query based on the current task, problem evidence, and plan, recalls similar records, excludes records of the current task itself, and then obtains candidate memories through relevance rearrangement and threshold filtering. The retrieval uses vectors, keywords, knowledge graphs, or a combination of these methods, and the rearrangement uses a dedicated model, rule scoring, or language model scoring.

15. The method as described in claim 1, characterized in that, In step S6, the injected content includes currently observable evidence, a suggested action, and a corresponding success criterion; the main agent's completion statement, planned checks, file existence, or file openability cannot replace direct completion evidence corresponding to specific task requirements; when multiple search conditions are hit simultaneously, they are judged separately, and duplicate candidates are removed and merged into one injection.

16. The method as described in claim 1, characterized in that, When both maintenance and retrieval conditions are met in the same step, the problem status is updated first and memory construction or revision is performed. Then, candidates are retrieved from the updated memory, and finally, it is determined whether to inject. If only the construction condition is met, no intervention judgment is performed. If only the retrieval condition is met, no new memory is built. Neither memory construction nor memory injection can prove that the problem is solved. Only subsequent direct verification of the results can close the problem.

17. The method as described in claim 1, characterized in that, The method also includes an exception handling step: when the long-term memory database, vector service, or reordering service fails, the long-term memory operation fails and is shut down, the main agent continues to execute the task, and the system does not use unreordered candidates as alternative results; startup errors such as missing configuration or mismatched vector dimensions are terminated before the task starts.

18. A hierarchical memory management and active intervention system for task-oriented intelligent agents, characterized in that, The system is located outside the main intelligent agent that performs the task, and the system includes: The task requirement generation unit is used to extract task requirements from the task description, construct a task profile, and write the current task requirements into working memory before the main intelligent agent performs the operation for the first time. The event acquisition unit is used to collect the running events of the main intelligent agent and save and process them according to their source. The problem status management unit is used to associate current events with historical problems to form problem evidence, and to perform semantic confirmation on events that require semantic judgment, thereby managing the lifecycle status of problems. The triggering judgment unit is used to generate a memory construction request or a memory retrieval request based on the problem status; The working memory management unit is used to manage access to working memory and retrieve candidate memories from working memory when a retrieval is triggered. The long-term memory management unit is used to manage the access to long-term memory and retrieve candidate memories from long-term memory when a retrieval is triggered. The intervention decision unit is used to compare candidate memories, current evidence, and the main agent's current plan to decide whether to inject the memory into the main agent or remain silent.

19. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, The task requirement generation unit extracts deliverables, constraints, prohibitions, and acceptance criteria from the task description, retains the original source and direct verification conditions for each task requirement, and generates long-term memory candidates with applicable scope only for rules that are clearly applicable to subsequent tasks.

20. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, The runtime event acquisition unit obtains the task description, tool return results, command exit status, error information, the main intelligent agent's analysis of the results, the next step plan, and deliverable information from the main intelligent agent, and saves and processes them according to the source of the original task text, tool output, analysis, plan, and evaluation.

21. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, The problem status management unit directly generates problem evidence for objective events. For events that require semantic judgment, it first generates problem candidates and then performs semantic confirmation. It manages the lifecycle status of problems, including observed, awaiting evidence, processable, under repair, verified and resolved, or closed. It also uses evidence fingerprints to determine whether the evidence has changed substantially. If the evidence fingerprint has not changed, it will not be triggered repeatedly due to the increase of steps.

22. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, In the triggering judgment unit, clear and effective task constraints across steps and facts that have been confirmed and affect subsequent steps enter working memory. Temporary states, currently visible outputs, and unverified guesses do not build long-term memory. Fault recovery experience starts from the first failure and only builds procedural memory when the main agent subsequently adopts a substantially different strategy and confirms through direct results that the strategy has solved the original problem.

23. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, When a retrieval is triggered, the long-term memory management unit generates a query and recalls candidate memories based on the current task, problem evidence, and plan, while excluding records generated by the current task itself.

24. The hierarchical memory management and active intervention system for task-oriented intelligent agents as described in claim 18, characterized in that, When the main agent has not yet identified the error, is preparing a strategy to repeat the failure, or still lacks direct evidence for the task requirements before submission, the intervention decision unit selects relevant memories to inject into the main agent. When the main agent has already adopted the correct solution and is verifying it, the problem has been solved, or the candidate memories cannot provide new information for the current decision, the intervention decision unit remains silent.

25. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the hierarchical memory management and active intervention method for task-oriented intelligent agents as described in any one of claims 1 to 17.

26. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the hierarchical memory management and active intervention method for task-oriented intelligent agents as described in any one of claims 1 to 17.

Images