新代理记忆框架 MRAgent：单次查询仅需 11.8 万 Token，大幅优于 LangMem

长时序推理暴露出人工智能代理的一个核心弱点：上下文窗口会迅速被填满，而检索管道往往返回噪声而非信号。 为了解决这一问题，新加坡国立大学的研究人员开发了MRAgent——一个摒弃静态“先检索再推理”模式的框架。相反，它采用了一种机制，使代理能够根据不断积累的证据，动态地扩展其记忆库。 这种多步骤的记忆重建被整合进大型语言模型（LLM）的推理流程中。尽管MRAgent并非该领域的唯一框架，但与其它代理式记忆管理方法相比，它显著降低了令牌消耗和运行时成本。

在长时序任务中，被动检索的局限性 在经典的检索管道中，文档通过向量搜索或图遍历被检索出来，并传递给LLM进行推理。然而，这种被动的方式存在缺陷：它无法将推理与内存访问有机结合，从而导致三大瓶颈： • 这些系统无法在推理过程中随时调整检索策略。如果代理获取了一份文档，并发现其中缺少了一个关键线索——例如特定的日期或人物——它就无法根据这一发现重新发起新的查询。 • 固定的相似度分数和预定义的图扩展方式，只能返回表面化的匹配结果，这些结果会以无关的噪声充斥LLM的上下文窗口，从而削弱推理效果。 • 目前的系统严重依赖于预先构建的结构，如top-k结果和静态相关性函数，这限制了其灵活性，难以应对那些不可预测、长时序的用户交互。 研究人员认为，要克服这些局限性，开发者必须转向“主动且关联式的记忆重建过程”，这一概念源自认知神经科学。 在此范式下，记忆的回忆是按顺序展开的，而非像传统方式那样被动地从静态数据库中读取信息。系统首先从用户提示中的小而具体的触发点入手，例如某个人的名字、某个动作或某个地点。这些初始提示旨在引导用户连接不同的概念或类别，而非直接处理海量文本。 通过遵循这些元数据的“台阶式”引导，代理会逐一收集细小的证据。它利用每一条新获得的信息来指导下一步行动，直至成功拼凑出完整而准确的故事。

MRAgent如何实现主动的记忆重建 MRAgent（面向LLM代理的记忆推理架构）不将记忆视为静态数据库，而是将其视作一个交互式环境。在处理复杂查询时，代理会借助基础LLM的推理能力，在结构化的记忆图中探索多条候选检索路径。 在每一步中，LLM会评估其已收集的中间证据，并利用这些证据对搜索过程进行迭代优化。它会推断出新的搜索约束条件，追寻信息最丰富的路径，并剪枝掉不相关的分支。这样一来，MRAgent便能在不向LLM的上下文窗口中塞满噪声的情况下，完整地拼凑起深藏于记忆中的信息。 为了使这种主动式探索在计算上更加高效且可扩展，该框架采用了“提示-标签-内容”的机制来组织数据库。这一机制构建了一个多层关联图，包含三种节点类型： • 提示：细粒度的关键字，例如从用户交互中提取的实体或上下文属性。 • 内容：实际存储的记忆单元。这些内容被划分为多个层次，例如针对具体事件的片段式记忆，以及用于稳定事实和用户偏好的语义记忆。 • 标签：用以概括特定提示与内容之间关系联结的语义桥梁。 这种结构实现了高度高效的两阶段检索流程。LLM首先从提示中从提示出发，逐步导航至候选标签。由于标签清晰地揭示了数据的语义关系和结构关联，代理会评估这些简短的摘要，以判断其相关性。LLM会识别出有潜力的搜索路径，并在耗费计算资源和提示令牌去访问详细而沉重的记忆内容之前，果断舍弃不相关的分支。 举例来说，一位用户可能会问AI代理：“内特在赢得他的第三次电子游戏锦标赛时，是如何使用奖金的？” • MRAgent首先从提示中提取细粒度的初始提示，例如“内特”、“电子游戏锦标赛”和“获胜”。 • 代理将这些初始提示映射到记忆图中，并查看与之相连的可用关联标签。代理看到了诸如“锦标赛胜利”和“锦标赛参与”等标签。由于代理只关注用户在夺冠后究竟做了什么，MRAgent便放弃了“锦标赛参与”标签，转而追寻“锦标赛胜利”标签。 • 代理检索与所选提示-标签组合相关联的片段式内容，从中找到了三个不同的记忆片段，这些片段记录了内特赢得锦标赛的过程。 • MRAgent审视这三段记忆，决定其中一段特别符合查询需求，并舍弃另外两段。 • 基于这些信息，代理更新其提示，并开启新一轮的探索与剪枝。从新获取的片段式记忆中，代理将“锦标赛收益”添加到提示中，并以此继续探索新的标签，进一步锁定新的记忆。如此反复操作，直到代理收集到足够多的信息来回答查询——例如，“内特把钱存了下来。” MRAgent在行业基准测试中的表现 MRAgent与其他多种代理式记忆构建框架并行运行。其他替代方案包括基于图的代理式记忆框架A-MEM，以及分层记忆框架MemoryOS。其他持久性记忆框架还包括LangMem和Mem0。 研究人员在LoCoMo和LongMemEval行业基准测试中对MRAgent进行了测试。这些测试旨在评估代理在长时序任务和对话中，解决数十个会话、数百轮对话中查询的能力。所使用的骨干模型分别为Gemini 2.5 Flash和Claude Sonnet 4.5。系统还与标准的RAG、A-MEM、MemoryOS、LangMem和Mem0进行了对比测试。 在两种模型和所有问题类型中，MRAgent均以显著优势超越了所有基线模型。 然而，对于企业开发者而言，最关键的指标往往是计算成本。在LongMemEval测试中，MRAgent的提示令牌消耗仅降至每样本118千个。相比之下，A-MEM消耗了632千个令牌，而LangMem则每条查询耗尽了326万个令牌。此外，与A-MEM相比，MRAgent的运行时间也有效缩短了一半，从1122秒降至586秒。 MRAgent在实践中之所以高效，是因为其按需运行的特性。在检索前评估标签、剪枝无关路径，不仅节省了成本，还节约了上下文空间。更进一步，系统能够自主评估其累积的上下文，并自动知晓何时停止搜索，彻底避免了重复的数据探索。 实施与开发的挑战 尽管MRAgent效果显著，但要在代理开始查询之前，必须先准备好“提示-标签-内容”结构。开发者需要思考如何设计底层记忆数据库，以便LLM能够高效地浏览关联项、剪枝无关路径，同时避免计算成本的大幅飙升。 幸运的是，开发者无需手动标注或结构化这些数据。作者设计了MRAgent的自动化蒸馏流程，利用LLM处理原始交互历史，并自动填充记忆图。对于开发者而言，工作重点在于实现并协调这一自动化数据采集流程，而非手动为数据打标签。 你需要设置后台作业或流式管道，将原始用户交互通过提示模板进行提取，以获取这些元数据，然后再将其存储到你的图数据库中。 不过，作者强调，这只是一个轻量级的构建阶段，MRAgent有意保持采集过程的简单性。 作者已在GitHub上公开了代码。