HyperAIHyperAI

Command Palette

Search for a command to run...

4 小时前
Agent

智能体上下文管理:将智能体记忆与成本视为生命周期和架构问题加以解决

Gaurav Dadhich

摘要

生产级 AI 智能体的失败,往往并非因为推理能力不足,而是因为它们无法管理推理上下文中的内容;它们必须在上下文中持有大量信息:对话历史、冗长的提示、庞大的工具定义以及不断膨胀的工具输出。它们淹没在自己累积的历史中,同时为每一轮不断增长的 token 成本买单,导致在同一对话内以及跨对话间出现记忆缺失。当前的主流应对方式将此视为一个存储与检索问题。我们认为这种框架过于狭隘。我们提出,主动管理智能体所持有的信息是一个生命周期问题,而不仅仅是存储问题:它涵盖决定记住什么、提取并结构化信息、为不同数据类型选择合适的存储、构建最优冗余、有意识地巩固、在保持来源的同时遗忘过时信息、决定当前轮次的相关内容、预测下一步所需,以及压缩上下文以适应预算而不丢失关键信息、不损害回忆能力等。在严肃的生产级智能体中,这一过程不仅针对单个用户,而是跨越组织范围层级运作。我们倾向于将这一学科命名为智能体上下文管理(Agentic Context Management,ACM)(正如过去一些人所做的那样),并将其分解为五个原语:架构设计、摄入、范围界定、预测以及压缩与巩固。随后,我们从经济学角度论证了为何受管理的生命周期并非奢侈品:朴素的上下文积累会使 token 成本随对话长度呈二次方增长,粗略的摘要以准确性断崖为代价换取线性成本,而只有经过验证的压缩才能在保持保真度的同时实现线性成本。我们描述了一个参考实现 Maximem Synap,它作为一个多租户服务实现了这五个原语,并在第 6 节详述的配置下,在 LongMemEval 上达到 92% 的得分,在 LoCoMo 上达到 93.2% 的得分。最后,我们讨论了现有基准尚未捕捉到的维度,即延迟、token 效率和上下文衰减抵抗能力,以及该类别所指向的决策级和组织级上下文的开放前沿;但这些维度持续决定着严肃场景中智能体效用的稳定性和可用性。

一句话总结

Gaurav Dadhich 引入 Agentic Context Management (ACM),将 agent 记忆重新定义为包含五个原语(架构设计、摄取、范围界定、预测、压缩与整合)的生命周期问题,这些原语经济地将 token 成本从二次降低到线性,同时保持保真度,参考实现 Maximem Synap 在 LongMemEval 上达到 92%,在 LoCoMo 上达到 93.2%。

核心贡献

  • 论文将 Agentic Context Management (ACM) 引入为由五个原语(架构设计、摄取、范围界定、预测、压缩与整合)组成的生命周期,将视角从静态存储转向主动的、多轮上下文编排。
  • 经济分析表明,朴素的上下文累积导致 token 成本二次方增长,粗粒度摘要产生线性成本但会遇到准确度悬崖,只有经过验证的压缩才能以线性成本保持保真度,从而将生命周期确立为实际必要。
  • 参考多租户服务 Maximem Synap 实现了这五个 ACM 原语,报告在 LongMemEval 上达到 92%,LoCoMo 上达到 93.2%,同时识别出在延迟、token 效率和上下文衰减抗性方面的基准测试缺口。

引言

作者观察到,生产环境中的 AI agent 常常不是因为推理失败而踉跄,而是由于无纪律的上下文管理:agent 忘记先前指令,因窗口过载而产生幻觉,并因盲目追加整个历史而招致膨胀的成本。主流视角将此视为一个仅仅存储和检索事实的“记忆”问题,却忽略了必要的生命周期决策——保留什么,如何结构化,哪一部分属于当前轮次,接下来要预测什么,以及如何在预算下安全压缩上下文。作者将挑战重新定义为 Agentic Context Management,这是一个围绕五个原语——架构设计、摄取、范围界定、预测、压缩/整合——组织的系统,在用户、客户和组织范围内协调运行。他们证明,朴素的全追加上下文导致 token 成本为 O(n2)O(n^2)O(n2),而受控压缩则实现了线性成本的高效前沿,并具有验证保真度,并提供了一个实现完整生命周期的参考实现(Maximem Synap)。

方法

作者引入 Maximem Synap,这是一个多租户托管上下文管理平台,将 agentic context management 的五个原语实现为一个连贯的生命周期,而不是孤立的工具。该系统旨在解决朴素存储-检索方法的失败模式:无界上下文导致的成本爆炸,未经检查的压缩导致的准确度崩溃,以及仅评分命中但遗漏了 agent 推理所需上下文桥梁的检索导致的推理不足。

Maximem Synap 的核心是一个自主的架构设计步骤。当 agent 连接时,系统根据客户对 agent 用途的描述和参考资料,合成一个定制的记忆架构。这个设计通过多 agent 的 LLM 推理和验证生成,决定了要捕获的记忆类别(事实、偏好、情节、情感、时间事件等),它们如何被提取、存储、检索和压缩,以及哪些实体和关系是重要的。这个架构支配着下游的每一个原语,使原语之间的耦合变得具体:一个客服 agent 和一个编程 agent 会得到不同的类别模式、保留策略和压缩规则,所有这些都体现在一个生成的文档中。

摄取是一个异步的、基于队列的流水线。文档或对话轮次通过一个异步优先的 SDK 提交,该 SDK 会立即返回一个摄取标识符而不会阻塞调用应用程序。在后台,流水线对内容进行鉴定,按照 agent 架构指示提取记忆类别,并解析实体。实体解析运行一个按置信度排序的匹配策略层叠——从精确标识符到词汇、语义和上下文信号——将表面提及链接到客户范围内的标准实体。公共实体通过全球知识层进行验证;新实体则被注册。提取和解析结果跨多语言存储栈进行持久化:关系存储作为事实来源,向量存储用于基于嵌入的搜索,图存储用于实体-关系遍历,对象存储用于原始内容,以及专门的存储用于时间序列遥测和队列/缓存。即时一致性的权衡是有意为之:会话内的写后读通过将最近的轮次原样携带在记忆中来满足,因此 agent 在最新信息上运行,而持久的、结构化的可用性则被推迟而不阻塞。

检索是一个感知范围、预算意识的流水线,以最窄优先的方式解析组织层级:用户、客户、然后是客户端,并在存储和查询层都实施严格的隔离。它组装带有来源标记的、排序的、适合 token 预算的记忆项。提供两种检索模式:低延迟路径和高准确度路径,后者增加了查询分解和 LLM 重排序。关键的是,系统将向量相似性与向量引导的多跳知识图谱遍历相结合。语义相似性指示从哪里进入图谱以及跟随哪些关系,从而浮现在纯向量搜索中会遗漏的相关记忆——直接解决了导致推理不足的桥梁文档问题。

预测被视作一个区别于显式查询时检索的检索原语。Maximem Synap 实现了一个预测路径,根据 agent 不断演变的行为预测它在显式请求到来之前可能需要的上下文。这个准备好的上下文在需要时作为缓存读取,将检索从 agent 的关键路径上移出,从而减少延迟。预测机制是专有的;作者报告了生产中持续超过 60% 的命中率,其价值在于降低延迟而非去重。

压缩和整合被设计为经过验证的操作。对于长对话,Maximem Synap 压缩上下文然后针对原始内容验证结果:它测试关键信息是否仍可恢复,并输出一个显式的验证分数和压缩比。如果分数低于阈值,则自动以较低的激进度重试压缩。这种类别感知的压缩——哪些内容必须逐字保留,哪些可以被抽象化,由 agent 生成的架构决定——避免了未经验证的摘要带来的灾难性准确度损失。为了保持验证开销线性,压缩定期针对已经压缩过的上下文加上最近的轮次进行,而不是对整个对话记录。NNN 轮后的总 token 成本遵循 NW(1+c/p)N \cdot W \cdot (1 + c/p)NW(1+c/p),其中 WWW 是 token 预算,ppp 是压缩频率,ccc 是一个固定因子;这是被一个常数因子提升的线性成本,与追加完整历史的二次方膨胀相比,带来了巨大的节省。

该平台为每次模型调用暴露一个简单的三步集成模式:过去上下文的范围检索,当前对话的验证压缩,新轮次的非阻塞摄取。应用代码从不需要接触模式设计、嵌入模型、索引管理或隔离逻辑;这些完全由生命周期的原语和生成的架构处理。这些设计选择——综合架构、验证压缩、异步摄取、具有强制隔离的一等范围界定、混合语义-关系检索和预测性延迟设计——直接解决了在存储-检索系统中观察到的生产失败模式,并实现了论文所主张的大规模 agentic 记忆所需的生命周期。

实验

评估使用 LongMemEval 和 LoCoMo 来验证对话记忆,其中多会话推理是最困难的,这反映了一个更广泛的推理充分性差距:标准检索基准衡量的是命中率,而非所有必要的上下文是否都已出现,向量搜索和关键词搜索在互补的领域中取胜。尽管存在这一差距,该系统凭借其上下文层而非庞大的答案模型取得了强劲的结果,凸显了对混合检索和直接评分充分性及生产维度进行评估的新需求。

生产记忆系统以对应于缺失上下文管理原语的不同模式失败。摄取和架构设计的缺失导致垃圾累积、细节丢失和身份碎片化;范围界定不足导致范围泄漏和跨会话失忆;未经验证的压缩会产生准确度悬崖,可能导致性能低于无上下文的基线。垃圾累积、细节丢失和身份碎片化均源于缺失的摄取和架构设计原语,包括当在没有提取的情况下存储原始信号时,一个现实世界中 99.6% 的垃圾率。没有范围界定会导致范围泄漏和跨会话失忆,而未经验证的压缩会产生准确度悬崖,在激进压缩后性能降至无上下文基线以下。

比较了三种上下文管理策略:全追加、粗粒度摘要和验证压缩。全追加导致 token 成本二次方增长,并受到上下文退化(如“中间丢失”效应)的影响,而粗粒度摘要具有线性成本但面临因丢弃相关细节而导致准确度悬崖的风险。验证压缩以线性成本实现保持和检查过的保真度,正如 Maximem Synap 的 92.0% LongMemEval 得分所证明的,避免了两种失败模式。全追加具有 O(n2)O(n^2)O(n2) 的 token 成本,并最终因上下文衰减而失败,例如“中间丢失”现象。粗粒度摘要将成本降至 O(n)O(n)O(n),但它是有损且未经验证的,当下游重要的内容被丢弃时,会产生准确度悬崖。验证压缩在保持和检查所需信息的同时维持了 O(n)O(n)O(n) 的 token 成本,使其成为没有固有失败模式的目标。经过验证的压缩实现达到 LongMemEval 的 92.0%,确认保持和检查过的保真度防止了粗粒度摘要中看到的准确度悬崖。

Maximem Synap 在 LongMemEval 对话记忆基准上达到 92.0% 的整体准确率,在 LoCoMo 类别 1-4 上达到 93.2%,两者均使用透明配置和小答案模型(gpt-5-mini)进行评估。多会话推理被证明是最具挑战性的 LongMemEval 类别(75.2%),这与各系统的整体模式一致。持续使用较小的答案模型表明,性能提升来源于记忆和上下文检索层。该系统使用 gpt-5-mini 作为答案和评判模型,在 LongMemEval(全部 500 个问题)上达到 92.0%,在 LoCoMo 类别 1-4 上达到 93.2%。多会话推理需要从不同的对话中整合信息,分数为 75.2%,是最弱的类别,这突显了各个已公布系统广为人知的困难。LoCoMo 的对抗性无法回答类别(类别 5)按照官方惯例被排除,以防止人为的分数波动并与先前工作保持可比性。评估工具(maximem-ai/memory_and_context_eval_harness)和方法是公开记录的,单次运行的产物可根据要求提供,以支持可复现性。使用比许多竞争配置更小的答案模型表明,性能优势来源于上下文管线,而不是答案模型的规模。

自我报告的 LongMemEval 得分显示 Maximem Synap 使用比竞争配置更小的答案模型达到 92.0%,而其他系统则对答案模型切换表现出敏感性。由于每行使用不同的方法、评判和设置,这些数字无法直接比较;多会话推理对于所有记录的系统来说仍然是最困难的类别。Maximem Synap 使用 gpt-5-mini(一个比最强竞争对手配置小的答案模型)在 LongMemEval 上达到 92.0%,表明提升来自上下文层而非答案模型。SuperMemory 的 LongMemEval 结果在仅更换答案模型的情况下从 81.6% 到 85.2% 不等,显示出记忆基准对评估选择的高度敏感性。多会话推理是 Maximem Synap 最弱的类别,为 75.2%,并被描述为每个已知系统已公布的最难类别。该表格仅列出了每个供应商在不同方法下的最佳自我报告数据,不能被当作头对头对比。

在调查的记忆系统中,没有一个系统公开宣布完全覆盖所有五个原语。摄取和范围界定最常作为主要或部分功能出现,而压缩与整合仅对一个系统是主要重点。架构设计对某些系统是主要关注点,对其他系统则不存在,揭示了分歧的设计优先级。MemGPT/Letta 是唯一将压缩与整合列为主要重点的系统。除了 ACE/Dynamic Cheatsheet 外,每个系统都至少部分支持摄取,使其成为最普遍的原语。架构设计是 MIRIX、Mem0 和 SuperMemory 的主要关注点,但并非 MemGPT/Letta、Zep/Graphiti 或 Cognee 的明确关注点。七个系统中的六个部分或完全覆盖了范围界定,其中 Zep/Graphiti 和 MemGPT/Letta 对此给予主要强调。预测从未被列为主要关注点;它仅在四个系统中作为部分或可选功能出现。

这些实验评估了生产记忆系统中的失败模式与策略,表明缺失摄取和架构设计原语会导致垃圾累积和身份碎片化,而范围界定不足则导致范围泄漏和失忆。对全追加、粗粒度摘要和验证压缩的比较发现,只有验证压缩能维持线性成本和准确度,正如 Maximem Synap 使用小答案模型在 LongMemEval 上达到 92.0% 所证明的。多会话推理对于所有系统来说仍然是最困难的类别,对七个系统的调查显示没有系统覆盖全部五个原语,压缩和预测是涉及最少的。


用 AI 构建 AI

从创意到上线——通过免费 AI 协同编码、开箱即用的环境和最优惠的 GPU 价格,加速您的 AI 开发。

AI 协同编码
开箱即用的 GPU
最优定价

HyperAI Newsletters

订阅我们的最新资讯
我们会在北京时间 每周一的上午九点 向您的邮箱投递本周内的最新更新
邮件发送服务由 MailChimp 提供