共享选择性持久记忆:让Agentic LLM系统跨会话复用上下文

针对LLM智能体每次会话"失忆"的问题,提出选择性持久化四类可复用上下文的记忆架构。
基于大语言模型的智能体系统在多轮工具调用中面临一个根本困境:每次新会话都会丢弃此前积累的配置、约束与工具使用经验。直接保存完整对话历史虽看似直接,却会造成token浪费,并因无关信息干扰而降低生成质量。为此,研究者提出"共享选择性持久记忆"架构,核心思路是有针对性地识别并跨会话保留四类高价值上下文:任务规格、数据模式、领域约束和工具使用模式。这一设计的关键价值在于在"完全无记忆"与"全量保存"之间找到平衡点,强调筛选智能而非存储容量,对代码生成等需要长期沿用项目约束的场景尤具实用意义。
智能体LLM的"失忆"困境
基于大语言模型(LLM)的智能体系统正在成为代码生成领域的重要工具。这类系统通过多轮工具调用(multi-turn tool use)完成复杂任务,但它们面临一个根本性的上下文难题:每一次会话都从零开始。
上一轮会话中积累的配置选择、领域约束、数据模式(data schemas)以及工具使用模式,在新会话开始时被全部丢弃。这意味着让此前会话变得高效的关键信息无法被继承,智能体不得不反复"重新学习"相同的背景知识,造成显著的效率损失。

为什么不能直接保存全部历史
一个看似直接的解决方案是:把完整的对话历史全部持久化,供后续会话调用。但原文明确指出,这种做法既低效又适得其反。
一方面,完整保存对话历史在token层面极其浪费——冗长的历史记录会迅速消耗上下文窗口的预算。另一方面,更严重的问题在于质量:不相关的上下文会降低生成质量。当智能体被大量无关信息淹没时,它反而更难聚焦于当前任务的核心需求。
换句话说,记忆不是越多越好,关键在于"记住该记住的"。
这里涉及到LLM的一个基本工程约束——上下文窗口(context window)。当前主流LLM的上下文窗口通常以token数量计量(如32K、128K甚至更大),所有输入给模型的文本(包括系统提示、历史对话、工具返回结果等)都需要占用这一有限预算。一旦历史记录累积过多,不仅接近窗口上限,推理成本(按token计费)也会线性上涨。更关键的是,研究表明LLM在处理超长上下文时存在"迷失在中间(lost in the middle)"效应——模型对位于上下文首尾的信息关注度远高于中间部分,大量历史信息混入后反而会稀释真正重要的指令与约束,导致生成质量不升反降。这解释了为何简单堆砌历史并非可行方案。
共享选择性持久记忆的核心思路
针对上述矛盾,原文提出了**共享选择性持久记忆(shared selective persistent memory)**这一记忆架构,专为智能体系统设计。
其命名本身就揭示了三个设计原则:
- 共享(shared):记忆可以在不同会话之间被复用,而非局限于单次交互;
- 选择性(selective):系统不会盲目保存一切,而是有针对性地识别哪些上下文值得保留;
- 持久(persistent):被选中的上下文能够跨会话稳定存续。
这套架构的核心工作,是识别并保留四类可复用的上下文,从而在保证效率的同时,避免无关信息对生成质量的干扰。
四类可复用上下文
根据原文披露,该架构聚焦于四个类别的可复用上下文:
- 任务规格(task specifications):描述智能体需要完成什么,是任务意图的结构化沉淀;
- 数据相关信息:如数据模式(data schemas)等,帮助智能体理解所处理数据的结构与约束;
- 领域约束(domain constraints):特定业务或技术领域内必须遵守的规则;
- 工具使用模式(tool-use patterns):此前会话中被验证有效的工具调用方式。
这四类信息的共同特征是:它们具有跨会话的稳定性和复用价值,而不是仅在单次对话中临时有效的碎片信息。相比之下,一次性的闲聊或临时性的中间推理,往往不属于值得持久化的范畴。
**工具使用模式(tool-use patterns)**值得单独说明,因为它是多轮智能体系统特有的记忆类型。在Agentic LLM场景中,智能体通常拥有一组可调用的外部工具(如代码执行器、数据库查询、API调用等),完成一个复杂任务需要按特定顺序组合调用多个工具。这种调用序列本身就包含了大量隐性知识——比如"在查询数据库之前需要先做格式转换"或"调用某个API时需要附加特定的鉴权参数"。如果这类经验性的调用路径每次都要从零探索,会产生大量冗余的试错开销。将验证有效的工具使用模式持久化,本质上是在保存智能体通过"实践"习得的操作经验,类似于人类工程师积累的操作手册或最佳实践文档。
这一设计对智能体工程的意义
从工程实践的角度看,共享选择性持久记忆试图回答一个正在困扰智能体开发者的现实问题:如何让智能体系统在长期使用中越来越"懂"你,而不是每次都从头解释一遍?
对于代码生成场景尤其如此。开发者在一个项目中往往有固定的技术栈、代码规范、数据结构和常用工具链。如果智能体能够持久记住这些约束,就能在后续会话中直接产出符合项目习惯的代码,减少反复的沟通成本。
选择性带来的平衡
该方案最值得关注的价值,在于它在"记忆"与"精简"之间寻求平衡。完全无记忆的系统效率低下,而记忆过载的系统则会因为噪声干扰而退化。选择性持久化通过对上下文进行分类筛选,试图找到那个既能保留关键知识、又不至于污染上下文窗口的中间地带。
这也反映出智能体记忆研究的一个共识方向:记忆架构的关键不在存储容量,而在检索与筛选的智能程度。
在智能体记忆研究领域,目前已有几种主流的记忆管理思路可供对比参考。**RAG(检索增强生成)**通过向量检索从外部知识库中动态拉取相关片段,解决的是外部知识获取问题,但并不天然处理会话间的上下文积累。记忆压缩(memory compression)则尝试对历史对话做摘要蒸馏,保留语义核心并丢弃细节,但压缩过程可能损失结构化约束信息。共享选择性持久记忆的思路更接近记忆分类存储——预先定义哪些类型的信息值得保留,而非对全部历史做无差别处理。这种分类优先的设计使得筛选逻辑更可解释,也更易于工程实现与维护。
小结与观察
共享选择性持久记忆为多轮工具调用的智能体LLM系统提供了一种结构化的记忆思路。它将可复用上下文明确划分为任务规格、数据信息、领域约束和工具使用模式四类,既避免了"从零开始"的重复劳动,也规避了"全量保存"带来的token浪费与质量下降。
需要说明的是,本文基于原始摘要撰写,原文的具体实现细节、评测数据与实验结果尚未在摘要中充分展开。这一架构在实际系统中的性能表现、记忆更新与冲突处理机制,仍有待完整论文进一步验证。对于关注智能体记忆与长期上下文管理的研究者和工程师而言,这类工作提供了一个值得追踪的方向。
相关推荐

AI Agent审批工作流:如何处理编辑与重试
详解AI Agent人工审批工作流的设计要点:如何审阅精确请求、恢复执行,以及处理编辑与重试。以Airlock为例,探讨Agent走向生产环境所需的安全与可控机制。

MCP授权治理:为什么工具调用需要超越OAuth的安全防线
MCP工具调用为何需要超越OAuth的授权治理?本文解析工具权限的执行位置、请求内容检查与数据泄露测试,并介绍Airlock如何为AI代理的工具调用建立分层安全防线。

如何区分AI Agent流量与真实用户流量
AI Agent流量正被访问日志误记为真实用户行为。本文解读如何通过身份声明机制区分Agent流量与用户流量,帮助开发者与平台还原真实数据、优化风控策略。