1. 项目概述当智能体“失忆”时我们如何动态扩容它的记忆最近在折腾各种语言智能体Language Agents项目时我遇到了一个既普遍又棘手的问题内存溢出。无论是本地跑一个开源的大模型服务还是部署一个复杂的多智能体协作系统控制台里冷不丁冒出的“OutOfMemoryError”、“memory access violation”或者“insufficient memory”错误总能瞬间让开发者的血压飙升。这些错误背后往往指向一个核心矛盾——静态预分配的内存难以应对动态、不可预测的任务负载。想象一下你设计了一个能帮你分析长文档、编写复杂代码的智能体。在开发测试阶段它运行良好。但当你把它部署上线面对用户抛来的一个长达数百页的PDF分析请求时它突然“卡住”了然后崩溃留下一句冰冷的“内存不足”。问题不在于智能体不够聪明而在于它的“记忆”容量是固定的就像给一个学生一个固定大小的笔记本让他去记录一场持续数天的学术会议——笔记迟早会写满重要的信息会被迫丢弃。这正是“AdaMEM: Test-Time Adaptive Memory for Language Agents”这个研究方向试图解决的核心痛点。它不是一个具体的工具或SDK而是一种方法论和架构思想。其核心目标是让语言智能体在实际运行Test-Time过程中能够根据当前任务的实际需求自适应地Adaptive调整和管理其记忆Memory资源。简单说就是让智能体学会“按需记忆”在资源有限的情况下优先记住最重要的信息动态释放或压缩次要信息从而避免崩溃并提升处理复杂、长程任务的能力。从网络上的热议也能看出无论是开发层面的“Java: OutOfMemoryError”、“claude code memory”还是部署运维时的“TencentDB agent memory”、“process exited with code 3221225477”内存管理都是智能体走向实用化必须跨过的一道坎。AdaMEM的思路正是将内存从一个静态的、被动的“硬件限制”转变为一个动态的、可被智能体主动管理的“认知资源”。接下来我将结合架构设计、算法策略和工程实践深入拆解如何为你的语言智能体构建一个“自适应记忆系统”。这不是某个框架的简单使用教程而是一套从问题本质出发到落地实现的完整方案。2. 静态内存管理的困局为什么固定大小的记忆是个灾难在深入自适应方案之前我们必须先理解传统做法的局限性。大多数语言智能体项目在内存管理上可以概括为三种初级策略而这每一种都埋藏着隐患。2.1 策略一固定上下文窗口与粗暴截断这是最普遍的做法。无论是使用OpenAI API上下文长度如128K还是本地部署模型如Llama 3的8K/128K我们通常会在初始化时设定一个最大的上下文窗口Context Window或对话轮次。所有的人类输入、模型输出、系统指令和历史对话都塞进这个窗口。问题所在 当对话或任务流程超过这个窗口时常见的做法是从头部或中部开始丢弃最早的历史信息。这带来了“失忆”问题。例如在一个多轮调试对话中智能体可能完全忘记了最初用户提出的核心需求在一个长文档分析任务中它可能丢失了文档开头的关键定义和前提假设。这种失忆是毁灭性的会导致后续的推理完全偏离轨道。网络上“agent记忆”相关的讨论很多都源于此。工程上的体现你会在代码中看到一个硬编码的max_tokens或max_history_turns参数。当len(all_messages) max_history_turns时执行pop(0)。这种做法简单但智能。2.2 策略二向量数据库作为“外部记忆”为了突破上下文窗口限制一个流行的方案是引入向量数据库如Chroma、Milvus、Pinecone。将历史对话、文档片段转换成向量嵌入Embeddings存储起来需要时通过语义检索召回相关片段再注入当前的上下文窗口。这听起来很完美但实操中陷阱重重检索不一定精准语义搜索并非精确匹配。它可能召回大量相关但冗余的信息或者漏掉关键信息。这会导致注入窗口的内容质量不稳定有时甚至引入噪声。上下文污染与成本激增每次检索到的内容都需要被插入到当前对话的上下文里这会挤占原本用于当前思考和输出的令牌数。如果检索过多不仅可能降低回复质量还会显著增加API调用成本对于按Token计费的云服务或本地推理延迟。无法记忆复杂逻辑与状态向量数据库擅长记忆“事实片段”但对于多步推理中的中间状态、智能体自身的决策逻辑、用户的临时偏好等动态的、结构化的“程序性记忆”其表达能力不足。额外的复杂性与延迟引入了一个新的系统组件带来了数据同步、嵌入模型选择、索引维护等一系列工程问题也增加了请求的响应延迟。2.3 策略三任务链与子任务分解将大任务拆解成子任务每个子任务在一个干净的上下文环境中执行只传递必要的参数。这确实能控制单个步骤的内存使用。然而其弊端在于“上下文碎片化” 智能体在处理子任务B时可能完全丢失了处理子任务A时获得的宝贵洞察和临时结论。虽然可以通过在子任务间传递“摘要”来缓解但摘要的过程本身就是信息压缩和丢失的过程。智能体失去了对任务全局的、连贯的把握更像一个机械执行流水线指令的工人而非一个通盘考虑的战略家。这三种策略的共同点是内存的管理策略是静态的、预先定义好的无法根据运行时任务的真实复杂度和信息密度进行动态调整。AdaMEM要做的就是设计一套机制让智能体自己学会在运行时决定记住什么记住多久以什么形式记住以及忘记什么3. AdaMEM核心架构一个分层的动态记忆系统AdaMEM不是一个单一的算法而是一个系统架构。我将其核心思想归纳为一个分层、动态、可评估的记忆管理系统。它包含以下几个关键组件3.1 记忆分层从工作记忆到长期档案模仿人类的记忆系统我们将智能体的记忆划分为不同层级每层有不同的容量、存取速度和遗忘机制。工作记忆Working Memory类比大脑中正在思考的内容容量极小7±2个组块但存取速度极快。实现即模型当前的上下文窗口。所有直接参与当前一步推理的信息都必须在此。AdaMEM的关键在于动态管理这一层的内容。容量动态可变但受模型最大上下文长度硬性限制。短期记忆Short-Term Memory类比最近几分钟到几小时的经历可以通过复述转入长期记忆。实现一个在内存中的、结构化的缓冲区如一个列表或队列。存储最近多轮的完整对话、任务执行的中间结果、用户的近期反馈等。管理策略基于时间衰减或重要性评分进行淘汰。当工作记忆需要更多空间时短期记忆中最不重要的内容会被移出或压缩。长期记忆Long-Term Memory类比经过深度处理的知识和经验。实现通常由向量数据库存储事实性知识和关系型数据库或键值存储存储结构化状态、用户画像、技能参数等共同构成。管理策略写入相对谨慎需要经过重要性过滤。读取通过检索完成。可以实施更复杂的归档和清理策略如基于最后访问时间、使用频率。记忆索引与元数据层这是实现“自适应”的大脑皮层。它为每一段记忆无论存放在哪一层维护元数据例如重要性评分Importance Score一个动态计算的数值表示这段信息对当前及未来任务的关键程度。访问频率Access Frequency被检索或使用的次数。最后访问时间Last Accessed Time。关联任务Related Tasks这段记忆与哪些任务或目标相关。信息类型Type是事实、指令、推理步骤、用户偏好还是错误日志。这个索引层是智能体进行记忆决策记住、遗忘、压缩、召回的核心依据。3.2 自适应流程记忆的写入、读取与遗忘有了分层架构自适应就体现在内存管理的各个环节1. 写入时的评估与分流Adaptive Encoding 每当有新信息产生用户输入、模型输出、工具调用结果不是直接塞进工作记忆或存入数据库而是先经过一个“记忆评估器”。# 伪代码示意 def encode_memory(raw_info, current_context): # 1. 提取关键特征 features extract_features(raw_info) # 如信息长度、实体密度、情感强度、与当前任务的相关性 # 2. 预测重要性评分 (可使用一个轻量级模型或启发式规则) importance_score predict_importance(features, current_context) # 3. 基于评分和当前系统负载决定存储策略 memory_strategy decide_storage_strategy(importance_score, system_memory_load) if memory_strategy WORKING_MEMORY: # 直接放入工作记忆上下文窗口 insert_into_context(raw_info) elif memory_strategy SHORT_TERM_BUFFER: # 放入短期缓冲区并附加元数据 store_in_buffer(raw_info, importance_score) elif memory_strategy LONG_TERM_ARCHIVE: # 进行结构化处理如生成摘要、提取关键点然后存入长期记忆 processed_info summarize_or_extract(raw_info) store_in_long_term(processed_info, importance_score) elif memory_strategy DISCARD: # 认为不重要直接丢弃或仅记录日志 log_discarded_info(raw_info)这个decide_storage_strategy函数是自适应的核心。例如当系统检测到当前上下文令牌使用率已超过80%时它会大幅提高信息进入工作记忆的“重要性门槛”将更多信息分流到缓冲区或长期记忆甚至直接丢弃低价值信息。2. 读取时的精准检索与重构Adaptive Retrieval 当智能体需要历史信息时不是简单地从向量数据库做相似性搜索。基于元数据的过滤首先记忆索引层会根据当前任务的目标从元数据中筛选出高重要性、高相关性的记忆候选集。动态重构工作记忆然后系统会根据当前工作记忆的剩余空间从候选集中选择最优组合注入。这可能不是简单的“Top-K”而是一个优化问题在有限的令牌预算内选择能最大程度提升当前任务成功率的信息集合。摘要与重组对于过长的记忆片段在注入前可能进行实时摘要只保留最精炼的核心。这比固定的“截断”要智能得多。3. 运行时的遗忘与压缩Adaptive Forgetting/Compression 这是最体现“Test-Time Adaptation”的地方。系统会持续监控内存使用状态如工作记忆令牌数、缓冲区大小。被动触发当工作记忆将满时系统自动启动“清理”程序。主动优化即使内存未满系统也可能定期运行“记忆整理”后台任务评估所有记忆的重要性对低重要性记忆进行降级从工作记忆移到缓冲区、压缩或删除。压缩策略对于文本记忆压缩可以是生成一个更短的摘要。对于结构化状态压缩可以是只保留关键字段或聚合值。关键技巧压缩后的内容其元数据中需要包含指向原始内容的指针或哈希以便在必要时可以尝试从更完整的存储层如长期记忆中恢复细节。4. 核心算法如何量化“记忆的重要性”整个自适应系统的基石是如何计算那段“重要性评分”。这是一个非常实际的问题我分享几种在实践中混合使用的策略4.1 基于启发式规则的基础评分这是一套快速、可解释的规则能为所有记忆提供一个初始重要性基线。来源权重系统指令 用户最新输入 工具成功返回结果 模型自身推理输出 工具错误信息。信息密度包含命名实体人名、地点、专业术语、数字、特定关键词如“关键”、“总结”、“错误”、“目标”的语句给予更高权重。可以使用简单的TF-IDF或关键词匹配来评估。新鲜度衰减重要性随时间呈指数衰减。current_importance base_importance * exp(-decay_rate * time_elapsed)。最新信息总是更相关。确认与反馈被用户明确肯定如“对的”、“很好”或作为后续问题依据的信息其重要性应被显著提升。反之被用户纠正的信息其重要性可能降低或标记为“待核实”。4.2 基于轻量级模型的预测评分对于更复杂的场景可以训练一个小的分类或回归模型来预测重要性。这个模型的训练数据可以从智能体与人类的交互日志中构建。特征工程文本特征长度、嵌入向量的范数粗略表示信息量、与对话目标的余弦相似度。上下文特征出现在对话的哪个阶段开头、中间、结尾、位于哪一轮。行为特征该条信息之后是否立刻引发了工具调用、是否改变了对话主题。后续影响特征在未来的N轮对话中该信息被显式或隐式引用的次数。模型选型由于需要在运行时快速推断模型必须非常轻量。逻辑回归、小型神经网络如2层MLP或梯度提升树如LightGBM都是不错的选择。目标变量可以是二分类重要/不重要或回归重要性分数0-1。在线学习模型可以在运行中持续微调。例如当一段记忆被频繁检索时这是一个正反馈信号可以用于增强学习提高该段记忆及其相似记忆的分数。4.3 基于任务目标的动态重评估重要性不是一成不变的。一段记忆的重要性会随着当前任务目标的变化而动态变化。实现机制在智能体执行每一步之前或当任务目标被更新时系统可以用当前的任务描述作为查询对所有相关的短期和长期记忆进行一次“相关性重评估”。示例在一个旅行规划智能体中当用户的目标从“查找航班”切换到“预订酒店”时之前关于航班时间、机场的信息重要性会下降而关于目的地、预算、日期的信息重要性会上升。系统应能动态调整这些记忆的优先级在需要时为“预订酒店”子任务提供最相关的上下文。实操心得不要追求一个完美的、通用的重要性模型。最好的策略是“规则打底模型优化动态调整”。先从一组简单的启发式规则开始让系统跑起来收集日志数据。然后用这些数据去训练和迭代你的预测模型。在实际部署中将规则分数和模型预测分数进行加权融合往往能取得更稳定、更可解释的效果。5. 工程实现从理论到可运行的代码理论很美好但如何落地这里我以一个基于Python和LangChain或类似框架的智能体项目为例勾勒出AdaMEM的核心模块实现思路。5.1 定义记忆数据结构首先我们需要一个丰富的数据结构来承载记忆及其元数据。from dataclasses import dataclass from datetime import datetime from typing import Any, Dict, List, Optional from enum import Enum class MemoryType(Enum): USER_INPUT user_input AGENT_RESPONSE agent_response TOOL_RESULT tool_result SYSTEM_EVENT system_event INTERNAL_THOUGHT internal_thought dataclass class MemoryChunk: 记忆块存储信息的基本单位 id: str # 唯一标识如UUID content: str # 原始文本内容 type: MemoryType # 记忆类型 timestamp: datetime # 创建时间 # --- 元数据 --- importance_score: float # 动态重要性评分范围[0, 1] access_count: int 0 # 被访问次数 last_accessed: Optional[datetime] None # 最后访问时间 related_goals: List[str] None # 关联的任务目标ID列表 embedding: Optional[List[float]] None # 向量嵌入用于检索 compressed_version: Optional[str] None # 压缩后的内容 parent_id: Optional[str] None # 如果这是某个记忆的压缩版指向原记忆 def to_dict(self) - Dict[str, Any]: return {field: getattr(self, field) for field in self.__dataclass_fields__}5.2 实现分层记忆存储管理器这是一个核心类负责记忆的增删改查和层级调度。class AdaptiveMemoryManager: def __init__(self, llm_client, embedding_model, max_working_tokens8000, short_term_capacity50): self.llm llm_client self.embedder embedding_model self.max_working_tokens max_working_tokens self.short_term_capacity short_term_capacity # 短期记忆最多存储多少条 # 存储层 self.working_memory: List[MemoryChunk] [] # 当前上下文中的记忆 self.short_term_buffer: List[MemoryChunk] [] # 内存中的短期缓冲区 self.long_term_vector_store ... # 初始化向量数据库客户端 self.long_term_kv_store ... # 初始化键值数据库如Redis用于结构化记忆 # 评估器可以是规则引擎或模型 self.importance_evaluator RuleBasedEvaluator() # 后期可替换为ModelBasedEvaluator async def add_memory(self, raw_content: str, mem_type: MemoryType, current_goal: str None): 自适应添加记忆的核心入口 # 1. 创建基础记忆块 new_chunk MemoryChunk( idstr(uuid.uuid4()), contentraw_content, typemem_type, timestampdatetime.now(), importance_score0.0, # 初始化为0等待评估 related_goals[current_goal] if current_goal else [] ) # 2. 评估初始重要性 new_chunk.importance_score await self.importance_evaluator.evaluate(new_chunk, self.working_memory) # 3. 计算当前工作记忆负载估算Token数 current_working_tokens self._estimate_tokens(self.working_memory) # 4. 决策存储位置 if new_chunk.importance_score 0.8 or current_working_tokens self.max_working_tokens * 0.6: # 重要性极高或内存充裕直接放入工作记忆 self.working_memory.append(new_chunk) self._maybe_compress_working_memory() # 触发压缩检查 elif new_chunk.importance_score 0.4: # 中等重要性放入短期缓冲区 self.short_term_buffer.append(new_chunk) self._manage_short_term_buffer() # 管理缓冲区容量 else: # 低重要性进行深度处理后存入长期记忆或丢弃 if new_chunk.importance_score 0.1: processed await self._summarize_for_long_term(new_chunk) await self.long_term_vector_store.add(processed) # 否则可以记录日志后丢弃 else: logger.debug(fDiscarding low-importance memory: {new_chunk.content[:100]}...) # 5. 为新记忆生成嵌入异步进行不阻塞主流程 asyncio.create_task(self._generate_embedding(new_chunk)) def _maybe_compress_working_memory(self): 当工作记忆接近上限时压缩重要性最低的记忆 current_tokens self._estimate_tokens(self.working_memory) if current_tokens self.max_working_tokens * 0.9: # 达到90%阈值 # 按重要性排序找到最不重要的记忆 self.working_memory.sort(keylambda x: x.importance_score) least_important self.working_memory[0] # 尝试压缩它例如用LLM生成一句话摘要 compressed_content self._compress_chunk(least_important) least_important.compressed_version compressed_content # 更新其内容为压缩版释放空间 original_content least_important.content least_important.content compressed_content logger.info(fCompressed working memory chunk. Original: {original_content[:50]}...) # 将原始完整内容转移到短期缓冲区并更新其重要性因为被压缩重要性可能降低 backup_chunk dataclasses.replace(least_important, contentoriginal_content, idstr(uuid.uuid4())) backup_chunk.importance_score * 0.7 # 降权 self.short_term_buffer.append(backup_chunk) async def retrieve_relevant_memories(self, query: str, current_goal: str, top_k: int 5) - List[MemoryChunk]: 根据查询和当前目标从所有记忆层中检索最相关的信息 relevant_memories [] # 1. 从工作记忆中筛选本来就全在上下文中这里主要是为了排序和选择注入 # 通常工作记忆全部保留除非特别长这里略过。 # 2. 从短期缓冲区中基于元数据和简单相似度筛选 for chunk in self.short_term_buffer: relevance self._calculate_relevance(chunk, query, current_goal) if relevance 0.5: # 相关性阈值 relevant_memories.append((chunk, relevance)) # 3. 从长期向量存储中做语义检索 vector_results await self.long_term_vector_store.similarity_search(query, ktop_k*2) # 多查一些 for doc in vector_results: # 假设doc.metadata中存储了我们的MemoryChunk序列化数据 chunk MemoryChunk(**doc.metadata) chunk.relevance_to_query self._calculate_relevance(chunk, query, current_goal) relevant_memories.append((chunk, chunk.relevance_to_query)) # 4. 按综合相关性排序相关性分数 * 当前重要性评分 relevant_memories.sort(keylambda x: x[1] * x[0].importance_score, reverseTrue) # 5. 更新被选中记忆的元数据增加访问计数更新最后访问时间 for chunk, _ in relevant_memories[:top_k]: chunk.access_count 1 chunk.last_accessed datetime.now() # 被成功检索本身就是一个正反馈可以略微提升其重要性 chunk.importance_score min(1.0, chunk.importance_score * 1.05) return [chunk for chunk, _ in relevant_memories[:top_k]]5.3 与智能体主循环集成最后我们需要将这个记忆管理器嵌入到智能体的执行循环中。class AdaptiveLanguageAgent: def __init__(self, memory_manager: AdaptiveMemoryManager, tools: List): self.memory memory_manager self.tools tools async def run(self, user_input: str, session_id: str): # 1. 将用户输入作为记忆存储并关联当前会话目标 current_goal self._infer_goal(user_input) # 从输入中推断或维持上一个目标 await self.memory.add_memory(user_input, MemoryType.USER_INPUT, current_goal) # 2. 检索相关记忆准备上下文 relevant_memories await self.memory.retrieve_relevant_memories(user_input, current_goal) # 3. 构建最终的提示词上下文动态组装工作记忆 prompt_context self._construct_prompt( system_instructionself._get_system_prompt(), working_memoriesself.memory.working_memory, # 当前工作记忆 retrieved_memoriesrelevant_memories, # 检索到的相关记忆 current_goalcurrent_goal, user_inputuser_input ) # 4. 检查上下文长度如果超限触发更激进的记忆压缩或淘汰 if self._estimate_tokens(prompt_context) self.memory.max_working_tokens: await self.memory._emergency_memory_trim(prompt_context) # 重新构建prompt_context... # 5. 调用LLM生成思考和行动 llm_response await self.llm.generate(prompt_context) # 6. 解析LLM响应执行工具调用如果有 tool_calls self._parse_tool_calls(llm_response) tool_results [] for call in tool_calls: result await self._execute_tool(call) tool_results.append(result) # 将工具调用和结果也作为记忆存储 await self.memory.add_memory(fTool {call[name]} called with args: {call[args]}, MemoryType.SYSTEM_EVENT, current_goal) await self.memory.add_memory(fTool result: {result}, MemoryType.TOOL_RESULT, current_goal) # 7. 生成最终回复并存储 final_response await self._synthesize_response(llm_response, tool_results) await self.memory.add_memory(final_response, MemoryType.AGENT_RESPONSE, current_goal) # 8. 可选定期后台任务整理和优化记忆 if random.random() 0.1: # 10%的概率触发整理 asyncio.create_task(self.memory.periodic_memory_maintenance()) return final_response工程上的注意事项性能开销重要性评估、向量检索、实时压缩都会带来延迟。需要将这些操作尽可能异步化并且为评估模型和压缩模型设置严格的超时限制。复杂性管理引入了大量状态记忆块、元数据。必须设计完善的数据持久化方案确保智能体重启后记忆不丢失。同时要为记忆系统本身配备监控和调试工具例如记录每次记忆淘汰的原因、重要性分数的变化曲线等。评估与调优没有银弹参数。重要性阈值、压缩触发线、衰减率等都需要在实际任务流上进行A/B测试来调优。可以设定一些可量化的指标如“任务完成率”、“平均对话轮次”、“内存溢出发生率”来评估不同参数配置的效果。6. 避坑指南实现自适应记忆时常见的“坑”在实际构建这样一个系统时我踩过不少坑这里分享几个关键的教训坑一过度优化陷入循环。早期版本中我的重要性评估模型过于复杂其推断耗时甚至超过了LLM生成主要回复的时间。同时记忆管理系统频繁地压缩、重组记忆导致智能体花费大量“脑力”在管理记忆上而不是解决用户问题。解决方案遵循“奥卡姆剃刀”原则。先从最简单的基于规则和新鲜度的策略开始确保它带来的收益减少OOM错误、提升长任务性能明显大于其开销。之后再进行精细化迭代。坑二记忆污染与幻觉加强。如果记忆检索不够精准或者将模型之前生成的、包含错误的推理步骤也作为高重要性记忆存储并频繁召回会导致错误被不断强化智能体陷入“幻觉循环”。解决方案对模型自身生成的内容AGENT_RESPONSE,INTERNAL_THOUGHT给予较低的基础重要性权重。引入“置信度”或“验证状态”元数据。对于工具返回的事实性结果可以标记为“已验证”对于模型的推理标记为“待验证”。在检索时优先召回高置信度的记忆。定期运行“记忆清理”任务寻找并降权那些与其他记忆存在事实矛盾的内容。坑三状态不一致与调试地狱。当记忆分散在工作内存、缓冲区、向量库、键值库等多个地方并且内容会被动态压缩和修改时整个系统的状态变得极其复杂。复现一个特定时间点的智能体“心智状态”几乎不可能给调试带来了巨大挑战。解决方案为所有记忆操作添加审计日志记录每个记忆块的完整生命周期创建、评分、存储位置变更、压缩、检索、删除并关联唯一的会话ID和请求ID。实现记忆快照与回放定期或在关键决策点将整个记忆系统的状态包括所有存储层的内容和元数据序列化保存。当出现异常回复时可以加载快照进行离线分析和复现。提供可视化工具开发一个简单的内部看板能够实时展示当前会话的记忆图谱包括各记忆块的重要性分数、存储位置和关联关系。坑四对“遗忘”的恐惧。开发者本能地希望智能体记住一切导致重要性阈值设置过低几乎所有信息都被长期保存系统最终变得臃肿不堪检索效率下降。解决方案接受“遗忘”是高效认知的必要组成部分。设计明确的记忆生命周期策略。例如可以设定除非用户明确要求记住否则所有会话记忆在24小时后自动标记为低重要性一周后未被访问的长期记忆自动归档到冷存储只有重要性评分持续高于某个阈值且被多次访问的记忆才被视为“核心知识”永久保留。实现AdaMEM这样的自适应记忆系统是一个在“智能体性能”、“资源消耗”和“系统复杂性”之间寻找精妙平衡的过程。它没有标准答案但其核心思想——让智能体具备动态管理自身认知资源的能力——无疑是构建强大、鲁棒、实用的语言智能体的必经之路。从我自己的实践来看即使只实现了最基本的重要性评分和分层存储也能让智能体在面对长文档、多轮复杂对话时的崩溃率下降一个数量级其回复的连贯性和相关性也有肉眼可见的提升。这其中的每一分开销在提升用户体验和任务成功率面前都是值得的。