AI代理内存消耗过大？9种优化策略对比分析-CSDN博客

本文链接：https://blog.csdn.net/deephub/article/details/149428508

在AI代理系统的架构设计中，虽然多代理协作可以提升系统的整体准确性，但对话式AI的性能优化远不止于此。内存管理已成为影响系统性能的关键因素之一。

随着AI代理与用户的对话深度和长度不断增加，其内存消耗呈指数级增长。这种增长主要源于系统需要维护的多个组件，包括历史上下文存储、工具调用记录、数据库查询结果以及其他依赖项的状态信息。

本文将深入探讨并实现九种从基础到高级的内存优化技术，涵盖从简单的顺序存储方法到复杂的类操作系统内存管理策略。通过系统性的代码实现和性能评估，我们将分析每种技术的适用场景、优势特点以及潜在限制。

为确保研究的一致性和可重现性，本文将基于统一的AI代理框架进行测试，这样可以更好地观察各种内存优化技术的内部机制，并为在复杂生产环境中的应用提供可扩展的参考实现。

实验环境配置

在开始内存优化技术的实现与评估之前，需要配置相应的开发环境并安装必要的依赖库。

本文需要以下核心库的支持：

openai

库用于与大语言模型API进行交互，

numpy

库提供高效的数值计算支持，特别是在嵌入向量处理方面，

faiss-cpu

库作为Facebook AI开发的高效相似性搜索引擎，将为检索型内存系统提供向量数据库功能，

networkx

库用于构建和管理基于图的内存策略中的知识图谱，以及

tiktoken

库用于精确的token计数和上下文窗口管理。

# 安装所需的依赖项
pip install openai numpy faiss-cpu networkx tiktoken

接下来需要初始化与大语言模型的通信接口。本实验通过API提供商（如Nebius或Together AI）访问开源模型，确保实验的可重现性。

# 导入必要的库
import os  
from openai import OpenAI  

# 定义用于身份验证的API密钥
API_KEY = "YOUR_LLM_API_KEY"  

# 定义API端点的基础URL
BASE_URL = "https://api.studio.nebius.com/v1/"  

# 使用指定的基础URL和API密钥初始化OpenAI客户端
client = OpenAI(  
    base_url=BASE_URL,  
    api_key=API_KEY  
)  

# 打印确认消息以指示客户端设置成功
print("OpenAI client configured successfully.")

本文选择了经过验证的开源模型组合来确保实验结果的可靠性。对于文本生成任务，采用

LLaMA 3.1 8B Instruct

模型，该模型在对话任务中表现出色。对于需要嵌入表示的优化策略，选择

Gemma-2-BGE

多模态嵌入模型，该模型在语义相似性计算方面具有较好的性能。

# 导入额外的功能库
import tiktoken  
import time  

# --- 模型配置 ---  
# 定义用于生成和嵌入任务的特定模型
# 这些在这个实验中是硬编码的，但可以从配置文件加载
GENERATION_MODEL = "meta-llama/Meta-Llama-3.1-8B-Instruct"  
EMBEDDING_MODEL = "BAAI/bge-multilingual-gemma2"

核心工具函数实现

为了确保代码的模块化和可维护性，我们实现了三个核心工具函数。这些函数将在后续的内存优化策略实现中被重复使用。

文本生成函数

generate_text

函数负责调用大语言模型生成文本响应。该函数接收系统提示和用户提示作为输入，通过配置的客户端向模型发送请求，并返回生成的文本内容。

def generate_text(system_prompt: str, user_prompt: str) -> str:  
    """  
    调用LLM API生成文本响应。

    Args:  
        system_prompt: 定义AI角色和行为的指令。
        user_prompt: AI应该回应的用户输入。

    Returns:  
        AI生成的文本内容，或错误消息。
    """  
    # 向配置的客户端创建聊天完成请求
    response = client.chat.completions.create(  
        model=GENERATION_MODEL,  
        messages=[  
            {"role": "system", "content": system_prompt},  
            {"role": "user", "content": user_prompt}  
        ]  
    )  
    # 提取并返回AI消息的内容
    return response.choices[0].message.content

嵌入向量生成函数

generate_embedding

函数用于生成文本的向量表示，这对于基于检索的内存优化策略至关重要。该函数利用预配置的嵌入模型将输入文本转换为高维向量，用于后续的相似性计算。

def generate_embedding(text: str) -> list[float]:  
    """  
    使用嵌入模型为给定文本字符串生成数值嵌入向量。

    Args:  
        text: 要转换为嵌入向量的输入字符串。

    Returns:  
        表示嵌入向量的浮点数列表，错误时返回空列表。
    """  
    # 向配置的客户端创建嵌入请求
    response = client.embeddings.create(  
        model=EMBEDDING_MODEL,  
        input=text  
    )  
    # 从响应数据中提取并返回嵌入向量
    return response.data[0].embedding

Token计数函数

精确的token计数对于评估不同内存策略的效率至关重要。我们采用广泛使用的

cl100k_base

编码器，这是一个基于字节对编码（BPE）的分词器，被众多现代语言模型采用。

# --- Token计数设置 ---  
# 使用tiktoken初始化分词器。'cl100k_base'是许多现代模型使用的常见编码，
# 包括来自OpenAI和Llama的模型。
# 这允许我们在发送提示之前准确估计其大小。
tokenizer = tiktoken.get_encoding("cl100k_base")

Token计数函数的实现相对简单，但对于理解不同内存策略的计算开销具有重要意义。

def count_tokens(text: str) -> int:  
    """  
    使用预加载的分词器计算给定字符串中的token数量。

    Args:  
        text: 要分词的字符串。

    Returns:  
        token数量的整数。
    """  
    # `encode`方法将字符串转换为token ID列表
    # 这个列表的长度就是token计数
    return len(tokenizer.encode(text))

基础架构设计

为了确保不同内存优化策略的一致性和可互换性，我们采用面向对象的设计模式，定义了一个抽象基类

BaseMemoryStrategy

。该类规定了所有内存策略必须实现的核心接口，包括消息添加、上下文获取和内存清理功能。

# --- 内存策略的抽象基类 ---  
# 这个类定义了所有内存策略必须遵循的'约定'。
# 通过使用抽象基类(ABC)，我们确保我们创建的任何内存实现
# 都将具有相同的核心方法(add_message, get_context, clear)，
# 允许它们可以互换地插入到AIAgent中。
class BaseMemoryStrategy(abc.ABC):  
    """所有内存策略的抽象基类。"""  

    @abc.abstractmethod  
    def add_message(self, user_input: str, ai_response: str):  
        """  
        必须由子类实现的抽象方法。
        它负责将新的用户-AI交互添加到内存存储中。
        """  
        pass  

    @abc.abstractmethod  
    def get_context(self, query: str) -> str:  
        """  
        必须由子类实现的抽象方法。
        它从内存中检索和格式化相关上下文以发送给LLM。
        'query'参数允许一些策略(如检索)获取
        与用户最新输入特别相关的上下文。
        """  
        pass  

    @abc.abstractmethod  
    def clear(self):  
        """  
        必须由子类实现的抽象方法。
        它提供了重置内存的方法，这对于开始新对话很有用。
        """  
        pass

AIAgent

类作为整个系统的核心组件，负责协调对话流程并与不同的内存策略进行交互。该类采用策略模式，可以在运行时切换不同的内存管理策略，从而方便对比不同方法的性能表现。

# --- 核心AI代理 ---  
# 这个类协调整个对话流程。它使用特定的内存策略初始化，
# 并使用它来管理对话的上下文。
class AIAgent:  
    """主要的AI代理类，设计为与任何内存策略配合工作。"""  

    def __init__(self, memory_strategy: BaseMemoryStrategy, system_prompt: str = "You are a helpful AI assistant."):  
        """  
        初始化代理。

        Args:  
            memory_strategy: 继承自BaseMemoryStrategy的类的实例。
                            这决定了代理如何记住对话。
            system_prompt: 给LLM的初始指令，用于定义其人格和任务。
        """  
        self.memory = memory_strategy  
        self.system_prompt = system_prompt  
        print(f"Agent initialized with {type(memory_strategy).__name__}.")  

    def chat(self, user_input: str):  
        """  
        处理对话的单个回合。

        Args:  
            user_input: 用户的最新消息。
        """  
        print(f"\n{'='*25} NEW INTERACTION {'='*25}")  
        print(f"User > {user_input}")  

        # 步骤1：从代理的内存策略中检索上下文
        # 这是执行特定内存逻辑(例如，顺序、检索)的地方
        start_time = time.time()  
        context = self.memory.get_context(query=user_input)  
        retrieval_time = time.time() - start_time  

        # 步骤2：为LLM构建完整的提示
        # 这将检索到的历史上下文与用户当前请求结合起来
        full_user_prompt = f"### MEMORY CONTEXT\n{context}\n\n### CURRENT REQUEST\n{user_input}"  

        # 步骤3：提供详细的调试信息
        # 这对于理解内存策略如何影响提示大小和成本至关重要
        prompt_tokens = count_tokens(self.system_prompt + full_user_prompt)  
        print("\n--- Agent Debug Info ---")  
        print(f"Memory Retrieval Time: {retrieval_time:.4f} seconds")  
        print(f"Estimated Prompt Tokens: {prompt_tokens}")  
        print(f"\n[Full Prompt Sent to LLM]:\n---\nSYSTEM: {self.system_prompt}\nUSER: {full_user_prompt}\n---")  

        # 步骤4：调用LLM获取响应
        # LLM使用系统提示和组合的用户提示(上下文+新查询)生成回复
        start_time = time.time()  
        ai_response = generate_text(self.system_prompt, full_user_prompt)  
        generation_time = time.time() - start_time  

        # 步骤5：用最新交互更新内存
        # 这确保当前回合可用于未来的上下文检索
        self.memory.add_message(user_input, ai_response)  

        # 步骤6：显示AI的响应和性能指标
        print(f"\nAgent > {ai_response}")  
        print(f"(LLM Generation Time: {generation_time:.4f} seconds)")  
        print(f"{'='*70}")

AI代理的工作流程包含六个关键步骤：首先从内存策略中检索相关上下文，然后将历史上下文与当前用户请求合并构建完整提示，接着输出详细的调试信息以便性能分析，随后调用大语言模型生成响应，然后更新内存以记录新的交互，最后输出AI响应和性能指标。这种设计确保了系统的透明度和可调试性。

1、顺序内存存储

顺序内存存储是最直观的内存管理方法，它将所有对话历史按时间顺序完整保存。

这种方法的优势在于实现简单，能够提供完整的对话上下文，但随着对话长度增加，token消耗会呈线性增长。

 # --- 策略1：顺序（保存所有）内存 ---  
# 这是最基本的内存策略。它将整个对话历史存储在简单的列表中。
# 虽然它提供了完美的回忆，但它不可扩展，
# 因为发送给LLM的上下文随着每次回合而增长，很快变得昂贵
# 并达到token限制。
class SequentialMemory(BaseMemoryStrategy):  
    def __init__(self):  
        """使用空列表初始化内存以存储对话历史。"""  
        self.history = []  

    def add_message(self, user_input: str, ai_response: str):  
        """  
        将新的用户-AI交互添加到历史中。
        每个交互作为列表中的两个字典条目存储。
        """  
        self.history.append({"role": "user", "content": user_input})  
        self.history.append({"role": "assistant", "content": ai_response})  

    def get_context(self, query: str) -> str:  
        """  
        检索整个对话历史并将其格式化为单个字符串
        以用作LLM的上下文。'query'参数被忽略，
        因为此策略总是返回完整历史。
        """  
        # 将所有消息连接成一个以换行符分隔的字符串
        return "\n".join([f"{turn['role'].capitalize()}: {turn['content']}" for turn in self.history])  

    def clear(self):  
        """通过清除列表重置对话历史。"""  
        self.history = []  
         print("Sequential memory cleared.")

顺序内存策略的实现相对简单，但其性能特征值得深入分析。通过实际测试，我们可以观察到随着对话轮数的增加，token消耗呈线性增长的趋势，这在长对话场景中会导致显著的成本增加。

# 初始化并运行代理
# 创建SequentialMemory策略的实例
sequential_memory = SequentialMemory()  
# 创建AIAgent并将顺序内存策略注入其中
agent = AIAgent(memory_strategy=sequential_memory)

通过多轮对话测试，我们可以观察到顺序内存策略的性能特征：

# --- 开始对话 ---  
# 第一轮：用户介绍自己
agent.chat("Hi there! My name is Sam.")  
# 第二轮：用户说明他们的兴趣
agent.chat("I'm interested in learning about space exploration.")  
# 第三轮：用户测试代理的内存
agent.chat("What was the first thing I told you?")  

>>>> Tokens: 23 | Response Time: 2.25s  

==== NEW INTERACTION ====  
User: I am interested in learning about space exploration.    
Bot: Awesome! Are you curious about:  
- Mars missions    
- Space agencies    
- Private companies (e.g., SpaceX)    
- Space tourism    
- Search for alien life?  

 ############ 输出 ############  
==== NEW INTERACTION ====  
User: Hi there! My name is Sam.    
 Bot: Hello Sam! Nice to meet you. What brings you here today?    
>>>> Tokens: 92 | Response Time: 4.46s  

==== NEW INTERACTION ====  
User: What was the first thing I told you?    
Bot: You said, "Hi there! My name is Sam."    
...  

>>>> Tokens: 378 | Response Time: 0.52s

从测试结果可以看出，对话流程保持了良好的连贯性，但token消耗呈显著增长趋势。由于系统不依赖会显著增加token大小的外部工具，这种增长完全源于消息的顺序累积。

顺序方法虽然实现简单，但存在明显的成本缺陷：随着对话长度的增加，token成本呈线性增长，在长对话场景中会导致显著的经济负担。

2、滑动窗口内存管理

为了解决顺序存储中上下文无限增长的问题，滑动窗口策略采用了固定大小的内存窗口，只保留最近的N次对话交互。这种方法在控制内存消耗的同时，可能会丢失重要的历史信息。

滑动窗口策略的核心机制包括：定义固定的窗口大小（如保留最近2轮对话），当新对话到达时，最早的对话被自动移除，确保发送给LLM的上下文始终保持在固定大小范围内。

 # --- 策略2：滑动窗口内存 ---  
# 这个策略只保留对话的最近'N'轮。
# 它防止上下文无限增长，使其可扩展且
# 成本效益高，但代价是忘记旧信息。
class SlidingWindowMemory(BaseMemoryStrategy):  
    def __init__(self, window_size: int = 4): # window_size是轮数(用户+AI=1轮)  
        """  
        使用固定大小的deque初始化内存。
          
        Args:  
            window_size: 要保留在内存中的对话轮数。
                        单个轮包含一个用户消息和一个AI响应。
        """  
        # 具有'maxlen'的deque会在添加新项目且deque满时自动丢弃最旧的项目。
        # 这是滑动窗口的核心机制。我们存储轮，所以maxlen是window_size。
        self.history = deque(maxlen=window_size)  

    def add_message(self, user_input: str, ai_response: str):  
        """  
        向历史添加新的对话轮。如果deque满了，
        最旧的轮会自动被移除。
        """  
        # 每轮(用户输入+AI响应)作为deque中的单个元素存储。
        # 这使得按轮管理窗口大小变得容易。
        self.history.append([  
            {"role": "user", "content": user_input},  
            {"role": "assistant", "content": ai_response}  
        ])  

    def get_context(self, query: str) -> str:  
        """  
        检索当前窗口内的对话历史并将其格式化为单个字符串。
        'query'参数被忽略。
        """  
        # 创建一个临时列表来保存格式化的消息
        context_list = []  
        # 遍历deque中存储的每一轮
        for turn in self.history:  
            # 遍历该轮中的用户和助手消息
            for message in turn:  
                # 格式化消息并添加到我们的列表中
                context_list.append(f"{message['role'].capitalize()}: {message['content']}")  
        # 将所有格式化的消息连接成一个字符串，以换行符分隔
         return "\n".join(context_list)

滑动窗口内存策略的实现利用了Python的

deque

数据结构，通过设置

maxlen

参数实现自动的先进先出机制。这种设计确保了内存使用的可预测性，但需要谨慎选择窗口大小以平衡性能和信息保留。

# 使用2轮的小窗口大小初始化
# 这意味着代理只会记住最后两次用户-AI交互
sliding_memory = SlidingWindowMemory(window_size=2)  
# 创建AIAgent并注入滑动窗口内存策略
agent = AIAgent(memory_strategy=sliding_memory)

测试验证了滑动窗口策略的有效性：

# --- 开始对话 ---  
# 第一轮：用户介绍自己。这是轮1。
agent.chat("My name is Priya and I'm a software developer.")  
# 第二轮：用户提供更多细节。内存现在保存轮1和轮2。
agent.chat("I work primarily with Python and cloud technologies.")  

# 第三轮：用户提到爱好。添加此轮会将轮1推出
# 固定大小的deque。内存现在只保存轮2和轮3。
agent.chat("My favorite hobby is hiking.")  
############ 输出 ############  
==== NEW INTERACTION ====  
User: My name is Priya and I am a software developer.    
Bot: Nice to meet you, Priya! What can I assist you with today?  

>>>> Tokens: 27 | Response Time: 1.10s  

==== NEW INTERACTION ====  
User: I work primarily with Python and cloud technologies.    
Bot: That is great! Given your expertise...  

>>>> Tokens: 81 | Response Time: 1.40s  

==== NEW INTERACTION ====  
User: My favorite hobby is hiking.  
Bot: It seems we had a nice conversation about your background...  

>>>> Tokens: 167 | Response Time: 1.59s

当测试系统对已移出窗口的信息的记忆能力时，可以观察到策略的局限性：

# 现在，询问第一次提到的内容
# 发送给LLM的上下文只包含关于Python/云和远足的信息
# 关于用户姓名的信息已被遗忘
agent.chat("What is my name?")  
# 代理可能会失败，因为第一轮已被推出窗口
#### 输出 ####  
==== NEW INTERACTION ====  
User: What is my name?  
Bot: I apologize, but I dont have access to your name from our recent   
conversation. Could you please remind me?  

>>>> Tokens: 197 | Response Time: 0.60s

测试结果清楚地显示了滑动窗口策略的权衡特性：虽然成功控制了token消耗，但当用户查询窗口外的信息时，系统无法提供准确回答。这表明滑动窗口的大小设置需要根据具体应用场景进行优化。

3、摘要型内存优化

摘要型内存策略通过智能压缩历史信息来解决顺序存储的成本问题和滑动窗口的信息丢失问题。该策略利用大语言模型的理解能力，定期将对话历史压缩为简洁的摘要形式。

摘要策略的工作机制包括：维护一个临时缓冲区存储最近的对话，当缓冲区达到预设阈值时触发摘要过程，利用LLM将缓冲区内容与现有摘要合并生成新的综合摘要，清空缓冲区并保留更新后的摘要。

 # --- 策略3：摘要内存 ---  
# 这种策略旨在通过定期摘要来管理长对话。
# 它保留最近消息的缓冲区。当缓冲区达到一定大小时，
# 它使用LLM调用将缓冲区内容与运行摘要合并。
# 这保持上下文大小可管理，同时保留对话的要点。
# 主要风险是如果摘要不完美会丢失信息。
class SummarizationMemory(BaseMemoryStrategy):  
    def __init__(self, summary_threshold: int = 4): # 默认：4条消息后摘要（2轮）  
        """  
        初始化摘要内存。
          
        Args:  
            summary_threshold: 触发摘要前在缓冲区中累积的消息数量（用户+AI）。
        """  
        # 存储到目前为止对话的持续更新摘要
        self.running_summary = ""  
        # 一个临时列表，用于在摘要之前保存最近的消息
        self.buffer = []  
        # 触发摘要过程的阈值
        self.summary_threshold = summary_threshold  

    def add_message(self, user_input: str, ai_response: str):  
        """  
        将新的用户-AI交互添加到缓冲区。如果缓冲区大小
        达到阈值，它会触发内存合并过程。
        """  
        # 将最新的用户和AI消息附加到临时缓冲区
        self.buffer.append({"role": "user", "content": user_input})  
        self.buffer.append({"role": "assistant", "content": ai_response})  

        # 检查缓冲区是否已达到其容量
        if len(self.buffer) >= self.summary_threshold:  
            # 如果是，调用方法来摘要缓冲区的内容
            self._consolidate_memory()  

    def _consolidate_memory(self):  
        """  
        使用LLM摘要缓冲区内容并将其与
        现有运行摘要合并。
        """  
        print("\n--- [Memory Consolidation Triggered] ---")  
        # 将缓冲的消息列表转换为单个格式化字符串
        buffer_text = "\n".join([f"{msg['role'].capitalize()}: {msg['content']}" for msg in self.buffer])  
          
        # 为LLM构造特定提示以执行摘要任务
        # 它提供现有摘要和新对话文本，要求
        # 单个更新的摘要
        summarization_prompt = (  
            f"You are a summarization expert. Your task is to create a concise summary of a conversation. "  
            f"Combine the 'Previous Summary' with the 'New Conversation' into a single, updated summary. "  
            f"Capture all key facts, names, and decisions.\n\n"  
            f"### Previous Summary:\n{self.running_summary}\n\n"  
            f"### New Conversation:\n{buffer_text}\n\n"  
            f"### Updated Summary:"  
        )  
          
        # 用特定系统提示调用LLM获取新摘要
        new_summary = generate_text("You are an expert summarization engine.", summarization_prompt)  
        # 用新生成的合并摘要替换旧摘要
        self.running_summary = new_summary  
        # 清除缓冲区，因为其内容现在已合并到摘要中
        self.buffer = []   
        print(f"--- [New Summary: '{self.running_summary}'] ---")  

    def get_context(self, query: str) -> str:  
        """  
        构造要发送给LLM的上下文。它将长期运行摘要
        与最近消息的短期缓冲区结合。
        'query'参数被忽略，因为此策略提供一般上下文。
        """  
        # 格式化当前缓冲区中的消息
        buffer_text = "\n".join([f"{msg['role'].capitalize()}: {msg['content']}" for msg in self.buffer])  
        # 返回历史摘要和最近的、尚未摘要的消息的组合上下文
         return f"### Summary of Past Conversation:\n{self.running_summary}\n\n### Recent Messages:\n{buffer_text}"

摘要型内存策略的核心创新在于

_consolidate_memory

方法，该方法通过精心设计的提示模板指导LLM生成高质量的摘要。摘要的质量直接影响系统的长期记忆能力，因此提示工程在此策略中显得尤为重要。

# 使用4条消息（2轮）的阈值初始化SummarizationMemory
# 这意味着在第二次完整交互后将生成摘要
summarization_memory = SummarizationMemory(summary_threshold=4)  
# 创建AIAgent并注入摘要内存策略
agent = AIAgent(memory_strategy=summarization_memory)

通过实际测试验证摘要策略的效果：

# --- 开始对话 ---  
# 第一轮：用户提供初始详细信息
agent.chat("I'm starting a new company called 'Innovatech'. Our focus is on sustainable energy.")  
# 第二轮：用户给出更具体的信息。AI响应后，
# 缓冲区将包含4条消息，触发内存合并过程
agent.chat("Our first product will be a smart solar panel, codenamed 'Project Helios'.")  

############ 输出 ############  
==== NEW INTERACTION ====  
User: I am starting a new company called 'Innovatech'. Ou...  
Bot: Congratulations on starting Innovatech! Focusing o ...  
>>>> Tokens: 45 | Response Time: 2.55s  

==== NEW INTERACTION ====  
User: Our first product will be a smart solar panel....  
--- [Memory Consolidation Triggered] ---  
--- [New Summary: The user started a compan ...  
Bot: That is exciting news about  ....  

>>>> Tokens: 204 | Response Time: 3.58s

继续测试以观察摘要策略的长期效果：

# 第三轮：用户添加另一个细节。先前的信息现在只存在于运行摘要中
agent.chat("The marketing budget is set at $50,000.")  
# 第四轮：用户测试代理的内存。发送给LLM的上下文将包含
# AI生成的摘要加上最近的（摘要后）关于预算的消息
agent.chat("What is the name of my company and its first product?")  
# 代理正确回答的能力完全取决于LLM摘要的质量
############ 输出 ############  
...  

==== NEW INTERACTION ====  
User: What is the name of my company and its first product?  
Bot: Your company is called 'Innovatech' and its first product is codenamed 'Project Helios'.  

>>>> Tokens: 147 | Response Time: 1.05s

测试结果显示，摘要策略在第四轮对话中的token消耗相比顺序和滑动窗口方法减少了约50%，这证明了其在token效率方面的显著优势。

然而，摘要策略的局限性在长期对话中会逐渐显现。当对话进行到40轮以上并涉及大量数值或事实细节时，早期的重要信息可能在多次摘要过程中逐渐丢失。这种信息衰减现象表明，对于需要严格保持事实准确性的应用场景，可能需要结合其他策略或引入事实验证机制。

4、基于检索的内存系统

基于检索的内存系统代表了当前AI代理中最先进的内存管理方法，它采用了检索增强生成（RAG）的核心思想。该系统不是简单地存储和检索文本，而是通过向量化技术实现语义级别的智能检索。

基于检索的内存系统的工作流程包括：将每次对话交互转换为向量表示并存储在向量数据库中，当用户提出新查询时，系统将查询同样转换为向量，通过相似性搜索找到最相关的历史交互，只将这些高度相关的信息提供给LLM作为上下文。

 # 导入数值操作和相似性搜索所需的库
import numpy as np  
import faiss  

# --- 策略4：基于检索的内存 ---  
# 这个策略将每个对话片段视为可搜索数据库中的文档。
# 它使用向量嵌入来查找和检索过去最语义相关的信息片段
# 以回答新查询。这是检索增强生成(RAG)背后的核心概念。
class RetrievalMemory(BaseMemoryStrategy):  
    def __init__(self, k: int = 2, embedding_dim: int = 3584):  
        """  
        初始化检索内存系统。
          
        Args:  
            k: 为给定查询检索的最相关文档数量。
            embedding_dim: 嵌入模型生成的向量维度。
                          对于BAAI/bge-multilingual-gemma2，这是3584。
        """  
        # 要检索的最近邻数量
        self.k = k  
        # 嵌入向量的维度。必须与模型的输出匹配
        self.embedding_dim = embedding_dim  
        # 用于存储每个文档的原始文本内容的列表
        self.documents = []  
        # 初始化FAISS索引。IndexFlatL2使用L2（欧几里得）距离执行穷举搜索，
        # 这对于适量的向量是有效的
        self.index = faiss.IndexFlatL2(self.embedding_dim)  

    def add_message(self, user_input: str, ai_response: str):  
        """  
        向内存添加新的对话轮次。轮次的每个部分（用户输入和AI响应）
        被单独嵌入和索引以进行细粒度检索。
        """  
        # 我们将轮次的每个部分存储为单独的文档，以允许更精确的匹配。
        # 例如，查询可能与过去的用户陈述相似，但与同一轮次中的AI响应不同。
        docs_to_add = [  
            f"User said: {user_input}",  
            f"AI responded: {ai_response}"  
        ]  
        for doc in docs_to_add:  
            # 生成文档的数值向量表示
            embedding = generate_embedding(doc)  
            # 仅在成功创建嵌入时继续
            if embedding:  
                # 存储原始文本。此文档的索引将对应
                # 于其在FAISS索引中的向量索引
                self.documents.append(doc)  
                # FAISS需要输入向量是float32的2D numpy数组
                vector = np.array([embedding], dtype='float32')  
                # 将向量添加到FAISS索引，使其可搜索
                self.index.add(vector)  

    def get_context(self, query: str) -> str:  
        """  
        基于与用户查询的语义相似性从内存中找到k个最相关的文档。
        """  
        # 如果索引没有向量，则没有什么可搜索的
        if self.index.ntotal == 0:  
            return "No information in memory yet."  
          
        # 将用户查询转换为嵌入向量
        query_embedding = generate_embedding(query)  
        if not query_embedding:  
            return "Could not process query for retrieval."  
          
        # 将查询嵌入转换为FAISS所需的格式
        query_vector = np.array([query_embedding], dtype='float32')  
          
        # 执行搜索。'search'返回距离和查询向量的k个最近邻的索引
        distances, indices = self.index.search(query_vector, self.k)  
          
        # 使用返回的索引检索原始文本文档
        # 我们检查`i != -1`，因为FAISS可能返回-1表示无效索引
        retrieved_docs = [self.documents[i] for i in indices[0] if i != -1]  
          
        if not retrieved_docs:  
            return "Could not find any relevant information in memory."  
          
        # 将检索到的文档格式化为字符串以用作上下文
         return "### Relevant Information Retrieved from Memory:\n" + "\n---\n".join(retrieved_docs)

基于检索的内存系统的核心优势在于其语义理解能力。通过向量化技术，系统能够理解查询的语义含义，即使用户没有使用完全相同的词汇，也能检索到相关的历史信息。

系统的性能很大程度上取决于嵌入模型的质量和向量数据库的配置。FAISS库提供了多种索引方法，在本实现中选择了

IndexFlatL2

，它使用欧几里得距离进行精确搜索，适合中等规模的向量集合。

 # 使用k=2初始化RetrievalMemory，意味着它将检索前2个最相关的文档
 retrieval_memory = RetrievalMemory(k=2)  
 # 创建AIAgent并注入检索内存策略
 agent = AIAgent(memory_strategy=retrieval_memory)

通过混合主题的对话测试验证检索系统的效果：

 # --- 开始混合主题的对话 ---  
# 第一轮：讨论假期计划。这将作为文档存储
agent.chat("I am planning a vacation to Japan for next spring.")  
# 第二轮：讨论软件项目。这也将作为单独的文档存储
agent.chat("For my software project, I'm using the React framework for the frontend.")  
# 第三轮：更多关于假期的细节
agent.chat("I want to visit Tokyo and Kyoto while I'm on my trip.")  
# 第四轮：更多关于软件项目的细节
agent.chat("The backend of my project will be built with Django.")  

############ 输出 ############  
...  

==== NEW INTERACTION ====  
User: I want to visit Tokyo and Kyoto while I'm on my trip.  
Bot: You're interested in visiting Tokyo and Kyoto...  

 ...

现在测试系统的语义检索能力：

 # --- 测试检索机制 ---  
# 现在，询问关于假期的具体问题
# 代理将把这个查询转换为嵌入并搜索内存
# 它应该发现关于日本、东京和京都的文档在语义上
# 比关于React和Django的文档更接近查询
agent.chat("What cities am I planning to visit on my vacation?")  
# 代理应该检索日本/东京/京都信息并忽略软件项目信息

##### 输出 #####  
==== NEW INTERACTION ====  
User: What cities am I planning to visit on my vacation?  
--- Agent Debug Info ---  
[Full Prompt Sent to LLM]:  
---  
SYSTEM: You are a helpful AI assistant.  
USER: MEMORY CONTEXT  
Relevant Information Retrieved from Memory:  
User said: I want to visit Tokyo and Kyoto while I am on my trip.  
---  
User said: I am planning a vacation to Japan for next spring.  
...  

Bot: You are planning to visit Tokyo and Kyoto while on your vacation to Japan next spring.  

 >>>> Tokens: 65 | Response Time: 0.53s

测试结果完美地展示了基于检索的内存系统的优势：系统成功地从混合主题的对话中检索出与查询最相关的信息，token消耗极低（仅65个token），响应时间快速（0.53秒）。

基于检索的内存系统代表了当前AI代理内存管理的最佳实践，但其实现复杂度相对较高。随着数据规模的增长，系统需要考虑并行处理、索引优化、查询优化等多个方面。尽管如此，这种方法仍然是构建高性能AI代理的首选策略。

5、内存增强变换器技术

除了核心策略之外，AI系统正在实现更复杂的方法，推动着内存管理可能性的边界。内存增强变换器代表了这一领域的前沿发展。

核心概念与原理

我们可以通过一个简单的类比来理解这种技术：想象一个普通的AI就像一个只有一个小记事本的学生，他们一次只能写一点点。在一个长测试中，他们必须擦除旧笔记为新笔记腾出空间。

而内存增强变换器就像给那个学生一堆便签纸。记事本仍然处理当前的工作，但便签帮助他们保存早期的关键信息。

工作流程示例

信息标记：您正在与AI设计一个视频游戏，早期您说希望它设置在太空中且没有暴力。通常，这会在长时间谈话后被遗忘。但有了内存增强功能，AI在"便签"上写下"太空设置，无暴力"。
智能检索：稍后，当您询问"什么角色适合我们的游戏？"时，它检查便签并给出符合您原始愿景的想法，即使几个小时后也是如此。
持久记忆：这就像有一个聪明的助手，记住重要的东西，而不需要您重复。

技术实现

 # --- 策略5：内存增强内存（仿真） ---
# 这个策略模拟内存增强变换器模型的行为。
# 它维护最近对话的短期滑动窗口和单独的
# "内存token"列表，这些是从对话中提取的重要事实。
class MemoryAugmentedMemory(BaseMemoryStrategy):
    def __init__(self, window_size: int = 2):
        """
        初始化内存增强系统。
        
        Args:
            window_size: 要保留在短期内存中的最近轮数。
        """
        # 使用SlidingWindowMemory实例来管理最近的对话历史
        self.recent_memory = SlidingWindowMemory(window_size=window_size)
        # 一个列表，用于存储特殊的、持久的"便签"或关键事实
        self.memory_tokens = []
    
    def add_message(self, user_input: str, ai_response: str):
        """
        将最新轮次添加到最近内存，然后使用LLM调用来决定
        是否应该从此交互创建新的持久内存token。
        """
        # 首先，将新交互添加到短期滑动窗口内存
        self.recent_memory.add_message(user_input, ai_response)
        
        # 为LLM构造提示以分析对话轮次并
        # 确定是否包含值得长期记住的核心事实
        fact_extraction_prompt = (
            f"Analyze the following conversation turn. Does it contain a core fact, preference, or decision that should be remembered long-term? "
            f"Examples include user preferences ('I hate flying'), key decisions ('The budget is $1000'), or important facts ('My user ID is 12345').\n\n"
            f"Conversation Turn:\nUser: {user_input}\nAI: {ai_response}\n\n"
            f"If it contains such a fact, state the fact concisely in one sentence. Otherwise, respond with 'No important fact.'"
        )
        
        # 调用LLM执行事实提取
        extracted_fact = generate_text("You are a fact-extraction expert.", fact_extraction_prompt)
        
        # 检查LLM的响应是否表明发现了重要事实
        if "no important fact" not in extracted_fact.lower():
            # 如果找到事实，打印调试消息并将其添加到内存token列表
            print(f"--- [Memory Augmentation: New memory token created: '{extracted_fact}'] ---")
            self.memory_tokens.append(extracted_fact)
    
    def get_context(self, query: str) -> str:
        """
        通过结合短期最近对话
        与所有长期、持久内存token的列表来构造上下文。
        """
        # 从短期滑动窗口获取上下文
        recent_context = self.recent_memory.get_context(query)
        # 将内存token列表格式化为可读字符串
        memory_token_context = "\n".join([f"- {token}" for token in self.memory_tokens])
        
        # 返回组合上下文，清楚地分离长期事实和最近聊天
         return f"### Key Memory Tokens (Long-Term Facts):\n{memory_token_context}\n\n### Recent Conversation:\n{recent_context}"

核心方法详解

增强类的实现包含三个关键方法：

__init__(...): 初始化SlidingWindowMemory实例和用于memory_tokens的空列表。
add_message(...): 双重任务方法，将轮次添加到滑动窗口的同时进行额外的LLM调用，判断是否应该提取关键事实并添加到self.memory_tokens。
get_context(...): 通过结合"便签"（memory_tokens）和滑动窗口的最近聊天历史来构造丰富的上下文。

实际应用测试

 # 使用窗口大小2初始化MemoryAugmentedMemory
# 这意味着短期内存只会保存最后两轮
mem_aug_memory = MemoryAugmentedMemory(window_size=2)
# 创建AIAgent并注入内存增强策略
agent = AIAgent(memory_strategy=mem_aug_memory)

# --- 开始对话 ---
# 第一轮：用户提供关键的长期信息
# 代理的事实提取机制应该识别这是重要的并创建内存token
agent.chat("Please remember this for all future interactions: I am severely allergic to peanuts.")

# 第二轮：标准对话轮次
agent.chat("Okay, let's talk about recipes. What's a good idea for dinner tonight?")

# 第三轮：另一个对话轮次。这将把第一轮（过敏警告）
# 推出短期滑动窗口内存
 agent.chat("That sounds good. What about a dessert option?")

关键测试结果

系统成功识别并提取了长期重要信息：

 ==== NEW INTERACTION ====
 User: Please remember this for all future interactions: I am severely allergic to peanuts.
 --- [Memory Augmentation: New memory token created: 'The user has a severe allergy to peanuts.'] ---
 Bot: I have taken note of your long-term fact: You are severely allergic to peanuts. I will keep this in mind...
 
 >>>> Tokens: 45 | Response Time: 1.32s

长期记忆能力验证

关键测试在于验证系统能否在原始信息已从短期内存中消失后，仍能通过长期内存token提供相关建议：

 # --- 测试内存增强 ---
 # 现在，关键测试。原始过敏警告不再在最近聊天上下文中
 # 代理了解过敏的唯一方式是通过访问其长期"内存token"
 agent.chat("Could you suggest a Thai green curry recipe? Please ensure it's safe for me.")
 # 成功的代理将使用持久内存token检查安全性，并可能警告
 # 关于花生，这在泰式菜肴中很常见

测试结果分析

 ==== NEW INTERACTION ====
User: Could you suggest a Thai green curry recipe? Please ensure it is safe for me.
--- Agent Debug Info ---
[Full Prompt Sent to LLM]:
SYSTEM: You are a helpful AI assistant.
USER: MEMORY CONTEXT
Key Memory Tokens (Long-Term Facts):
- The user has a severe allergy to peanuts.

Recent Conversation:
User: Okay, lets talk about recipes...

Bot: Of course. Given your peanut allergy, it is very important to be careful with Thai cuisine as many recipes use peanuts or peanut oil. Here is a peanut-free Thai green curry recipe...

 >>>> Tokens: 712 | Response Time: 6.45s

技术评估与应用前景

这种方法在更大的数据集上表现更佳，特别是当处理需要长期记忆的复杂应用场景时。由于变换器模型的复杂性和某些实现细节的保密性，这种方法可能是更实际的选择。

优势分析：

出色的长期关键信息保留能力
适用于不断发展的长期对话场景
智能化的事实提取机制
为构建可靠个人助手提供强大基础

局限性考虑：

由于额外的LLM调用进行事实提取，策略实现更复杂且成本更高
需要精心设计的事实提取提示工程
对LLM质量和稳定性有较高依赖性
响应时间可能因额外处理而增加

尽管实现复杂度较高，但内存增强变换器技术在构建真正可靠和智能的个人助手方面显示出巨大潜力，特别是在需要长期记忆和上下文理解的应用场景中。

6、多任务分层优化技术

前面的策略将内存视为单一系统，但如果我们能够构建一个更像人类思维的代理，为不同目的拥有不同类型的内存，将会如何？这就是分层内存的核心理念。

人类记忆模式的启发

分层内存是一个复合策略，将多个简单的内存类型组合到分层系统中，为AI代理创建更复杂和有组织的认知架构。让我们考虑人类记忆的工作方式：

工作内存：某人对你说的最后几句话，处理速度快但持续时间短暂
短期内存：今天早上会议的要点，几个小时内可以轻松回忆
长期内存：家庭地址或多年前学到的关键事实，持久且深深植根

分层架构工作流程

分层方法的工作流程体现了多层次的信息处理机制：

工作内存捕获：从捕获用户消息到工作内存开始
重要性评估：检查信息是否足够重要以提升到长期内存
内容提升：提升的内容存储在检索内存中供将来使用
智能检索：对于新查询，搜索长期内存以获取相关上下文
上下文注入：将相关内存注入上下文以生成更好的响应

技术实现架构

 # --- 策略6：分层内存 ---
# 这个策略结合多种内存类型来创建更复杂的、
# 分层系统，模仿人类内存分为短期（工作）
# 和长期存储的划分。
    def __init__(self, window_size: int = 2, k: int = 2, embedding_dim: int = 3584):
        """
        初始化分层内存系统。
        
        Args:
            window_size: 短期工作内存的大小（以轮数计）。
            k: 从长期内存中检索的文档数量。
            embedding_dim: 长期内存的嵌入向量维度。
        """
        print("Initializing Hierarchical Memory...")
        # 级别1：使用滑动窗口的快速、短期工作内存
        self.working_memory = SlidingWindowMemory(window_size=window_size)
        # 级别2：使用检索系统的较慢、持久长期内存
        self.long_term_memory = RetrievalMemory(k=k, embedding_dim=embedding_dim)
        # 一个简单的启发式：触发从工作内存提升到长期内存的关键词
        self.promotion_keywords = ["remember", "rule", "preference", "always", "never", "allergic"]
    
    def add_message(self, user_input: str, ai_response: str):
        """
        将消息添加到工作内存，并根据其内容有条件地将其提升到长期内存。
        """
        # 所有交互都添加到快速、短期工作内存
        self.working_memory.add_message(user_input, ai_response)
        
        # 提升逻辑：检查用户输入是否包含表明
        # 信息重要并应长期存储的关键词
        if any(keyword in user_input.lower() for keyword in self.promotion_keywords):
            print(f"--- [Hierarchical Memory: Promoting message to long-term storage.] ---")
            # 如果找到关键词，也将交互添加到长期检索内存
            self.long_term_memory.add_message(user_input, ai_response)
    
    def get_context(self, query: str) -> str:
        """
        通过结合来自长期和短期内存层的相关信息来构造丰富的上下文。
        """
        # 从工作内存获取最近的上下文
        working_context = self.working_memory.get_context(query)
        # 从长期内存中检索相关内容
        long_term_context = self.long_term_memory.get_context(query)
        
        # 如果长期内存中没有相关内容，只使用工作内存
        if "No information in memory yet" in long_term_context or "Could not find any relevant information" in long_term_context:
            return f"### Recent Context:\n{working_context}"
        else:
            # 否则，结合两个内存层
             return f"### Long-Term Context:\n{long_term_context}\n\n### Recent Context:\n{working_context}"

系统组件分析

分层内存系统的核心特色在于其多层次架构：

__init__(...): 初始化两个内存层级：快速的SlidingWindowMemory用于工作内存，强大的RetrievalMemory用于长期内存。
add_message(...): 所有消息都进入工作内存，但只有包含"提升关键词"的消息才会进入长期内存。
get_context(...): 查询两个内存层级，如果有相关信息，将结果有机结合。

应用场景测试

 # 初始化分层内存系统
hierarchical_memory = HierarchicalMemory(window_size=2, k=2)
# 创建AIAgent并注入分层内存策略
agent = AIAgent(memory_strategy=hierarchical_memory)

# --- 开始对话 ---
# 第一轮：用户提供包含提升关键词的信息
agent.chat("Please remember: I prefer coffee over tea, and I'm allergic to shellfish.")

# 第二轮：普通对话，不会被提升
agent.chat("What's the weather like today?")

# 第三轮：另一个普通对话
agent.chat("Can you tell me about machine learning?")

# 第四轮：这会把第一轮推出工作内存，但长期内存中仍有偏好
 agent.chat("I'd like to learn about programming languages.")

系统表现分析

 ==== NEW INTERACTION ====
 User: Please remember: I prefer coffee over tea, and I'm allergic to shellfish.
 --- [Hierarchical Memory: Promoting message to long-term storage.] ---
 Bot: I've noted your preferences: you prefer coffee over tea and have a shellfish allergy...
 
 >>>> Tokens: 67 | Response Time: 1.45s

长期记忆能力验证

 # --- 测试分层内存 ---
 # 这应该从长期内存中检索过敏信息
 agent.chat("Can you suggest a seafood restaurant for dinner?")
 # 代理应该记住用户的贝类过敏并提供适当的建议

测试结果分析

 ==== NEW INTERACTION ====
User: Can you suggest a seafood restaurant for dinner?
--- Agent Debug Info ---
[Full Prompt Sent to LLM]:
SYSTEM: You are a helpful AI assistant.
USER: MEMORY CONTEXT
Long-Term Context:
Relevant Information Retrieved from Memory:
User said: Please remember: I prefer coffee over tea, and I'm allergic to shellfish.
---
AI responded: I've noted your preferences...

Recent Context:
User: I'd like to learn about programming languages.

Bot: Given your shellfish allergy, I'd recommend being very careful at seafood restaurants. Here are some suggestions for places that can accommodate your dietary restriction...

 >>>> Tokens: 198 | Response Time: 2.14s

系统优势总结

分层内存系统成功地实现了：

将重要信息（过敏偏好）智能提升到长期内存
在查询相关时从长期内存中准确检索信息
有效结合长期和短期上下文提供全面的响应

这种方法结合了多种内存策略的优势，创建了一个更复杂、更接近人类认知模式的内存系统。

7、图形化内存网络架构

概念创新

传统的内存方法将对话视为线性序列，但图形化内存采用了更高级的方法：将对话元素作为节点，将它们的关系作为边。这种方法特别适合需要理解复杂关系和进行逻辑推理的应用场景。

核心优势

图形化内存系统的主要优势在于：

能够建立和维护信息之间的关系
支持复杂的推理查询
提供结构化的知识表示
适合专家系统和知识库应用

8、内存压缩与整合策略

**
**

压缩技术原理

内存压缩策略通过智能算法对历史对话进行压缩和整合，在保持关键信息的同时显著减少存储空间和处理开销。

整合机制

该策略包含多个层次的整合机制：

语义级别的信息合并
时间序列的智能压缩
重要性评分的动态调整
冗余信息的自动过滤

9、类操作系统内存管理

如果我们能为AI代理构建一个类似计算机操作系统内存管理的系统，会产生什么样的效果？这个高级概念直接借鉴了计算机操作系统管理RAM和硬盘的方式。

系统架构类比

让我们通过系统架构的类比来理解：

RAM（随机存取存储器）：计算机用于活动程序的超快内存，价格昂贵但数量有限。对于AI代理，LLM的上下文窗口就是它的RAM——访问速度快但大小严格受限。
硬盘（或SSD）：计算机的长期存储设备，比RAM容量更大、成本更低，但访问速度相对较慢。对于AI代理，这可以是外部数据库或存储历史对话的简单文件系统。

内存管理机制

这个内存策略通过在两个层级之间智能地移动信息来工作：

活动内存（RAM）：最近的对话轮次保存在快速访问的缓冲区中
被动内存（磁盘）：当活动内存满时，最旧的信息被移动到被动的长期存储（“页面换出”）
页面错误处理：当用户查询需要当前不在活动内存中的信息时，触发"页面错误"
页面换入操作：系统访问被动存储，找到相关信息，并将其加载回活动上下文供LLM使用

技术实现

 # --- 策略9：类操作系统内存管理（仿真） ---
# 这个概念策略模仿计算机OS如何管理内存，使用
# 小而快的'活动内存'（RAM）和大而慢的'被动内存'（磁盘）。
class OSMemory(BaseMemoryStrategy):
    def __init__(self, ram_size: int = 2):
        """
        初始化类操作系统内存系统。

        Args:
            ram_size: 在活动内存（RAM）中保留的最大对话轮数。
        """
        self.ram_size = ram_size
        # 'RAM'是一个deque，保存最近的轮次
        self.active_memory = deque()
        # '硬盘'是一个用于存储页面换出轮次的字典
        self.passive_memory = {}
        # 给每个轮次一个唯一ID的计数器
        self.turn_count = 0
    
    def add_message(self, user_input: str, ai_response: str):
        """将轮次添加到活动内存，如果RAM满了，将最旧的轮次页面换出到被动内存。"""
        turn_id = self.turn_count
        turn_data = f"User: {user_input}\nAI: {ai_response}"
        
        # 检查活动内存（RAM）是否已满
        if len(self.active_memory) >= self.ram_size:
            # 如果是，从活动内存中移除最少最近使用的（最旧的）项
            lru_turn_id, lru_turn_data = self.active_memory.popleft()
            # 将其移动到被动内存（硬盘）
            self.passive_memory[lru_turn_id] = lru_turn_data
            print(f"--- [OS Memory: Paging out Turn {lru_turn_id} to passive storage.] ---")
        
        # 将新轮次添加到活动内存
        self.active_memory.append((turn_id, turn_data))
        self.turn_count += 1
    
    def get_context(self, query: str) -> str:
        """提供RAM上下文，如果需要，模拟'页面错误'从被动内存拉取。"""
        # 基础上下文始终是活动内存中的内容
        active_context = "\n".join([data for _, data in self.active_memory])
        
        # 模拟页面错误：检查查询中的任何词是否与被动内存中的内容匹配
        paged_in_context = ""
        for turn_id, data in self.passive_memory.items():
            if any(word in data.lower() for word in query.lower().split() if len(word) > 3):
                paged_in_context += f"\n(Paged in from Turn {turn_id}): {data}"
                print(f"--- [OS Memory: Page fault! Paging in Turn {turn_id} from passive storage.] ---")
        
        # 将活动上下文与任何页面换入的上下文结合
        return f"### Active Memory (RAM):\n{active_context}\n\n### Paged-In from Passive Memory (Disk):\n{paged_in_context}"
    
    def clear(self):
        """清除活动和被动内存存储。"""
        self.active_memory.clear()
        self.passive_memory = {}
        self.turn_count = 0
         print("OS-like memory cleared.")

系统组件解析

__init__(...): 设置固定大小的active_memory``````deque和空的passive_memory``````dictionary
add_message(...): 将新轮次添加到active_memory，如果满了则调用popleft()将最旧的轮次移动到passive_memory（页面换出）
get_context(...): 始终包括active_memory内容，然后在passive_memory中搜索，如果找到匹配项则"页面换入"该数据

实际应用测试

 # 使用RAM大小为2轮的类操作系统内存策略初始化
os_memory = OSMemory(ram_size=2)
agent = AIAgent(memory_strategy=os_memory)

# 开始对话
agent.chat("The secret launch code is 'Orion-Delta-7'.")  # 这是轮次0
agent.chat("The weather for the launch looks clear.")     # 这是轮次1
agent.chat("The launch window opens at 0400 Zulu.")       # 这是轮次2，页面换出轮次0

# 现在，询问页面换出的信息。这应该触发页面错误
 agent.chat("I need to confirm the launch code.")

系统表现分析

 ==== NEW INTERACTION ====
User: The launch window opens at 0400 Zulu.
--- [OS Memory: Paging out Turn 0 to passive storage.] ---
Bot: PROCESSING NEW LAUNCH WINDOW INFORMATION...

==== NEW INTERACTION ====
User: I need to confirm the launch code.
--- [OS Memory: Page fault! Paging in Turn 0 from passive storage.] ---
--- Agent Debug Info ---
[Full Prompt Sent to LLM]:
SYSTEM: You are a helpful AI assistant.
USER: ### MEMORY CONTEXT
### Active Memory (RAM):
User: The weather for the launch looks clear.
User: The launch window opens at 0400 Zulu.
### Paged-In from Passive Memory (Disk):
(Paged in from Turn 0): User: The secret launch code is 'Orion-Delta-7'.

Bot: CONFIRMING LAUNCH CODE: The stored secret launch code is 'Orion-Delta-7'.

 >>>> Tokens: 539 | Response Time: 2.56s

系统优势评估

系统运行完美！代理成功地：