别再叫它"记忆"了：这篇论文把 Agent 的上下文问题拆成一条五段流水线

你有没有遇到过这种情况：一个 Agent 刚上线的时候挺灵光，跑了几百轮对话之后开始犯糊涂——用户上周明明说过预算砍半了，它还在按旧方案报价；更糟的是账单，对话每多一轮，token 费用就肉眼可见地往上窜。

我们之前的反应通常是"给它接个记忆库"。存起来，查出来，完事。但 arXiv 上的新论文（arXiv:2607.21503）直接对这个思路开炮：把上下文当成"存取问题"来解，框架本身就太窄了。记忆不是一个 store，而是一条从"决定记什么"到"决定忘什么"的完整生命周期。这篇论文把这个学科命名为 Agentic Context Management（ACM），拆成五个原语，还给了一套让我眼前一亮的成本经济学论证。

核心摘要

痛点：生产级 Agent 挂掉，多半不是推理不行，而是管不住自己上下文里那堆东西——对话历史、巨型 prompt、几十上百个工具定义、越滚越大的工具输出。agent 被自己的历史淹死，还按二次方的速度烧钱。

方案：把上下文管理重构为五个原语的生命周期——architecting（设计记忆形态）、ingesting（结构化摄取）、scoping（跨组织层级的作用域）、anticipating（预测性预取）、compacting & consolidation（带验证的压缩）。作者强调这五件事是耦合的，不是五个可以单买的工具。

效果：参考实现 Maximem Synap 在 LongMemEval 上拿到 92.0%（460/500），LoCoMo 类别 1–4 拿到 93.2%，而且用的是比竞品更小的 answer model（gpt-5-mini）。

我的判断：说实话，这是一篇"定位论文"多于"技术论文"——单作者、来自 Maximem 这家公司、评测是自家系统自报分数，sales pitch 的味道不轻。但它把行业里一直在踩的坑（成本二次方、压缩精度悬崖、向量税）用干净的公式和实验钉死在纸面上，单是 Table 1 那张失败模式对照表，就值回阅读时间。

论文信息

• 标题：Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems
• 作者：Gaurav Dadhich（Maximem）
• arXiv：https://arxiv.org/abs/2607.21503 （2026 年 7 月 23 日提交，23 页，6 图 4 表）
• 评测代码与数据：https://github.com/maximem-ai

🎯 为什么"记忆"这个词本身就是问题

论文里引了一个挺扎心的数字：McKinsey 2025 年的调研显示，多数企业都在试 AI Agent，但只有约四分之一报告实现了规模化，在任何一个单一业务职能里把 Agent 跑起来的不到 10%。绝大多数 pilot 死在进生产的路上。

死因往往不是模型笨。论文列的病灶很具体：长对话里忘掉用户早前说过的话；忘掉同一会话里工具刚取回来的内容；multi-agent handoff 时自相矛盾；上下文被塞到"超过有用临界点"之后开始幻觉。而账单的走法更难看——每多一轮，成本就涨一截。

问题在于，"memory"这个词命名了一个 store，于是围绕它建的系统只优化两个时刻：写和读。可生产平台每一轮都要做五个决策：

1. 刚说的这些话里，哪些值得留？
2. 以什么结构留？
3. 已留的所有内容里，哪一小撮属于这一轮？
4. 下一轮可能需要什么？
5. 相关内容超出模型预算时怎么办？

store 一个都不管。论文那句话我觉得说得挺到位：存储只是生命周期里的一个时刻，不是全部。

这里可以顺手掏点背景。过去两年这个赛道其实挺挤：Mem0 做的是"通用记忆中间件"，向量加图谱，主打开箱即用；Zep/Graphiti 主打时序知识图谱，事实带有效期窗口，旧事实失效而非删除；Letta（前身是伯克利的 MemGPT）让模型自己当内存管理器，主动决定什么进核心上下文、什么归档。这些系统各有绝活，但论文的观点是——它们都在解决生命周期里的某一两段，没有一家把五段当一回事。这个说法后面有对照表支撑，我们一会儿看。

🧠 五个原语：上下文生命周期的完整拆解

图1：五个原语画成一个围绕中心 Agent 上下文窗口的环——Architecting（设计记忆形态）→ Ingesting（从信号中抽取结构）→ Scoping（现在什么相关）→ Anticipating（下一步什么会相关）→ Compacting（塞进预算，保住要点）。右侧是作用域层级：user（一个人）→ customer（一个组织）→ client（平台运营方），窄域优先、严格隔离；另有独立的 global knowledge layer 喂给实体规范化。图底下那句话说得很直白：做好一个原语的是记忆工具，五个跨作用域全做好的才是上下文管理平台。

逐个聊。

Architecting（架构设计）。在存任何一条记忆之前，先决定这个 agent 的记忆长什么样：哪些信息类别重要、怎么提取、存哪、留多久、怎么检索和压缩。大多数系统用一套固定通用 schema 回答这些问题，论文主张 architecture 本身就是一等公民——客服 agent 和 coding agent 需要的类别、保留策略、压缩策略完全不同，不该共用一张表。

Ingesting（摄取）。把原始信号——对话轮次、多模态文档、工具调用和响应——转成结构化、可检索的记忆。这里有个我很认同的论断：检索质量的上限由摄取质量决定。你只存了"用户提到过一个价格方案"，事后任何检索术都变不出"用户 4 月 3 号从 Starter 升到了 Pro"。垃圾进，垃圾出，而且垃圾一旦进了库，就再也捡不回来细节。

Scoping（作用域）。在摄取和检索两端都要决定：已知内容的哪一部分、在哪个 scope 上与未来相关。这是跨组织层级的分层决策，要求严格隔离——一个用户的上下文绝不出现在另一个用户的会话里；同时 B2B 场景下，组织级信息可以不断富集，形成网络效应。

Anticipating（预判）。这个原语最有意思，借的是计算机体系结构里投机预取的老思想：观察 agent 的行为，在它显式开口之前就把可能需要的上下文备好，把检索挪出关键路径。普通检索回答的是"现在什么相关"，anticipatory retrieval 回答的是"接下来什么会相关"这个面向下一步的问题。价值不在去重，在延迟——命中时一轮阻塞往返变成一次 cache read，代价是 miss 时白做的投机工作。

Compacting & Consolidation（压缩与整合）。上下文超预算时必须收缩，但论文立了一条硬规矩：压缩必须可验证。悄悄丢掉关键事实的压缩比不压缩更糟，因为它产出的是自信的错答案。每次压缩要检查信息丢失，输出显式的 validation score 和 compression ratio，不达标就用更温和的策略自动重试。

作者特意点了一句：这五个原语是耦合的。第一个原语选定的架构，会改变其余四个该干什么。所以"拼装五个独立工具"和"把上下文当系统管理"是两回事——这句话其实就是整篇论文的题眼。

⚠️ Table 1：一张值得截图收藏的失败模式对照表

这是全文我最喜欢的一张表。它把生产里真实见过的故障，逐个映射到缺失的原语上：

那个 99.6% 有个小插曲值得说：原始帖子写的是 97.8%，作者在脚注里老老实实做了勘误——10,134 条里 38 条可用，正确算术是 99.6%。这种细节让我觉得作者至少是认真审过自己引用的数字的。

📊 成本经济学：三个公式把问题钉死

这一节是论文最硬核的部分，作者给三种策略各算了一笔账。

Full-append（大多数手搓 agent 的做法）：每轮重发全部历史。假设每轮新增 \(t\) 个 token，对话 \(n\) 轮，累计输入 token 是：

而有界预算系统（每轮固定 \(W\) 个 token）就是 \(C_{bounded} = n \cdot W\)，线性。两者之比 \(R(n) = t(n+1)/(2W)\)，随对话长度线性拉大——对话越长，full-append 挨的刀越重。

代入 t=500、W=4,000 的示例数字：100 轮时 full-append 是有界方案的 6.3 倍，200 轮 12.6 倍，500 轮直接 31.3 倍。更狠的是论文顺手提的一句：按 input token 计费是二次方，但每轮 attention 计算量对序列长度也是二次方，所以 full-append 的累计计算量其实是三次方。账单只是你能看见的那部分。

图2：累计输入 token（百万级）随对话轮数的变化。橙色 full-append 曲线是教科书式的抛物线，蓝色有界上下文几乎是平的；图上标出 100 轮 6 倍、200 轮 13 倍的差距。注意作者标注这是 illustrative 而非实测，但渐近结论不依赖具体常数。

Crude summarization（粗暴摘要）：成本压到线性了，但精度直接跳崖。论文引了 Zhang et al. (2025) 的记录：18,282 个 token 一步压到 122 个，任务准确率从 66.7% 掉到 57.1%——比完全不给上下文还差。等等，压完之后比不压还差？这个数字我第一次看的时候愣了一下，但它其实合理：丢掉关键细节的摘要不只没帮忙，还提供了错误的自信。

Validated compaction（带验证的压缩）：目标位置是"精度-成本前沿"的左上角——线性成本加经过检验的保真度。验证不是免费的（压缩和检查都烧 token），但压缩是周期性跑的，每次只作用于"已压缩上下文加最近几轮"，不是整个 transcript。设上下文维持在预算 \(W\) 附近、每 \(p\) 轮压一次、每次成本是有界上下文的 \(c\) 倍，N 轮总成本就是：

线性成本乘一个固定因子。取 p=8、c=2（1.25 倍固定开销），相对 full-append 基线的净节省：100 轮约 80%，200 轮约 90%，500 轮约 96%。

图3：横轴是每次对话成本，纵轴是任务准确率。Full-append 蹲在右上角（保真但贵），crude summarization 蹲在左下角（便宜但精度崩了），validated compaction 独占左上——同等保真、线性成本。一张图扛起了整节的论点。

说实话这套模型假设挺理想化的——恒定每轮 token、忽略缓存折扣。但作者自己承认缓存只改常数不改渐近，这个辩解站得住。O(n²) 对 O(n) 的差距，常数项救不回来。

🔬 向量税：一个让我重新思考检索栈的实验

论文第三章还埋了一个动机性研究，结论挺反直觉的。实验设置：五个公开数据集（CodeXGLUE、MS MARCO、SQuAD、HotpotQA、SciQ），每个 10,000 文档、1,000 查询，Tantivy 做关键词检索对 ChromaDB 加 all-MiniLM-L6-v2 做向量检索，比 MRR@10。

图4：左图是五个数据集上的 MRR@10 对比（蓝色关键词、橙色向量）；右图是建索引墙钟时间的对数坐标图，向量索引比关键词慢 60–100 倍。

结果两边互有胜负，而且胜负有规律：

规律很清晰：语义鸿沟越大（"sort a list" 要找 bubble_sort），向量越赢；查询词本身就是关键实体（"mitochondria" 就是钥匙，不是什么相似概念），关键词碾压。而右边那张图是真正的杀招——向量税：每 1 万文档语料，关键词索引 0.4 秒上下，embedding 加向量索引要 26–43 秒，慢 60 到 100 倍。当 agent 需要"现在读这份新材料、现在就行动"时，这不是学术数字，是真实约束。

还有个更深一层的发现：基于命中的评分对 reasoning-sufficiency gap 结构性失明——检出了相关文档，却漏了完成推理链所需的 bridge document，这种失败 hit-based 指标根本测不出来。这也解释了为什么作者的结论不是"关键词 vs 向量二选一"，而是必须 hybrid，还要叠 graph 来保住关系信息。

我得说句公道话：这个实验的局限作者在附录里列了七条（无 chunking 对向量侧有偏、single-gold-target 评分测不了多文档充分性、没测 RRF 融合和 cross-encoder 重排等等），态度是诚实的。但也确实只是单一配置下的快照，别当成普遍定律。

🏗️ 参考实现：Maximem Synap 长什么样

图5：块级架构图。左侧 Agent 应用通过 async-first SDK 接入（写入立即返回 ingestion ID，从不阻塞）；右侧托管多租户服务内，ARCHITECTING 在接入时为每个 agent 生成定制记忆架构并配置下游所有组件；INGESTING 是异步队列流水线（qualify → 提取五类记忆 → 实体解析 → 持久化）；SCOPING 做 user → customer → client 窄域优先检索，向量加图，带 provenance 标签和 token 预算；ANTICIPATING 在显式请求到达前备好上下文；COMPACTING 是已验证操作（信息丢失检查、validation score、自动重试）；底层是 polyglot 存储：ChromaDB、Neo4j、Postgres、S3 兼容对象存储、时序遥测、Redis 队列缓存。

几个设计决策我觉得值得单独拎出来：

• 写入零阻塞：memory-write 调用立即返回 ingestion identifier，提取、实体解析、入库全在后台。这是刻意的取舍——记忆读远多于写，用立即一致性换延迟不划算；会话内的 read-your-writes 靠工作上下文里逐字携带的最近几轮保证。
• 实体解析跑级联：从精确标识符逐步退到 lexical、semantic、contextual 信号，按置信度排序。公共实体对 global knowledge layer 查，没见过的注册到 customer scope。"Sarah Chen" 和 "SC" 终于被认成同一个人了。
• 图感知检索：向量相似度只决定图的入口，然后做 vector-guided multi-hop traversal——这正是回应前面那个 bridge-document 问题。
• 预取命中率：作者说 anticipatory path 目前跨客户稳定 60%+ 命中率。这个数字是自家口径，没有第三方验证，但方向我信。

集成侧的代码干净得有点过分，每轮三次调用围着一次模型调用转：

retrieved = FETCH(query=user_message, scope={user, customer})  # 带作用域检索
compacted = COMPACT(current_conversation)                      # 带验证的压缩
reply     = MODEL(assemble(retrieved, compacted, recent_turns))
INGEST(turn, scope)                                            # 异步，立即返回 id

作者特意说：看点在于这段代码里缺席的东西——没有 schema 设计、没有 embedding 模型选型、没有索引管理、没有隔离逻辑。这些全是生命周期的职责，被收进平台里了。

🧪 实验：92 分和 93.2 分，但请先看清口径

评测配置（Table 2）：LongMemEval 完整 500 题全部 6 类，LoCoMo 官方 locomo10 且按惯例排除对抗性的 category 5（不可回答的问题，测的是 abstention 而非记忆，纳入与否能让头条分数移动 10 分以上——这是 LoCoMo 数字互不可比的最常见来源）。Answer model 和 judge 都是 gpt-5-mini，harness 开源在 maximem-ai/memory_and_context_eval_harness。

图6：左图 LongMemEval 六类——single-session-user、single-session-preference、knowledge-update、temporal-reasoning 四类全满分 100%，single-session-assistant 87.5%，multi-session 只有 75.2%，overall 92.0%；右图 LoCoMo 类别 1–4——multi-hop 97.3%、open-domain 93.4%、temporal 90.8%、single-hop 88.8%，overall 93.2%。

分项数字摆在这，残差集中在 multi-session 的 75.2 分——必须跨独立会话联结信息的推理。作者承认这对他们所知的一切系统都是最难的已发布类别，而且正好落在前面说的 reasoning-sufficiency 区间。这个自我暴露我给好评。

再看横向对比，这里要非常小心口径：

论文自己立了两条规矩：完整披露自家配置；绝不把不同 methodology 的数字并列当 head-to-head。这张表只是"published landscape"，行间互不可比。但有一个事实确实成立：Synap 的 92 分是用更小的 answer model 拿到的，而 SuperMemory 自己的 sweep 显示换个 answer model 分数就能摆 3.6 个点。这暗示收益来自上下文层而非 answer model——这是全文最有分量的一条间接证据。

不过该泼的冷水还得泼：这是单作者论文，作者就是 Maximem 的人，测的是自家系统，分数是自报的。harness 和数据公开了是好事，但 per-run artifacts 目前是"应要求提供"而不是直接公开。92% 这个数我会先打个八折放在心里，等第三方复现。

🤔 我的判断

这篇论文值钱的不是某个新算法，而是三样东西。

一是分类学本身。 Table 1 那张失败模式对照表，如果你在生产里运维过 Agent，大概率每一行都踩过。把"agent 又犯傻了"翻译成"缺了哪个原语"，这个诊断框架本身就有工程价值——下次再看到 scope bleeding 或者垃圾堆积，你知道该补哪块板。

二是把成本账算明白了。 O(n²) 对 O(n) 不新鲜，但加上"压缩精度悬崖"和"带验证压缩的固定因子开销"这两笔账，就凑齐了一个完整的决策三角形：成本、保真、延迟，你最多只能在验证的护航下拿到线性成本加保真。粗暴摘要那条路，数据已经判了死刑。

三是 anticipatory retrieval 这个方向。 把体系结构里的投机预取搬进 agent 上下文，我觉得这可能是五个原语里被低估的一个。现在大家卷的都是"检索得准不准"，很少有人卷"检索发生在不在关键路径上"。

问题也不少。benchmark 不测延迟、不测 token 效率、不测 context-rot 抗性——作者自己承认这三个生产团队最看重的维度全是空白，只说"后续论文再补"。Table 4 那张系统覆盖矩阵（把 MemGPT/Letta、MIRIX、Mem0、Zep、SuperMemory、Cognee 按五个原语打勾，只有 Synap 五格全满）说到底是为自家定位服务的营销物料，虽然作者用"按其公开文档所述焦点"的措辞留了余地。还有那个万亿级 decision-level context 的展望——"不只记录发生了什么，还记录组织为什么做这个决定"——方向性感，但作者列的未解难题（决策大多隐式、rationale 常是事后合理化、因果归因难）条条都是硬骨头，离落地远着呢。

回到工程上。如果你正在给自家 Agent 选记忆方案，这篇论文给的最实用建议其实是：别急着选型，先拿 Table 1 对照自己系统的故障，想清楚你缺的到底是哪个原语。只缺存取，Mem0、Zep 这些现成轮子够用；如果痛点在成本爆炸和压缩失真，那带验证的压缩和有界上下文是必须自己做的功课，市面上没有开箱即用的答案。

论文结尾那句话收得不错：接下来的竞争不在于谁存的数据最多，而在于谁把上下文管理得最好。存，早就不是护城河了。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我