你的 Agent 有 1000 万上下文，为什么第 50 轮就开始失忆？

过去三年，大模型最响亮的头条指标是上下文窗口。它从 ChatGPT 发布时的 8,192 token，涨到 100 万，再到 Llama 4 Scout 宣称的 1,000 万，以及 Magic.dev LTM-2-Mini 宣称的 1 亿。

隐含的承诺是：记忆是一个容量问题，而容量正在被解决。

它没有。NVIDIA 的 RULER 基准测得有效上下文大约只有标称值的 50%--65% ；Chroma 的"上下文腐烂"（context rot）研究测了 18 个前沿模型，每一个 都随输入变长而退化；Google 自家的 Gemini 3 Pro 在 MRCR 上从 128K 的 77% 掉到 1M 的 26.3%。

这篇文章讲三件事：为什么加大窗口救不了你、真正管用的"上下文生命周期"长什么样、以及------最关键也最少被讲的------那些公开的记忆系统跑分，为什么大半不能直接比较。

---

一、旧范式的原罪：把"记忆"当成了"容量"

先看一个类别错误（category error）。业界混淆了两种完全不同的评测：

长上下文评测（long-context eval）
  └─ 一次性喂入 100K / 1M / 10M token 的输入
  └─ 要求模型在单次前向过程中检索、总结或推理
  └─ 输入是固定的。什么都没写入。调用返回后什么都没留下。

记忆评测（memory eval）
  └─ 系统按时间顺序接收一串输入
  └─ 要求它往某个存储里写入东西
  └─ 然后在之后的某一轮，从这个存储里取回来

这是两件事。前者测的是"一次性阅读理解"，后者测的是"跨时间的状态管理"。

而你的 Agent 出问题的地方，几乎总是在后者。

1.1 大窗口为什么会"腐烂"

原因不在显存，在注意力本身的结构。

第一，注意力是预算，不是内存。 每个 token 都要和其他每个 token 竞争注意力权重。token 之间的两两关系数量是平方级增长的，而模型干净地加权这些关系的能力不是。"更多上下文 = 模型知道更多"是错的，正确的是"更多上下文 = 对同一份注意力的更激烈竞争"。

第二，位置编码自带衰减。 主流模型用 RoPE（Rotary Position Embedding，旋转位置编码），它对两个 token 之间的直接注意力会随着距离增加而自动衰减。开头（system prompt）和结尾（最新信息）注意力强，中间形成一片低注意力区。

第三，"中段迷失"至今没被解决。 2023 年斯坦福与 UC Berkeley 的工作首次量化了 lost-in-the-middle 效应：当关键事实位于上下文中部时，准确率下降超过 30%。2026 年的生产模型减轻了这个效应，但没有一个彻底消除它。

1.2 退化起点，取决于任务类型

"50% 法则"（把任务控制在窗口的一半以内）太粗糙了。真实的退化起点更接近一个绝对 token 阈值（大约 32K--100K），而不是窗口的固定百分比，并且因任务类型差异巨大：

任务类型	代表基准	有效上下文	说明
简单检索（NIAH）	Gemini 1.5 技术报告	10M token 内 >99% 召回	误导性乐观，见下文
语义检索	NoLiMa	13 个模型中 11 个在 32K 就掉到基线 50% 以下	去掉词汇重叠线索后崩溃
多跳检索	RULER	标称窗口的 16%--50%	只有最好的模型能到 50%
推理	BABILong	上下文的 10%--20%	"主流 LLM 有效利用率仅 10--20%"
代码缺陷修复	LongCodeBench	Claude 3.5 Sonnet：32K 时 29% → 256K 时 3%	严重塌方

不要用 NIAH（大海捞针）的数字来为大上下文加载背书。 NIAH 的"针"和"问题"之间有很高的词汇重叠，模型可以靠字面匹配蒙对；NoLiMa 去掉这个线索后，13 个模型里 11 个在 32K 就崩了。

1.3 一个反直觉的发现

Chroma 的研究里有一条很多人忽略的结论：逻辑连贯的文档，反而比随机排序的文本更难检索。

原因是连贯文本给注意力机制提供了一个"看起来很合理的替代叙事"------模型会顺着通顺的段落推理下去，把它当成答案。而用 --- 分隔、带显式标记的碎片化文本，模型反而更容易跳过。

直接推论：检索回来 8 个 chunk，保留 ## Source N 这样的显式分块标记再拼接，效果通常好于把它们改写成一段流畅的摘要。后者人读起来更舒服，而这正是它输的原因------它对模型来说也读起来更舒服。

---

二、新范式：把上下文当作一条生命周期来管理

2.1 五个阶段

2026 年逐渐成型的做法，是把上下文管理拆成五个原语，而不是一个"存起来再取"的存储：

阶段	要做的决定	最常见的错误
Architecting（架构）	哪些类别重要、各存哪里、保留多久、怎么取	指望存在一套通用 schema
Ingesting（摄入）	把原始信号（对话轮次、文档、工具输出）转成结构化条目	直接把原始对话塞进去
Scoping（定界）	在用户 / 团队 / 组织层级上决定可见性，并严格隔离	跨用户串数据
Anticipating（预取）	在模型开口之前，把可能需要的上下文先取好	等到阻塞了才查
Compacting & Consolidating（压缩与巩固）	压到预算内，同时验证关键事实仍可恢复，并保留溯源	压完就不管了

关键在最后一条：压缩必须是"带校验的有损变换"，不是"丢掉就算了"。

2.2 为什么这件事值得做：O(n²) → O(n)

厂商按输入 token 计费。朴素做法（每轮把完整历史重新拼上）的成本是：

朴素全历史追加：第 k 轮要重发前 k-1 轮的全部内容
  → 总成本 ≈ Σ(k) = O(n²)

有界上下文（每轮只装入预算内的内容）
  → 总成本 ≈ O(n)

在一个有代表性的费率下，这个差异在 100 轮时约为 6 倍，500 轮时约为 31 倍。

对跑了 5 小时、几千次工具调用的 Agent 来说，这不是优化，是能不能上线的区别。

2.3 三种被验证有效的结构

① 分层记忆（tiered memory）。 MemGPT / Letta 把上下文当虚拟内存管理：工作记忆持有当前任务上下文，冷数据从情景/语义存储里换入换出。生产系统通常收敛到三层：

活动上下文   最近 5--10 轮，全保真            ~20--30K token
工作记忆     最近约 50 轮，轻度压缩（~60%）   按需换入
归档记忆     全量历史，重度压缩 + 外部文件     按需检索

关键在于压缩梯度：近的轻压、远的重压、更远的归档或丢弃。这样避免了"全局同质化压缩"导致的长程推理断裂。

② 子代理上下文隔离。 这是研究中收益最明确的单一策略。Anthropic 在 2025 年 6 月公开其多智能体研究系统：主代理（Opus 4）协调，子代理（Sonnet 4）各领一条研究线，每个子代理持有自己的隔离上下文 ，完成后只回传摘要。报告的性能提升是 90.2% ，并且他们发现------token 使用量解释了两个架构之间 80% 的性能差异。

代价：整个系统消耗约 15 倍的 token。子代理通常只回传 1,000--2,000 token。

用 Go 并发模型的那句话总结：通过通信来共享记忆，不要通过共享记忆来通信。

③ 结构化状态累积。 与其总结对话，不如维护一份结构化的状态文档，让 Agent 每轮增量合并新信息。Factory 在 36,611 条真实工程会话消息上的评测显示，把新摘要合并进持久化状态文档，在准确性、完整性和连续性上都优于"逐字保留历史"和"每轮重新摘要"。

具体分数（压缩质量）：Factory 自研方案 3.70 、Anthropic 3.44、OpenAI 3.35，压缩率均超过 98%。ACON 框架在 AppWorld、OfficeBench 与多目标 QA 上把峰值 token 降了 26%--54%，且不需要微调。

---

三、理想丰满，现实骨感：五个工程死结

这一节决定你能不能真的把它跑起来。

死结一：上下文坍缩（context collapse）

当 Agent 反复重写自己的上下文时，每一次重写都倾向于更简略，逐步磨掉领域细节。多轮之后，上下文"坍缩"成一个看起来很整洁、但已经失去关键信息的空壳。

ICLR 2026 的 ACE（Agentic Context Engineering）论文直接命名了这个问题，给出的解法是把上下文表示为结构化的条目化要点集合，增量更新，而不是整块重写。它用 Generator / Reflector / Curator 三个角色往一份不断演进的 playbook 里增补和修正条目。

一句话总结：增量、追加式的上下文更新，胜过整体重写。

死结二：上游抽取失败，后面全白搭

检索质量的上界由摄入质量决定。一次审计给出的数字触目惊心：10,134 条摄入条目中只有 38 条可用，垃圾率 99.6%。

如果抽取层不可靠，生命周期的下游每一级都只是在放大噪声。做架构时，先验证 Ingesting，再谈 Compacting。

死结三：全时记忆注入，可能比什么都不做更差

直觉是"多给点记忆总没坏处"。消融实验的结论相反：选择性干预 > 全时注入 > 被动暴露记忆。

所以"合并"和"召回"这两级上，必须有一个相关性闸门。它不是优化项，是承重结构。

死结四：记忆是新的攻击面

持久化存储会随时间累积投毒风险与陈旧事实风险。与传统数据库不同，这里的写入方是一个会被提示词注入影响的模型，读取方又是一个会把内容当作事实来推理的模型。

治理维度目前没有标准指标------但至少应该测：隐私泄露率、删除合规性、访问越界次数。

死结五：你看到的跑分，可能不可比

这是最需要说清楚的一点。

问题	证据
答案键本身有错	独立审计发现 LoCoMo 的 ground-truth 中约 6.4% 不正确（幻觉事实、说话人张冠李戴、日期计算错误）
裁判模型放水	同一个审计中，LLM 裁判接受了约 63% 的故意构造的错误答案
同一系统分数天差地别	同一套系统在 LoCoMo 上被不同 harness 评出 38% 到 92%
"LoCoMo"指两个不同的东西	完整数据集是 50 个对话 / 7,512 题；而多数厂商实际跑的是约 10 个对话 / 1,986 题的子集
暴力基线能打赢专用系统	在饱和的基准上，把全部历史塞进窗口这个基线，常常能匹敌甚至击败专用记忆系统

所以：看到"92% on LoCoMo"先别激动，先问是哪个 LoCoMo、哪个 harness、哪个裁判模型、哪个产品版本。

---

四、怎么读一个记忆系统的分数：多轴镜头

质量只是一个轴。最便宜的赢法，是干脆不做记忆系统------把整个历史塞进上下文。在饱和基准上，这个暴力基线很有竞争力。

所以至少要四个轴一起看：

轴	测什么	为什么并列
质量	准确率、召回率、矛盾率、陈旧率	头条数字，但最容易靠大窗口刷出来
延迟	每次记忆操作的 p50 / p95	10 秒才返回的正确答案，在实时 Agent 里没用
Token 成本	注入记忆消耗的 prompt token、存储增长	直接决定账单和上下文预算
治理	隐私泄露率、删除合规、访问越界	尚无标准指标，但迟早会成为硬门槛

BEAM：把终点线挪到 1000 万 token

BEAM（Beyond a Million Tokens）是目前最完整的会话记忆基准。它的构造本身就是方法论上的一个进步：

100 个对话，分四档：20 @ 128K · 35 @ 500K · 35 @ 1M · 10 @ 10M
每对话 20 题 → 共 2,000 道人工校验题
10 项能力：信息抽取、多跳推理、知识更新、时序推理、
           偏好遵循、指令遵循、总结、时序事件排序、
           拒答、矛盾消解
评分：把参考答案拆成原子事实"nugget"，每个打 0 / 0.5 / 1 后取平均

两个设计要点值得抄：

1. 叙事连贯，而不是拼接。 很多"长"基准把不同用户的无关会话缝在一起，造成话题突变------这反而让任务变简单了，模型靠局部检索就能过关。BEAM 生成的是单一用户、话题连贯的长对话，同一个人、同一件事反复出现，后面的信息还可能与前面的矛盾。
2. 十项能力里三项是它新增的：矛盾消解（发现冲突应该要求澄清，而不是单方面选边）、事件排序、跨时间指令遵循。

结果（论文报告）：

• 长上下文模型在最短档得分约 0.24--0.28 ，到 10M 档掉到 0.10--0.13。
• 关键的是：性能在历史长度还没超出上下文窗口时就开始下降了，1M 档上已经在跌。
• 论文提出的结构化记忆系统（LIGHT）带来 3.5--12.7% 的提升；在 10M 档，部分模型的提升超过 100%------因为在那里完整历史已经装不进窗口了。

两点必须如实说明 ：其一，BEAM 在公开记录中是一篇 arXiv 预印本（编号 2510.27246），流传的"ICLR 2026"出处未经确认，引用时应按 arXiv 处理；其二，市面上一些 BEAM 高分（例如某结构化记忆方案在 10M 档报 64.1%、传统 RAG 报 24.9%）来自厂商自有博客与自有 harness，不等于独立复现。

---

五、可执行清单

5.1 先定工作上限，别用标称窗口

标称 1,000,000  →  RULER 有效 500K--650K  →  生产工作上限 250K--350K
标称   200,000  →  RULER 有效 100K--130K  →  生产工作上限  50K--80K

NVIDIA 2026 年 4 月的长上下文工程建议是：生产环境检索增强型 Agent 的 prompt 控制在标称窗口的三分之一以内 ，其余留给输出和余量。更保守的团队按 25%--30% 设限。

按任务类型再收一次：检索型任务可以放宽，推理型任务尽量压到 32K 以内（有效窗口可能只有标称的 10--20%）。

5.2 压缩要早触发，且必须校验

WORKING_CAP      = 280_000          # 1M 模型的生产工作上限
COMPACT_TRIGGER  = 0.6 * WORKING_CAP  # 到 60% 就开始压，不要等到 95%

# 反例：Claude Code 的自动压缩在约 95% 才触发。
# 到那时，你已经把一批退化后的答案发给用户了。

def compact(state, turns):
    summary = summarize(state.running_summary, turns[:-RECENT_N])
    # 关键一步：校验压缩是有损的，所以要验证关键事实仍可恢复
    probe = regenerate_probe(summary)   # 让压缩后的状态去重建：
    assert covers(probe, CRITICAL_FACTS)  #   事实 / 未完成的承诺 / 约束 / 理由 / 未解决的风险
    return CompactionState(
        system_header = state.system_header,   # 钉住的任务不变量，~500--1500 token
        running_summary = summary,
        recent_turns = turns[-RECENT_N:],
        provenance = keep_source_ids(summary), # 保留溯源：留下的事实仍要指得回出处
    )

三条来自实践的规则：

1. 先保召回，再提精度。压过头丢掉的细节，往往在几小时后才是关键。
2. 用阈值触发，不要等溢出再截断。
3. 把不变量钉在 system header 里，不要指望它能在反复摘要中活下来。

5.3 检索：保留结构标记，别改写成流畅摘要

基于 1.3 的反直觉发现：用 ## Source N 显式标记拼接的 chunk，通常胜过把它们改写成一段通顺的总结。

5.4 尽早用即时检索（just-in-time）

	预检索（经典 RAG）	即时检索（JIT）
加载时机	推理前一次性	运行时按需
上下文里装什么	整个嵌入块集合	轻量引用：路径、查询、链接
元数据	分块时被拍平	保留：文件名、时间戳、目录结构
主要风险	塞太多 token，信号被稀释	运行时变慢，工具设计要更讲究

实践中多数系统是混合：稳定知识用预检索，大而动态的数据用 JIT。

5.5 决策树

你的 Agent 会跑多久 / 跨几次会话？
│
├─ 单轮或短会话（< 20 轮）
│   └─ 全都放上下文，最多加一次压缩。别上生命周期框架。
│
├─ 长任务但单会话（20--200 轮，如长代码任务）
│   ├─ 先做：工作上限 + 阈值触发压缩 + 结构化笔记（NOTES.md 之类）
│   └─ 再考虑：把重上下文的活派给子代理，只回收 1--2K token 的摘要
│
├─ 跨会话、需要记住用户/项目
│   ├─ 分层记忆：活动 / 工作 / 归档
│   ├─ 摄入层必须先做对（垃圾率 99.6% 那个教训）
│   ├─ 召回必须过相关性闸门（全时注入 < 选择性干预）
│   └─ 写入侧考虑投毒与陈旧事实
│
└─ 要给老板/客户交一份"记忆系统选型报告"
    └─ 四个轴一起测：质量 + p95 延迟 + token 成本 + 治理
       并要求对方给出：harness、裁判模型、产品版本、用的是哪个 LoCoMo

---

六、我的判断

第一，这不是"替代"，是"分层"。 长上下文没有失效，它只是从"记忆层"降级成了"工作层"。

┌─────────────────────────────────────────┐
│ 归档记忆   外部文件 / 知识图谱 / 向量库     │  TB 级，按需检索
├─────────────────────────────────────────┤
│ 工作记忆   压缩后的运行摘要 + 结构化状态    │  50--100K，跨轮保留
├─────────────────────────────────────────┤
│ 上下文窗口 当前步骤的高信号 token           │  有效值 ≈ 标称的 1/3
└─────────────────────────────────────────┘
          ↑ 每一层之间的搬运，才是工程量所在

模型厂商会把窗口继续做大，但那只会让"工作层"更宽，不会替你解决"归档层"。窗口是别人的产品，记忆是你的架构。

第二，2026 年真正的分水岭是可复现性，不是分数。 当同一个系统能在同一基准上被评出 38% 和 92% 两个数字时，这个基准就暂时失去了作为采购依据的资格。眼下更靠谱的做法是：在你自己的任务集上，用你自己的 harness 和裁判，测你关心的那个记忆操作（是矛盾消解？还是时序排序？还是跨会话偏好？）。

第三，下一个值得盯的信号：厂商会不会公开 harness。 目前 BEAM、LoCoMo、LongMemEval 的分数满天飞，但绝大多数不披露评测框架。哪家开始把 harness 和裁判模型一起开源，哪家才是在真的推动这个领域。在那之前，把所有记忆系统的跑分都当作"待验证的厂商声明"来读。

---

参考

• RULER（Hsieh et al., NVIDIA）：长上下文有效窗口基准
• Context Rot（Hong, Troynikov, Huber, Chroma, 2025.7）：18 个前沿模型的长度退化研究
• BEAM: Beyond a Million Tokens （Tavakoli et al., arXiv:2510.27246）：10M token 记忆基准与 LIGHT 记忆框架；GitHub mohammadtavakoli78/BEAM
• LoCoMo （Maharana et al., ACL 2024）与 LongMemEval（Wu et al., ICLR 2025）：会话记忆基准，注意两者均有已知的方法学缺陷
• ACE: Agentic Context Engineering（ICLR 2026）：上下文坍缩与条目化增量更新
• ACON（Agent Context Optimization）：失败驱动的压缩指南更新，峰值 token 降低 26--54%
• MemGPT / Letta：虚拟内存式分层上下文管理
• Anthropic《Effective context engineering for AI agents》与多智能体研究系统相关公开材料
• Factory 在 36,611 条生产消息上的上下文压缩评测

免责声明：本文引用的实验数字均来自上述公开来源，其中厂商自报成绩已在正文中标注。BEAM 的会议出处存在未经确认的说法，已按预印本处理。不同 harness 下的分数不可直接比较，选型请务必在自己的任务集上复测。