跳到正文
北京时间
原文
HuggingFace Daily Papers(社区热门论文)·· 2026-07-23精选AI 评分72

Agentic Context Management:将智能体记忆与成本问题重构为生命周期与架构挑战

Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems

AI 导读

论文提出 Agentic Context Management(ACM)框架,将智能体上下文管理从存储问题重新定义为包含架构、摄取、范围界定、预判、压缩与整合五个原语的生命周期管理。

推荐理由

这篇论文把代理记忆从‘存什么’重新表述为‘管什么’的生命周期问题,五个原语和线性成本论证,对做生产级代理的团队有直接的架构启发。

正文 · AI 翻译
摘要

生产环境中 AI 智能体的失败,往往不是因为推理能力不足,而是因为它们无法管理自己推理上下文中的内容;它们必须在上下文中同时容纳大量信息:对话历史、超长提示词、庞大的工具定义,以及不断膨胀的工具输出。它们被自己不断累积的历史所淹没,同时还要为每一轮对话都在增长的 token 成本买单,结果导致在同一对话内以及跨对话之间都出现信息召回缺失。现有的应对方案把这个问题当作存储与检索问题来处理。我们认为这种框架过于狭隘。我们提出,主动管理智能体“心中所想”的内容是一个生命周期过程,而不仅仅是存储:它涵盖决定记住什么、提取并结构化信息、为不同数据类型选择恰当的存储方式、构建最优冗余、有意识地进行整合、在保持溯源的同时遗忘过时信息、判断当前轮次需要哪些相关内容、预判下一步将需要什么,以及在预算范围内压缩上下文而不丢失关键信息、不牺牲召回率等等。在严肃的生产级智能体中,这一过程不仅作用于单个用户,还贯穿组织层面的层级范围。我们倾向于将这一学科命名为“智能体上下文管理”(Agentic Context Management,ACM)(过去也有其他人这样称呼),并将其分解为五个原语:架构设计(architecting)、摄取(ingesting)、范围界定(scoping)、预判(anticipating)以及压缩与整合(compacting & consolidation)。随后,我们从经济角度论证为什么受管制的生命周期并非奢侈之举:朴素的上下文累积会使 token 成本随对话长度呈二次方增长;粗糙的摘要虽能换来线性成本,却以准确率断崖为代价;只有经过验证的压缩才能在保持保真度的同时实现线性成本。我们描述了一个参考实现——Maximem Synap,它将这五个原语实现为多租户服务,并在第 6 节详述的配置下,于 LongMemEval 上取得 92% 的成绩,在 LoCoMo 上取得 93.2% 的成绩。最后,我们以现有基准尚未覆盖的维度作结,即延迟、token 效率和上下文腐化抵抗力,以及该方向所指向的决策级和组织级上下文这一开放前沿;这些维度将继续决定智能体在严肃场景中效用的稳定性与可用性。

1 引言

过去两年,大语言模型从聊天界面演变为智能体,即能够采取行动、调用工具,并在多轮对话和多个会话中执行任务的系统。多项行业调查都强调了生产落地这一步有多难。截至 2025 年,大多数企业都在尝试 AI 智能体,但其中只有约四分之一的企业报告称已实现规模化部署,而在单一业务职能内完成智能体规模化的企业甚至不足 10%。事实上,绝大多数智能体试点项目从未真正进入生产环境(McKinsey,2025)。最明显制约这一规模化进程的能力短板并非推理能力,因为前沿模型的推理表现已经相当出色。它们真正缺乏的,是对每一步上下文窗口中应包含什么内容的严格管理。缺乏这种管理,已部署的智能体就会部分或完全遗忘用户在一段长对话早期告诉过它的信息,或遗忘它在同一对话中从工具获取的内容,或遗忘上周向它提及的事情;在多智能体交接过程中自相矛盾;在塞满无用信息的上下文中产生模型幻觉;并且每多一轮对话,成本就更高。

当前对这个问题的框架是“记忆”。围绕它已经形成了一个健康的记忆工具生态。我们认为,恰恰是这个框架本身限制了这些系统。“记忆”指的是一个存储库,即一个存放事实并能取回它们的地方。围绕存储库构建的系统只优化两个时刻,即写入和读取。但让我们考虑一下,一个生产级智能体平台必须逐轮做出哪些决策:(a) 刚才所说的内容中,哪些值得保留;(b) 这些内容应以何种结构被保留;(c) 在所有已保留的内容中,哪一小部分属于本轮上下文;(d) 下一轮可能需要什么;(e) 当相关上下文超出模型能有意义使用的预算时,应该怎么办。这是五个在不同时刻做出的不同决策,而一个存储库一个也做不了。存储只是生命周期中的一个时刻,而非全部。一个可用的平台必须做出这五个决策,同时还要防止一个用户的上下文泄露到另一个用户,并尊重组织边界。

本文提出了四项贡献,旨在解决这些问题:

重新定义框架与分类体系:我们定义了智能体上下文管理(Agentic Context Management),并将其分解为五个原语或概念:架构设计(architecting)、摄取(ingesting)、范围界定(scoping)、预判(anticipating)、压缩与整合(compacting & consolidation);这些原语在从单个用户到组织的范围层级中运作(第 2 节)。

一个经济学论证:我们指出并证明,受管理的生命周期是必要的,而不仅仅是锦上添花。全量追加的上下文在对话过程中会消耗大量 token。粗糙的摘要则用准确率下降来换取成本降低。相反,经过验证且智能的压缩能够在保持保真度的同时,达到线性成本的效率前沿(第 3 节)。我们通过对五个数据领域的检索进行原创研究,来支撑论证中检索侧的论点。O​(n2)

参考实现:我们描述了 Maximem Synap,一个融合了这五个原语的多租户服务,既在架构层面,也在可观察行为层面进行了阐述(第 4–5 节)。

证据与议程:我们报告了两个公开记忆基准上的实验结果及其局限性(第 6 节),并勾勒出决策级与组织级上下文管理的前沿方向(第 8 节)。

Maximem 的 Synap 产品在本文中作为该类别的参考实现出现。然而,本文论证的核心在于这一类别本身。读者若读完本引言部分后,能以生命周期视角理解上下文管理,便已把握了要点。参考实现只是构建此类生命周期系统的一种方式。

2 从记忆到上下文管理

我们将智能体上下文管理定义为这样一门学科:决定智能体应在上下文中保留什么、何时保留、保留多久、以何种成本保留,并贯穿从上下文获取到上下文退役的完整生命周期。它包含五个原语。

架构设计:在存储任何一条记忆之前,必须由某个环节来决定给定智能体的记忆形态:哪些类别的信息重要、应如何提取、应存放于何处、应持久保留多久、应如何检索与压缩。大多数系统以固定的通用模式来回答这些问题。我们认为,架构本身就是一个构建上下文管理系统的头等原语。

摄取:原始信号——如对话轮次、多模态文档上传、工具调用及其响应——必须被转化为结构化、可检索的记忆。先前研究已充分确立并在实践中得到验证的一个关键观察是:检索质量受限于摄取质量。例如,一个只存储“用户提到了某个定价方案”的系统,永远无法在日后检索出“用户于 4 月 3 日从 Starter 升级到了 Pro”。

范围界定:在摄取和检索时,系统必须决定其所知信息中哪些部分与未来相关,以及相关范围有多大。这是一个跨组织层级(定义见下文)的分层决策,且具有严格隔离性,确保一个用户的上下文绝不会出现在另一个用户的会话中,同时一个组织的信息不断丰富,从而在 B2B 智能体环境中为所有用户创造由网络效应驱动的正向、高效体验;但前提是暴露给智能体的数据性质允许这种行为。

预判:智能体不知道自己不知道什么。如果智能体从不主动询问,它就不太可能检索到相关信息。推测性预取是计算机系统中一个由来已久的思想。我们将其应用到了智能体上下文中。它使上下文管理系统能够在原则上观察智能体的行为,并在显式请求到达之前准备好它可能需要的上下文,从而将检索移出关键路径。我们将预判视为一种区别于检索的原语:检索回答的是“什么与当前搜索查询或当下时刻相关”,而预判式检索回答的是“接下来什么会相关”。它还能帮助智能体获得它不知道自己需要知道的问题的答案,从而准确满足用户需求。

压缩与整合:当相关上下文超出下游模型能够有效利用的预算时,系统必须在不丢弃未来所需信息的前提下进行缩减。关键在于,压缩应当是**可验证的**:一个静默丢弃关键事实的压缩比不压缩更糟糕,因为它会产生自信的错误答案。我们提出,在生产规模下,可验证、无损且有主见的压缩是可行且有价值的。

这五个原语是相互耦合的:第一个原语所选择的架构会改变其余原语应做的事情(支持型智能体和编码型智能体需要不同的分类、保留策略和压缩方式)。这种耦合正是将上下文作为**一个系统**来管理、而非拼凑五个独立工具的核心论据。

作用域维度:每个原语都在一个作用域层级中运作,而不仅仅是针对单个用户。在本文中,我们用三个术语来描述这个层级,从最窄到最宽依次是:用户(与智能体交互的个体人或智能体/子智能体)、客户(该用户所属的组织)以及客户端(智能体平台的运营方,其部署横跨多个客户组织)。摄取与检索都应按照从最窄到最宽的次序解析这个层级,即先用户、再客户、后客户端,并且要在严格隔离的条件下进行。此外,应存在一个独立的全局知识层,用于承载共享的通用知识(例如,公共实体的规范身份标识)。大多数记忆工具的作用域仅限于用户;将组织结构扁平化地归入单一桶中,要么丢失组织上下文,要么导致一个用户的数据泄露到另一个用户的会话中。将作用域视为一个一等维度——即原语的作用域——正是让上下文管理能够服务于组织而不仅仅是单个个体的关键所在。×

Refer to caption
图 1:五原语上下文生命周期(架构、摄取、作用域、预判、压缩与整合),以围绕中心智能体的循环形式绘制,检索作用域层级(用户、客户、客户端)作为纵轴,全局知识层单独绘出,为实体规范化提供输入。→→→→→→

我们提出:一个能良好解决单个原语的系统,是一个记忆工具;而一个能在各作用域之间连贯地解决全部五个原语的系统,则是一个上下文管理平台。

该分类体系基于实际观察到的失败案例:每个原语之所以有其存在的必要,是因为缺少它就会产生一种有明确命名的、在生产环境中观察到的失败模式;其中一些记录在我们自己的部署笔记中(Maximem,2026a),另一些则见于已发表的文献。表 1 明确展示了这种对应关系;第 3 节量化了在成本和准确性方面占主导地位的两种失败模式。

媒体内容 · 前往原文查看
表 1:生产环境中的失败模式及其缺失所对应的原语
观察到的失败 在生产环境中的表现 缺失的原语 证据
垃圾信息累积 低价值或重复的条目不断累积,挤占了有用的记忆空间。对某个流行记忆库的一次审计发现,32 天内存储了 10,134 条记录,其中只有 38 条可用,垃圾率高达 99.6%(包括启动文件复述、cron 噪声、配置转储)。 架构设计 + 摄取(先存储,后提取) Maximem(2026a)
细节丢失 提取过程只保留了模糊的转述,导致具体事实永远无法被检索到。原文说的是“用户于 4 月 3 日从 Starter 升级到 Pro”,存储的却是“用户提到了一个计划”;任何检索方法都无法恢复被提取过程丢弃的细节。 摄取 Maximem(2026a);第 3.3 节
身份碎片化 同一个真实实体被存储在多个互不关联的名称下,导致其历史记录被割裂。“Sarah”“Sarah Chen”和“SC”被存储为三个互不相关的字符串;检索返回的是与查询嵌入向量最匹配的那一个,从而产生不完整或相互矛盾的答案。 摄取(实体解析) Maximem(2026a)
范围越界 某个范围内的记忆出现在另一个本应与之隔离的范围中。一个用户的偏好出现在另一个用户的会话里;或者智能体完全遗漏了组织层面的上下文。 范围界定 Maximem(2026a)
跨会话失忆(表现为交接时的重复) 早期会话中的知识没有被延续下来,因此必须重新建立。用户不得不对每个新会话或每个子智能体重复同样的话。 范围界定(缺少生命周期) Maximem(2026a)
检索处于关键路径上 每一轮对话在模型能够响应之前,都要阻塞等待一次同步检索的往返。每一轮对话都因检索往返而停滞。 预判 第 5 节
精度悬崖 未经验证的压缩会丢弃后续所需的信息,导致精度骤降。在一次未经验证的步骤中,18,282 个 token 被压缩到 122 个;精度从 66.7% 降至 57.1%,低于无上下文基线。 压缩与整合(缺少验证) Zhang 等人(2025)
二次方成本增长 反复发送不受管理的、不断增长的上下文,会使 token 成本呈二次方上升。每次对话的 token 成本随其长度的平方增长。 压缩与整合 第 3.1 节

3 为什么“存储与检索”并不足够

第 2 节的重新框架是概念性的。本节将其量化,因为受管生命周期的理由归根结底是经济层面的,也是信息层面的,而这两者都是可衡量的。

3.1 不作为的成本呈二次方增长

考虑一个多轮智能体对话。假设每轮增加约 token(用户消息加助手回复),并让对话运行 轮。在朴素的“全量追加”模式中(每轮重新发送整个历史记录,这是大多数手写智能体的做法),第 轮的输入上下文是整个历史记录,大约为 token。因此,整个对话的累计输入 token 为tnkk⋅t

Cappend=∑k=1nk​t=t​n​(n+1)2≈t2​n2=O​(n2).

由于服务商按输入 token 计费,成本随对话长度呈二次方增长。(单次调用的注意力计算更糟,每轮在序列长度上是二次方的,但计费结果更便于推理。)如果系统将每轮的上下文保持在固定预算内,累计 token 则为 。该比率,Wn⋅W=O​(n)

CappendCbounded=t​(n+1)2​W,

随 线性增长:对话越长,全量追加的代价就越沉重。以示例值(, )计算,该倍数在 100 轮时约为 ,在 200 轮时约为 ;完整推导和敏感性表见附录 A。nt=500W=4,0006×13×

Refer to caption
图 2:累计输入 token 与轮数的关系:全量追加(二次方)对比有界上下文(线性)。

3.2 但朴素地限制上下文会破坏准确性

限制预算是有必要的;但限制方式决定了能否保持准确性。粗糙的摘要可以限制 token,但有损且未经验证,其损失可能是灾难性的:先前的研究记录了一个案例,其中将 18,282 个 token 的上下文单步压缩到 122 个 token,导致任务准确率从 66.7% 降至 57.1%,比完全不提供上下文还要差(Zhang 等,2025)。摘要器丢弃了重要的内容,因为它无法知道下游需要什么。

这产生了三向对比:

方法 Token 成本 保真度 失败模式
全量追加 O​(n2) 完整,直到上下文腐化 成本爆炸;长上下文退化(“中间迷失”,Liu 等,2024)
粗糙摘要 O​(n) 有损、未经验证 准确率悬崖
经验证的压缩 O​(n) 保留 + 校验 无(目标状态)
Refer to caption
图 3:精度与成本的前沿曲线——全量追加(右上)、粗略摘要(左下)、经验证的压缩(左上)。一张图即可承载本节核心论点。

论证至此已十分清晰。上下文管理系统应位于左上角,即以线性成本实现经验证的保真度,而要做到这一点,就必须把压缩视为一种经过验证的操作,而非一种寄望于运气的行为。

3.3 检索并不等于充分性

成本只是问题的一半。另一半在于检索到的上下文是否足以支撑推理。检索质量本身就是一个由多个瓶颈串联而成的链条:

answer quality≤min⁡(extraction quality,retrieval quality,reasoning sufficiency).

抽取(Extraction)指的是在数据摄入阶段将原始信号转化为可存储、结构化的记忆的步骤。检索(Retrieval)则是在查询阶段将这些记忆取回的步骤。每一个环节都会限制最终输出答案的质量上限。如果你存储的是垃圾数据,抽取环节就会成为瓶颈。表 1 中的垃圾率审计就是一个极端案例——对未抽取信号进行忠实存储反而使存储库几乎无法使用。检索到错误材料,检索环节就会成为瓶颈;检索到了部分相关材料,但缺少推理出可证明答案所需的全部上下文,那么推理充分性就会成为瓶颈(Dadhich, 2026a)。最后这一点最容易被忽视——大多数基准测试衡量的是检索命中率(是否出现了相关文档?),几乎没有任何基准测试衡量推理所需的全部内容是否都出现了,更不用说检索到了多少不相关的内容。

我们开展了一项动机性研究(纯粹出于好奇),考察了五个领域的检索效果:代码(CodeXGLUE)、网页(MS MARCO)、事实(SQuAD)、多跳推理(HotpotQA)和科学(SciQ):五个语料库各含 10,000 篇文档,每个语料库 1,000 条查询,以 MRR@10 为评分指标(Dadhich, 2026a;数据和各数据集结果见 maximem-ai/file-vs-vector-study-results)。先说明其局限性:(a)单一操作者,一个关键词检索引擎对比一个向量存储;(b)未做分块;(c)单个语料库规模较小。我们将其作为动机性研究呈现,而非受控基准测试(完整方法和注意事项见附录 B)。但有两项发现与本主题相关。(a)向量检索和关键词检索在不同场景下各有优势,且差距并不小。向量搜索在语义鸿沟最大的地方占据主导(自然语言到代码:MRR 0.91 对比 0.29,查询“sort a list”能找到 bubble_sort),而关键词搜索在检索词是具体实体而非语义或模糊概念时取得决定性优势(科学问答:0.81 对比 0.61,“mitochondria”是一个关键词,而非相似概念),事实型问答两者持平,多跳推理略偏向关键词(表 B1)。该研究还量化了“向量税”:对同样的 10,000 篇文档语料库进行索引,嵌入向量生成所需时间是关键词索引的 60–100 倍(表 B2),当智能体需要立即阅读新材料并立即据此行动时,这是一个实实在在的约束。×

然而,更深层的发现是这项研究在设计上无法衡量的部分。与大多数检索评估一样,当单个黄金文档出现在顶部结果中时,它就计为一次命中——例如在 HotpotQA 上,它针对每个问题只按一个支撑文档来评分,尽管多跳问题需要两个或更多文档。以这种方式构建的评估无法检测出对智能体而言最重要的失败模式,即检索到了相关文档,却遗漏了完成推理链所需的桥接文档。这也是我们在检查输出时定性观察到的效应,但由于单一目标评分机制而无法量化,因此我们将其作为观察结果而非实验结果来报告。这就是推理充分性差距最纯粹的表现形式:检索命中处处可测,而推理充分性几乎无处可测。我们得出的结论是,检索必须结合词汇信号与语义信号:关键词搜索与向量搜索的混合方案,因为两者各自覆盖对方的盲区。在我们构建 Maximem 的 Vity(一个跨应用的个人 AI 记忆库)的实验过程中,我们了解到纯向量实现有其自身的局限性,需要与图结构结合使用,以便在查询中保留关系信息并管理来源追溯。于是图结构也被加入组合之中。但仅靠这种混合方法只是必要条件,而非充分条件。弥合充分性差距还需要结构化摄取和范围感知的组装,这正是本文其余部分将检索视为受管生命周期中的一个原语而非独立组件的原因,也是第 6.3 节论证该领域需要直接对充分性进行评分的评估体系的原因。

Refer to caption
图 4:关键词检索与向量检索按数据集划分的 MRR,并叠加了嵌入生成(“向量税”)延迟。

3.4 生命周期必须提供什么

这两个论点得出了相同的结论。弥合成本差距需要经过验证的压缩;弥合充分性差距则需要保留结构的摄取、组装充分上下文的范围界定,以及结合语义与关系信号的检索。没有任何单一的检索方法能做到这一点,但一个受管理的、专门设计的生命周期可以。下一节将描述这样一个系统。

4 Maximem Synap 系统

Maximem Synap 是一个多租户、托管的上下文管理服务。在本节中,我们通过组件做什么以及为什么这样做来描述它们:它们的接口、可观察行为和保证,而刻意不描述它们内部如何工作;机制内部是专有的。这一句话涵盖了整个章节;我们不会对单个组件逐一标注。

Refer to caption
图 5:参考架构:SDK API(REST + 流式)管理器/流水线 多语言存储,五个原语标注在实现它们的组件上。→→→

客户端表面:Maximem Synap 暴露了一个异步优先的 SDK(Python 为规范语言;另有 JavaScript 桥接),其内存写入调用会立即返回一个摄取标识符,绝不阻塞调用应用程序;处理过程异步进行。SDK 提供统一的、范围感知的检索调用、一个对话压缩调用,以及一个流式通道。租户隔离在存储层(按租户命名空间)和查询层(范围谓词)均得到强制执行,身份来源于存储的凭据,而非由客户端断言。

架构设计(按智能体的内存设计):当智能体被连接时,Maximem Synap 会根据客户对其用途的描述以及提供的任何参考材料,为该智能体生成一个定制化的内存架构,选择要捕获哪些内存类别,以及如何提取、存储、检索和压缩它们,然后激活该架构。这是一个自主的、由 LLM 推理驱动的设计步骤,带有多个智能体的检查和验证,而不是从固定菜单中选择;由此产生的架构支配着每个下游原语的行为。

摄取:摄取是一个异步、基于队列的多阶段流水线。它接收一份文档,立即返回一个摄取 ID,并在后台对内容进行质量判定,提取记忆类别:事实、偏好、事件片段、情绪、时间事件,以及根据系统在该实例中所支持的智能体性质而定的更多类别;同时提取实体、关系和时间有效性,然后解析实体,并将结果持久化到关系型、图型和向量存储中。提取决策由设置步骤中的按智能体架构决定,而非基于固定的通用模式。

实体解析:由于同一个人或事物会以多种表面形式出现(“Sarah”、“Sarah Chen”、“SC”;或在组织层面,同一份文档既叫“PR FAQ”也叫“6-pager”),Maximem Synap 在摄取期间将提取的实体解析为规范身份。它运行一个按置信度排序的匹配策略级联,从精确标识符开始,逐步过渡到更宽松的词法、语义和上下文信号。公共实体对照全局知识层进行校验。任何此前未见过的实体都会在客户范围内注册。解析采用尽力而为原则,绝不阻塞摄取;模糊匹配可排队供人工审核。

范围界定(检索):检索是一个感知范围的流水线,按最窄优先的顺序解析层级:用户、客户、客户端,并返回带来源标记、受 token 预算约束、已排序的记忆条目。它提供低延迟模式和更高精度模式,后者增加了查询分解和 LLM 重排序。

图感知检索:除了向量相似性之外,Maximem Synap 还执行向量引导的知识图谱多跳遍历:语义相似性决定从何处进入图谱以及哪些关系值得跟进,从而浮现纯向量搜索会遗漏的相关记忆(第 3.3 节的桥接文档问题)。图增强检索已有公开先例(Edge et al., 2024; Gutiérrez et al., 2024; Hu et al., 2025),我们将在第 7 节讨论;Maximem Synap 具体的遍历和评分方法不在此处描述。

预取:Maximem Synap 还实现了一条预取检索路径:智能体可能需要的上下文可以在显式请求之前就准备好,其设计意图既在于告诉智能体它需要但不知道记忆中已存在的内容,也在于将检索延迟移出智能体的关键路径,并且预取与显式检索由同一套决策逻辑控制。这不是查询结果缓存,因为缓存是对重复查询重放答案。而预取则是根据智能体不断演变的行为进行预测;它预测并预取尚未被请求的上下文,在请求到达之前将其准备好。它的价值在于降低延迟而非去重,因为检索位于智能体的关键路径上(第 5 节)。将预期中的获取移出该路径,可以把一次阻塞式的往返变成在需要时的一次缓存读取,代价是未命中时被丢弃的推测性工作。我们描述了这一概念,但没有描述预测机制本身——该机制是专有的,我们花了一段时间才在最小化系统为降低计算和智能开销而需执行的浪费性工作的同时实现高命中率,而且这仍是一项进行中的工作(目前我们在各客户间持续实现 60% 以上的命中率)。

压缩与整合:对于长对话,Maximem Synap 将压缩视为一项经过验证的操作:每次压缩都会检查信息损失。系统会测试原始对话中的关键信息是否仍可从压缩结果中恢复,并输出一个明确的验证分数和压缩比率,当验证结果低于阈值时,会自动以更温和的压缩力度重试。压缩是类别感知的:哪些内容必须逐字保留、哪些内容可以被抽象,由智能体生成的架构决定。这就是第 3.2 节中经过验证的压缩;验证机制本身在此不作描述。

存储:Maximem Synap 采用多语言、按租户命名空间隔离的存储栈:向量存储用于嵌入向量,图存储用于实体-关系图,关系型存储作为数据源真相和短期上下文,对象存储用于原始内容和每个智能体的配置,时序存储用于使用遥测数据,内存存储用于队列、缓存和协调。每个存储背后的具体引擎是实现选择,可能会更改或合并;在这一层重要的是每个存储所扮演的角色。向量存储和图存储共同使检索能够结合语义和关系信号,这正是第 3.3 节论证过的混合方案的必要性:向量存储弥合了语义鸿沟,而图存储提供了纯相似性搜索所缺失的关系链接。嵌入向量默认使用本地托管的 sentence-transformer 模型计算。

集成模式:从应用程序的角度来看,生命周期简化为围绕每次模型调用的三步调用模式:对过去上下文的作用域检索、对当前对话的验证压缩,以及对新一轮对话的非阻塞摄取(见清单 1,伪代码;具体签名见公开 SDK 文档)。清单的重点在于其中没有的内容:没有模式设计、没有嵌入模型选择、没有索引管理、没有隔离逻辑。这些是生命周期层的工作。

清单 1 —— 生产集成模式(伪代码),每一轮对话时:检索 FETCH(query=user_message, scope={user, customer}) 作用域检索;压缩 COMPACT(current_conversation) 验证压缩;回复 MODEL(assemble(retrieved, compacted, recent_turns));摄取 INGEST(turn, scope) 异步执行;立即返回一个摄取 ID。←⊳←⊳←⊳

一个示例追踪:设想某 SaaS 产品的支持客服收到这样一条消息:“嗨,Sarah 说让我来问你。我们上周升级到了 Pro 版,但仪表盘上仍然显示的是 Starter 版。”在连接阶段,架构设计已经生成了该智能体的记忆架构(与计费相关的类别、按客户范围划分的组织实体、对账户事实采用保守压缩)。摄取阶段提取出一个具有时间有效性的事实(上周从 Starter 升级到 Pro)、一个事件片段(仪表盘显示过期的套餐信息),以及一个实体提及(“Sarah”),实体解析将其链接到此前在该客户范围内已从“Sarah Chen”和“SC”等提及中识别出的规范身份。同一名字在另一客户处则解析为不同的人。在下一轮对话中,按范围检索会汇总用户级上下文(该用户的未结工单)、客户级上下文(该组织的套餐历史与团队),以及客户级模式(已知的套餐传播延迟),每个条目都带有来源标记并适配 token 预算。随着对话变长,压缩会缩减内容,并在下一次模型调用前报告一个验证分数。整个过程中应用代码均为清单 1;本段所述的每一个行为都可以通过 SDK 和仪表盘观察到。→

关于分解的说明:我们将 Maximem Synap 呈现为五个原语,即具有明确契约的能力,而非五个独立的运行时组件。从原语到进程的映射是实现选择,且在该系统的生命周期中已经发生过变化。契约才是稳定的接口面。

5 设计选择

我们重点强调那些将上下文管理系统与记忆工具区分开来的选择,每一项都与第 3 节中的一种失败模式相关联。

架构是综合定制出来的,而非固定通用的:一套通用模式不可能同时完美适配金融科技客服智能体和编程助手;它们在类别划分、保留策略和压缩需求上各不相同。为每个智能体单独生成架构,才能让生命周期其余环节贴合实际用例,而这一选择对提取质量的影响也最大(即 3.3 节链条中的第一环)。同时,正是这一选择让第 2 节的耦合论证变得具体可感:生成的架构正是“架构设计原语”用来配置其余四个环节的那个产物。

压缩带有质量契约:由于未经校验的压缩会产生自信但错误的答案(见 3.2 节),Maximem Synap 在每次压缩时都会返回一个明确的校验分数和压缩率,并在校验失败时自动重试。该系统会给出压缩是否成功的确认,而不是压缩完就指望它效果好。

校验并非没有代价:压缩上下文并对其进行检查会消耗 token。但压缩并非一次性事件;它会周期性运行,每一轮处理的对象都是“已压缩的上下文 + 最近几轮对话”,而不是完整转录文本。因此,每次压缩处理的都是有界上下文,而压缩次数只会随对话长度线性增长,所以开销是线性的而非二次方的。如果上下文保持在预算附近,且每 轮触发一次压缩、每次成本为有界上下文的 倍,那么 轮对话的总 token 成本为 :即 3.1 节的线性成本乘以一个固定系数 。与“全量追加”的基线相比,节省量随对话长度增长而增加,而非减少;在每轮 个 token、 、 (固定开销)的情况下,净 token 节省量在 100 轮时约为 80%,200 轮时约为 90%,500 轮时约为 96%。这种反复再压缩之所以安全,完全是因为每一轮都经过校验:如果没有信息丢失检查,迭代压缩就会滑向 3.2 节所述的上下文坍缩故障。WpcNN⋅W⋅(1+c/p)(1+c/p)O​(N2)t=500W=4,000p=8c=21.25×

摄取是异步且非阻塞的:立即返回摄取 ID 可保持调用方智能体的响应性;繁重的工作(提取、解析、多存储持久化)发生在关键路径之外。这种以即时一致性换取低延迟的取舍是刻意为之。其可行性在于记忆的读取频率远高于写入频率。这并不会牺牲会话内的写后读一致性:最近的几轮对话会原样携带在工作上下文中(清单 1 中的 recent_turns),因此智能体刚刚产生或接收到的信息在下一轮即可使用,无需等待摄取完成。异步机制只是延迟了该信息的持久化、结构化、长期可用性,而非其即时使用。

作用域是一等公民,隔离是强制实施而非建议:多租户隔离在存储和查询层实现,身份信息来源于凭据,因此组织上下文始终可用,且一个用户的数据不会出现在另一个用户的会话中——这正是扁平化、用户级作用域记忆容易引发的故障。作用域策略由 Maximem 建议、但由客户端掌控:Maximem 提出智能体应采用的作用域方案,客户端负责批准并加以管控,因此客户对哪些内容可在用户和组织之间共享、哪些内容保持隔离拥有最终控制权。

检索结合了语义信号与关系信号:纯向量检索会遗漏桥接上下文(见 3.3 节)。纯图遍历则成本高昂且脆弱。将两者结合旨在实现推理充分性,而不仅仅是检索命中率。

延迟是围绕设计来考量的,而非仅仅优化:检索位于智能体的关键路径上,因此系统提供了明确的低延迟检索模式;此外,第 4 节的预判路径旨在当上下文可以提前准备时,将检索完全移出关键路径。

6 评估

6.1 实验设置

我们在两个公开的第三方对话记忆基准上评估了 Maximem Synap:LongMemEval(Wu 等人,2024),包含 500 个基于长程多会话聊天历史的人工设计问题,覆盖六个能力类别;以及 LoCoMo(Maharana 等人,2024),针对超长对话(平均 300 轮)的问答任务。这两个基准均非我们自行设计;我们使用的是它们的官方公开版本,未做任何自定义子集划分,也未重新标注。∼

表 2 详细列出了每项报告结果的确切配置。我们认为,只有在完整说明配置的情况下,评估数字才具有可解释性,并且我们以这一标准要求自己的数据。有一个范围决策需要特别说明:LoCoMo 的第 5 类属于对抗性类别——问题被设计为不可回答,衡量的是模型拒答能力而非记忆能力,是否纳入该类别会使总分产生 10 分以上的波动,这也是 LoCoMo 数据难以比较的最常见原因。我们报告的是第 1–4 类,排除第 5 类,这与原论文、Mem0 和 Zep 的惯例保持一致(Maximem,2026d)。

媒体内容 · 前往原文查看
表 2:评估配置(完整方法论见 Maximem,2026d)
LongMemEval LoCoMo
结果(总体) 92.0%(460 / 500) 93.2%(第 1–4 类)
数据集 LongMemEval_S,完整 500 题集,全部 6 个类别,官方发布版本 locomo10,官方发布版本;第 1–4 类(按惯例排除对抗性第 5 类)
作答模型 gpt-5-mini gpt-5-mini
评判模型 gpt-5-mini,与标准答案进行二元 CORRECT/WRONG 判定 gpt-5-mini,与标准答案进行二元 CORRECT/WRONG 判定
检索配置 对已摄入记忆进行范围感知检索;完整逐次运行配置见已发布的方法论 相同
测试框架 maximem-ai/memory_and_context_eval_harness(Maximem,2026e)(开源) 相同
产物 方法论及逐类别计数已公开(Maximem,2026d);逐次运行产物(答案、检索上下文、评判结果)可应要求提供 相同
运行日期 / 仓库标签 已在结果仓库中打标签(maximem-ai/eval_benchmark_runs_output) 相同

6.2 结果

在表 2 的配置下,Maximem Synap 在 LongMemEval 上达到 92.0% 的总体得分(460/500),在 LoCoMo 类别 1–4 上达到 93.2%,这与我们的公开记录一致(Maximem, 2026c; 2026d)。各类别结果如下;我们既如实报告强项类别,也如实报告弱项类别。

各类别结果(官方类别分布;计数见 Maximem, 2026d) LongMemEval 类别 得分(正确数/n) LoCoMo 类别 得分 单会话用户 100.0%(70/70) 多跳 97.3% 单会话偏好 100.0%(30/30) 开放域 93.4% 知识更新 100.0%(78/78) 时间推理 90.8% 时间推理 100.0%(133/133) 单跳 88.8% 单会话助手 87.5%(49/56) 总体(类别 1–4) 93.2% 多会话 75.2%(100/133) 总体 92.0%(460/500)

残余错误集中在 LongMemEval 的多会话类别(75.2%):即需要跨多个独立会话整合信息的推理,其次是单会话助手类别(87.5%)。我们如实说明:多会话推理是我们所知所有系统中公开类别里最难的一项,而这正是第 3.3 节所述的推理充分性范畴。

Refer to caption
图 6:各类别结果:LongMemEval 六个类别(总体 92.0%)和 LoCoMo 类别 1–4(总体 93.2%)。

相比之下,LoCoMo 尤其已成为供应商之间公开方法论争议的主题,而记忆基准测试的分数对答案模型、评判器、摄取粒度以及对抗性类别的处理方式高度敏感;仅更换答案模型就可能让同一系统变动数个百分点(SuperMemory 自己发布的扫描结果在答案模型间横跨 81.6%–85.2%)。因此我们遵循两条规则。第一,我们自己的配置完整陈述(表 2)。第二,我们从不将不同方法论得出的数字作为正面交锋呈现:表 3 复现了各供应商自己报告的最佳 LongMemEval 成绩,并附上产生该成绩的答案模型,纯粹作为已发布的行业现状;各行之间不可相互比较。我们注意到该表确实支持的一个事实:Maximem Synap 的成绩是用比最强竞品配置更小的答案模型(gpt-5-mini)取得的,这是最清晰的信号,表明增益来自上下文层,而非答案模型。

媒体内容 · 前往原文查看
表 3:已发布的 LongMemEval 结果(各供应商自有方法论;自行报告;非受控对比)
系统 LongMemEval(自行报告) 答案模型 评判器 来源
Maximem Synap 92.0% gpt-5-mini gpt-5-mini Maximem(2026d)
SuperMemory 85.2% / 84.6% / 81.6% Gemini-3 Pro / gpt-5 / gpt-4o gpt-4o SuperMemory(2026)研究页面
Zep 71.2% gpt-4o gpt-4o Rasmussen 等人(2025)
Mem0 未发布 — — —
Letta(MemGPT) 未发布 — — —

6.3 本次评估的范围与局限

我们希望明确说明这些结果和系统究竟证明了什么、又没有证明什么。首先,两个基准衡量的都是对话性记忆以及对所回忆内容的推理能力。然而,它们并不衡量生产负载下的延迟,也不衡量每项任务的 token 成本,更不衡量随着检索上下文增长所体现的精确性或鲁棒性(即“上下文腐烂”)。其中有些维度是生产团队非常看重的,而本文对这些维度提出的是设计层面的论证(第 3 节),而非基准层面的主张。我们有意不在本文报告任何延迟数据,将其留待后续论文——届时我们将提出一个新基准,旨在填补现有基准的空白。其次,第 3.3 节中作为动机引用的研究所存在的局限性,已在该节中明确指出。第三,基准分数反映的是某种配置与系统组合的结果,而非抽象意义上的单一系统本身。表 2 也是结果的一部分。第四,每次运行的产物目前是按需提供而非公开发布;但测试框架和数据集是公开的。

由于现有基准只能部分覆盖生产团队所关心的维度,因此一个全面、可复现的、面向生产环境上下文管理的基准——同时衡量准确性、延迟、token 效率和抗上下文腐烂能力——将是后续工作的主题。

7 相关工作

我们将本文定位在一个以综述而非批判态度审视的领域内,把已有工作映射到第 2 节的五个原语上。对具名系统的描述均取自各系统自身的论文或文档。

基础:记忆内容与其使用相分离,在神经系统中是一个由来已久的想法:可微神经计算机将控制器网络与外部可寻址记忆耦合在一起(Graves 等人,2016)。受认知科学启发的综述将人类记忆系统(感觉记忆、工作记忆、情景记忆、语义记忆、程序性记忆)映射到 AI 对应物上,并强调存储、检索和遗忘同等重要(Zihong He 等人,2024)。将遗忘和保留视为测试时记忆化而非删除的研究(Behrouz 等人,2025)为如何推理保留问题提供了参考。上下文学习文献确立了上下文的形态(而非仅仅其存在)驱动模型行为这一观点(Dong 等人,2024)。

记忆系统(研究):MemGPT 将 LLM 视为一个操作系统,管理着上下文内存储与外部存储构成的类虚拟内存层级结构,由模型自身将信息分页调入调出(Packer 等人,2024);它主要解决生命周期中的范围界定和存储环节,并已产品化为 Letta,其文档描述了具有开发者定义记忆块的智能体、旧消息的自动压缩,以及实验性的“睡眠时间”智能体——后者在交互间隙于后台处理记忆,是与预期原语最接近的已发表同类工作(Letta 文档,2026)。MIRIX 将智能体记忆结构化为六种类型化组件,由多智能体框架协调路由更新与检索(Wang & Chen,2025),解决的是摄取和范围界定环节。Dynamic Cheatsheet 维护一份在测试时自适应更新的外部操作手册(Suzgun 等人,2025),而 Agentic Context Engineering(ACE)通过结构化增量更新扩展了操作手册的思路,避免了重写带来的简洁性偏差,并在此过程中记录了第 3.2 节核心的上下文坍缩失败问题(Zhang 等人,2025);两者都处于摄取与压缩的交汇处。CAMELoT 表明,免训练的联想记忆模块可以替代暴力扩展上下文规模的做法(Zexue He 等人,2024),这是一种偏向整合视角的压缩方案。

记忆系统(商业产品):若干商业系统将记忆作为可集成层提供;我们依据各系统自身的当前表述对其进行刻画(文档访问日期:2026 年 6 月 12 日)。Mem0 自称是“面向 LLM 应用的通用、自我改进的记忆层”,能够动态提取并整合对话中的关键信息,其开源版本中提供图后端(Chhikara 等,2025;Mem0 文档,2026);其公开聚焦点在于摄取这一基础能力。Zep 将自身定位为企业级规模的智能体记忆,通过 Graphiti 构建时间维度的“上下文图”,并据此组装 token 高效的上下文块(Zep/Graphiti 文档,2026);时间性事实有效性是其在摄取与存储层面的贡献,而其上下文组装则涉及范围界定。SuperMemory 自称是面向 AI 智能体的记忆与上下文基础设施,结合了事实图记忆、预计算用户画像以及托管式检索(SuperMemory 文档,2026)。Cognee 是一个开源 AI 记忆平台,通过记忆/回忆/遗忘/改进的接口,从异构数据中构建知识图谱(Cognee 文档,2026)。消费级助手原生内置用户级记忆(例如 ChatGPT 记忆),我们将其视为大多数终端用户所接触的基线。对照第 2 节来看,这些系统集中于记忆的摄取与存储,并具备部分范围界定能力;根据其各自的公开材料,没有任何系统声称具备生成式逐智能体记忆架构、作为产品能力的预测性预取,或经损失验证的压缩整合;而这些基础能力,连同组织级范围界定,正是我们认为生命周期框架最具增量价值之处。

媒体内容 · 前往原文查看
表 4:各系统基础能力覆盖情况。● = 根据系统自身的公开文档或论文,为其明确的主要聚焦点;◐ = 根据同一来源,为部分或可选能力;空白单元格表示该维度并非该系统公开材料所声明的聚焦点,而非声称其不存在。所有来源访问日期为 2026 年 6 月 12 日;逐行引用见补充说明。×
系统 架构设计 摄取 范围界定 预判 压缩与整合
MemGPT / Letta —a ◐ ●b ◐c ●
MIRIX ● ◐ ◐
ACE / Dynamic Cheatsheet ◐d ◐e
Mem0 ● ◐ ◐
Zep / Graphiti —a ● ● ◐
SuperMemory ● ◐ ◐f ◐
Cognee —a ● ◐ ◐
Maximem Synap(本文) ● ● ● ● ●

a 部分系统支持开发者定义或数据涌现的结构(Letta 的开发者定义记忆块;Graphiti 的“学习本体”;Cognee 的本体支持)。我们仅在系统根据智能体用途描述生成每个智能体专属记忆架构时,才将其标记为“架构化”;手工定义的结构或从摄入数据中事后涌现的结构属于另一种能力。b 从 token 预算的角度看:上下文窗口管理是 MemGPT 的创始论点,Letta 则文档化了一个带大小预算的显式上下文层级。分层组织范围界定(用户 vs. 组织 vs. 平台)并非其明确关注的焦点。c Letta 的睡眠期智能体在交互间隙于后台处理记忆;其官方文档将该功能标记为实验性。后台预计算与查询预测式预取相近,但并非同一回事。d ACE 和 Dynamic Cheatsheet 从智能体自身的执行经验中提取策略,而非从对话或文档中提取。e ACE 通过避免压缩(增量式结构化更新)来解决上下文重写中的信息丢失问题;它不执行经过验证的摘要生成。f SuperMemory 的用户画像属于预计算的常驻上下文(“无需搜索”),而非查询预测式预取。g 原始帖子声称 97.8%;但 10,134 条中仅 38 条可用的正确算术结果是 99.6% 的垃圾率。我们报告原始计数和修正后的百分比。

检索:检索增强生成是基础(Lewis 等人,2020)。图感知变体将其扩展到关系型和多文档推理:GraphRAG 构建社区摘要实体图以处理语料库级问题(Edge 等人,2024),HippoRAG 使用受海马体启发的知识图谱索引进行多跳检索(Gutiérrez 等人,2024)。RAPTOR 在递归摘要树上进行检索(Sarthi 等人,2024)。ReMindRAG 将大语言模型的遍历决策记忆在知识图谱边嵌入中,使相似查询无需重新进行逐跳大语言模型调用即可重放路径(Hu 等人,2025),它与 GraphRAG 和 HippoRAG 一起,是第 4 节图感知检索最接近的已发表现有技术,我们以此身份引用它。

长上下文:一条互补的研究路线表明,扩大上下文窗口并非没有代价:模型在长上下文中间位置的信息上表现会退化(Liu 等人,2024),而流式注意力(Xiao 等人,2024)和 KV 缓存压缩(Li 等人,2024)在注意力层面攻克长上下文的服务成本。ACM 与之正交;它决定的是首先应该把什么放进窗口,无论窗口大小如何。

8 未来方向:决策级与组织规模上下文

第 2 节的生命周期目前管理对话和组织上下文。前沿是决策级上下文:不仅捕捉发生了什么,还要捕捉组织为何做出如此决策,使智能体能够依据机构判断而非仅凭机构事实进行推理。这就是如今引起投资界关注的“上下文图谱”机遇,更广泛的机遇据估计可达数万亿美元规模(Gupta & Garg,2025),我们已就此发表了一篇扩展论述(Dadhich,2026b)。

我们对此刻意保持审慎,因为那些难题是真实存在的,且大多尚未解决。大多数决策是隐性的,从未被记录;被记录下来的理由往往是事后合理化解释,而非真正的决策轨迹;将决策与结果关联起来需要因果归因,而这连人类都难以做到;此外,判断某个过去的决策何时已被取代,本身就是一个难题。同样棘手的技术问题还包括:跨组织系统提取决策轨迹、组织内部的规范化(同一份文档,一个团队称之为“PR FAQ”,另一个团队称之为“6页备忘录”)、时间锚定、存储什么以及存储在哪里,以及将原本彼此隔离的知识汇聚到同一逻辑系统中所带来的安全后果。我们提出这些挑战,并非因为我们已全部解决(尽管我们已在参考系统中解决了大部分),而是因为将这些挑战一一列出,正是整个品类得以共同攻克难题、推动品类自身成熟的方式。一个如今能够在用户和组织之间管理事实的上下文管理生命周期,是最终构建决策级上下文的必要基础。

9 结论

智能体未能兑现其承诺,主要原因并非缺乏智能,而是缺乏受管理的上下文。仅仅将其视为一个记忆存储问题,是低估了它的复杂性。我们认为,这是一个贯穿组织层级范围的生命周期(架构设计、摄取、范围界定、预判、压缩与整合),而将其作为一个系统来管理,是经济上的必然要求,而非便利之举。这正是二次方成本与线性成本之间的差距,也是自信的错误答案与经过验证的答案之间的差距。下一代智能体上下文基础设施,将不仅仅提供一个存储历史记录的位置,而是一个管理完整上下文生命周期的系统。我们描述了一个这样的系统,并指出了该品类正迈向的决策级前沿。未来的竞争不在于谁存储的数据最多,而在于谁对上下文的管理最为出色。

致谢

作者感谢 Maximem 团队的 Shreyansh Singh Gautam 和 Anish Yadav 在 Maximem Synap 实现方面所做的工作,以及对本论文的评审反馈。作者还感谢 Varun Gupta 和其他评审人提供的非常详细且高质量的评审意见,这些意见实质性地改进了本论文。

参考文献

Behrouz, A., Razaviyayn, M., Zhong, P., & Mirrokni, V. (2025). It’s All Connected: A Journey Through Test-Time Memorization, Attentional Bias, Retention, and Online Optimization (Miras). arXiv:2504.13173v1. ICLR 2026 (poster).

Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413v1.

Cognee (2026). Cognee documentation, docs.cognee.ai; GitHub: topoteretes/cognee. 访问日期:2026年6月12日。

Dadhich, G. (2026a). File vs Vector for RAG. Maximem 博客,2026年1月15日。https://www.maximem.ai/blog/file-rag-vs-vector-rag (数据:github.com/maximem-ai/file-vs-vector-study-results)

Dadhich, G. (2026b). Context Graphs: The Trillion Dollar Elephant. Medium,2026年1月22日。

Dong, Q., et al. (2024). A Survey on In-context Learning. arXiv:2301.00234v6. EMNLP 2024.

Edge, D., Trinh, H., Cheng, N., et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130v2.

Graves, A., et al. (2016). Hybrid computing using a neural network with dynamic external memory. Nature, 538:471–476.

Gupta, J., & Garg, A. (2025). AI’s trillion-dollar opportunity: Context graphs. Foundation Capital,2025年12月22日。https://foundationcapital.com/ideas/context-graphs-ais-trillion-dollar-opportunity

Gutiérrez, B. J., et al. (2024). HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. arXiv:2405.14831v3. NeurIPS 2024.

He, Zexue, Karlinsky, L., Kim, D., McAuley, J., Krotov, D., & Feris, R. (2024). CAMELoT: Towards Large Language Models with Training-Free Consolidated Associative Memory. arXiv:2402.13449v1.

He, Zihong, Lin, W., Zheng, H., et al. (2024). Human-inspired Perspectives: A Survey on AI Long-term Memory. arXiv:2411.00489v2.

Hu, Y., Zhu, J., Tang, L., & Huang, C. (2025). ReMindRAG:低成本大语言模型引导的知识图谱遍历,用于高效 RAG。arXiv:2510.13193v2。NeurIPS 2025。

Letta (2026). Letta 文档,docs.letta.com。访问于 2026 年 6 月 12 日。

Lewis, P., et al. (2020). 面向知识密集型 NLP 任务的检索增强生成。NeurIPS 2020。arXiv:2005.11401。

Li, Y., Huang, Y., Yang, B., et al. (2024). SnapKV:大语言模型在生成之前就知道你在寻找什么。arXiv:2404.14469v2。NeurIPS 2024。

Liu, N. F., et al. (2024). 迷失在中间:语言模型如何使用长上下文。TACL 12:157–173。arXiv:2307.03172v3。

Maharana, A., Lee, D.-H., Tulyakov, S., Bansal, M., Barbieri, F., & Fang, Y. (2024). 评估大语言模型智能体的超长期对话记忆(LoCoMo)。ACL 2024,第 13851–13870 页。arXiv:2402.17753v1。

Maximem (2026a). Synap 底层工作原理。maximem.ai 博客,2026 年 4 月 11 日。https://www.maximem.ai/blog/how-maximem-synap-works

Maximem (2026c). Maximem Synap 更新:更高分数、17 项集成和实时 Playground。maximem.ai 博客,2026 年 5 月 27 日。https://www.maximem.ai/blog/maximem-synap-updates-higher-benchmark-scores-and-more

Maximem (2026d). Synap:智能体记忆基准测试结果。GitHub:maximem-ai/eval_benchmark_runs_output(README、RESULTS.md、METHODOLOGY.md;CITATION.cff;CC BY 4.0)。访问于 2026 年 7 月 9 日。

Maximem (2026e). 记忆与上下文评估工具集。GitHub:maximem-ai/memory_and_context_eval_harness。

McKinsey & Company (2025). 2025 年 AI 现状:智能体、创新与转型。QuantumBlack by McKinsey,2025 年 11 月。https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

Mem0 (2026). Mem0 文档,docs.mem0.ai。访问于 2026 年 6 月 12 日。

Packer, C., et al. (2024). MemGPT:迈向将大语言模型作为操作系统。arXiv:2310.08560v2。

Rasmussen, P., et al. (2025). Zep:面向智能体记忆的时序知识图谱架构。arXiv:2501.13956。

Sarthi, P., et al. (2024). RAPTOR:用于树状组织检索的递归抽象处理。ICLR 2024。arXiv:2401.18059v1。

SuperMemory (2026). SuperMemory 文档,supermemory.ai/docs。访问于 2026 年 6 月 12 日。

SuperMemory(2026)。研究:LongMemEval 结果。supermemory.ai/research。访问于 2026 年 7 月 9 日(引自 Maximem,2026d)。

Suzgun, M., Yuksekgonul, M., Bianchi, F., Jurafsky, D., & Zou, J. (2025)。动态速查表:基于自适应记忆的测试时学习。arXiv:2504.07952v1。

Wang, Y., & Chen, X. (2025)。MIRIX:面向 LLM 智能体的多智能体记忆系统。arXiv:2507.07957v1。

Wu, D., Wang, H., Yu, W., Zhang, Y., Chang, K.-W., & Yu, D. (2024)。LongMemEval:面向长期交互式记忆的聊天助手基准评测。arXiv:2410.10813v2。ICLR 2025。

Xiao, G., 等(2024)。基于注意力汇聚点的高效流式语言模型。arXiv:2309.17453v4。ICLR 2024。

Zep / Graphiti(2026)。Zep 文档,help.getzep.com;Graphiti GitHub:getzep/graphiti。访问于 2026 年 6 月 12 日。

Zhang, Q., Hu, C., Upasani, S., 等(2025)。智能体上下文工程:面向自改进语言模型的上下文演化。arXiv:2510.04618v3。ICLR 2026。

附录 A 成本模型推导

设每一轮对话新增 token 数为 ,对话总轮数为 。全量追加方式在每一轮都会重新发送全部历史记录,因此第 轮的输入 token 数为 ,累计总量为tnkk⋅t

Cappend=∑k=1nk​t=t​n​(n+1)2.

有界预算系统将每轮输入 token 数限制为 :。成本倍数为WCbounded=n​W

R​(n)=CappendCbounded=t​(n+1)2​W,

随 线性增长。示例数值(,):nt=500W=4,000

轮数n 全量追加(token) 有界(token) 倍数
50 637,500 200,000 3.2×
100 2,525,000 400,000 6.3×
200 10,050,000 800,000 12.6×
500 62,625,000 2,000,000 31.3×

这些仅为示例数值,并非实测结果;它们假设每轮新增 token 数恒定,且未考虑缓存折扣——缓存折扣会改变常数项,但不会改变渐近趋势。每次调用的注意力计算量随每轮序列长度呈二次方增长,这使得全量追加方式的累计计算量大致随 呈三次方增长;我们之所以先给出计费结果,是因为这一结论更为清晰。n

第 3.2 节的前沿论证如下:全量追加以二次方成本换取保真度;粗粒度摘要以线性成本换取保真度的损失(Zhang 等人,2025 年记录到,单步压缩将 18,282 个 token 压缩至 122 个 token 后,准确率从 66.7% 降至 57.1%,低于无上下文基线);经过验证的压缩方案则以线性成本实现经过校验的保真度。→

附录 B 检索研究方法论(动机研究,第 3.3 节)

实验设置。五个覆盖不同检索场景的公开数据集:CodeXGLUE(自然语言代码)、MS MARCO(网页段落)、SQuAD(事实型问答)、HotpotQA(多跳推理)、SciQ(科学问答)。五个独立语料库:每个数据集 10,000 篇文档(合计 50,000 篇,按数据集分别建索引,而非合并为一个语料库),每个数据集 1,000 条查询(共 5,000 条),以 MRR@10 对照各数据集的金标准标注进行评分。检索底层:Tantivy 0.22.0(默认文本分析器)和 ChromaDB(0.4.0,默认索引),嵌入向量采用 all-MiniLM-L6-v2(384 维)。不做分块处理:文档整体建索引。硬件:Apple M4 MacBook Pro(10 核,16 GB 内存)。运行时间为 2026 年 1 月 14 日。公开报告(Dadhich, 2026a)以定性方式报道了这些发现;下表首次公布具体数字。各数据集的得分与配置已发布于 maximem-ai/file-vs-vector-study-results。→≥

媒体内容 · 前往原文查看
表 B1:各数据集 MRR@10,关键词检索 vs. 向量检索(每数据集 10,000 篇文档 / 1,000 条查询)
数据集(场景) 关键词检索(Tantivy) 向量检索(Chroma) 领先方
CodeXGLUE(自然语言代码)→ 0.290 0.914 向量检索,优势明显
MS MARCO(网页查询) 0.404 0.523 向量检索
SQuAD(事实型问答) 0.605 0.614 持平
HotpotQA(多跳推理) 0.549 0.495 关键词检索,微弱领先
SciQ(科学问答) 0.815 0.614 关键词检索,优势明显
媒体内容 · 前往原文查看
表 B2:向量代价:每 10,000 篇文档语料库的建索引墙钟时间
语料库 关键词建索引 嵌入向量 + 向量建索引 倍数
CodeXGLUE 0.45 秒 43.1 秒 97×
MS MARCO 0.42 秒 26.3 秒 63×
SQuAD 0.41 秒 35.9 秒 88×
HotpotQA 0.39 秒 29.5 秒 75×
SciQ 0.44 秒 26.7 秒 60×

局限性(完整列出;这正是第 3.3 节将该研究定位为动机而非基准测试的原因):单一操作者;一个关键词检索引擎对一家向量数据库。结果仅表征这一特定配置,而非抽象的检索方法。

  1. Single operator; one keyword engine against one vector store. Results characterize this configuration, not retrieval methods in the abstract.

  2. 未做分块处理。all-MiniLM-L6-v2 对超出其最大序列长度的输入会进行截断,因此在长文档上,向量索引实际上只对每篇文档的开头部分进行了嵌入。这会使长文本比较偏向不利于向量检索的一方;如果做了分块,向量检索结果在这些语料上很可能会有所提升。相比之下,CodeXGLUE 的自然语言到代码片段足够短,能适配模型的窗口长度,因此截断不会影响该语料,其 0.914 的结果依然成立。

  3. 各语料规模较小。10,000 篇文档的索引无法体现生产级向量检索的约束条件。

  4. 单一标准答案评分。HotpotQA 按每道题一个支撑文档进行评分;该评估设计无法衡量多文档充分性。3.3 节讨论了为什么这一局限本身具有信息价值。

  5. 评估运行器未保留逐查询的追踪记录;随附发布内容包含各数据集得分和评估代码,但不包含逐查询的输出结果。

  6. MS MARCO 的许可证限制了对段落文本的再分发;发布内容中排除了该语料的底层段落。

  7. 该研究仅对两种检索基底进行了孤立比较;未评估融合式混合流水线(例如,对词法结果与语义结果进行倒数排名融合)或第二阶段的交叉编码器重排序器,而这两者预计都会提升向量检索和混合检索的数值。该结论强调的是组合信号的必要性,而非对最佳可实现组合系统的度量。

3.3 节得出的结论——检索方法的体制依赖性(B1)、索引阶段的不对称性(B2)、以及基于命中的评分对充分性的结构性盲区——均不受注意事项 1–3 的影响,而注意事项 4 正是充分性论证的基础,而非对其的威胁。

附录 C 可复现性声明

对于第 6 节中的每一个结果,我们都明确说明:数据集及带问题数量的划分、答案模型和评判模型、完整的检索配置、测试框架提交 SHA、运行日期,以及我们公开发布的内容(测试框架代码、配置和逐问题的原始输出)。如果某个结果在发布时无法由第三方重新运行,我们会直接说明,而不会暗示其可复现。任何竞争对手的数据均遵循第 6.2 节中的两条规则:要么采用完全相同的协议,要么明确标注为自行报告的数据,且绝不在同一张表中混用。

附录 D 数据使用与隐私

Maximem Synap 处理可能包含个人信息的对话数据。在策略层面:记忆在架构上按租户隔离(存储层和查询层双重强制,见第 4 节);客户通过生成架构的护栏控制数据保留期限;个人身份信息受按智能体配置的提取时处理策略约束。本文不报告任何客户数据;基准测试结果均使用公开数据集。

来源:HuggingFace Daily Papers(社区热门论文) · arxiv.org