💡 一句话总结：Memex(RL) 不是又一个 RAG 系统，是给 Agent 装了『笔记本 + 索引卡 + 档案柜』三件套，并用 RL 教会它什么时候翻笔记、什么时候找档案、什么时候继续干活。
长程 Agent 的根本困境
你给 Claude Opus 4.7 一个任务：『帮我把过去 30 个交易日 SP500 成分股的 10-K 摘要做成 Excel』。它开始干活：
- step 1-10：解析任务，列出股票清单
- step 11-50：访问 SEC EDGAR 抓第一只股票的 10-K
- step 51-100：开始抓第二只股票，但前面的所有 PDF 内容还在上下文里
- step 200：上下文逼近 200K，开始丢东西，决策质量崩
200K context 听起来够大，但长程任务的 token 累积是恐怖的——10-K 一份能上 50K token，30 只股票就 1.5M token，单一上下文窗口装不下。
LLM 社区的传统答案：
- RAG 外置：把读到的内容存到向量库，需要时检索。问题：检索粒度难调，相似 doc 查回来一堆。
- 滑动窗口：保留最近 N 步，丢掉早期。问题：早期的『任务描述 / 关键约束』被丢了，agent 跑偏。
- 递归 summary：定期把历史压缩成摘要。问题：信息损失不可逆，需要原文时找不回来。
Memex(RL) 论文（arXiv 2603.04257，2026-03 发表，5 月已被多个团队复现）针对这个困境提出了一个第四条路。
Memex 的三层记忆架构
核心数据结构有三层：
┌─────────────────────────────────────┐
│ 工作上下文 (LLM context window) │
│ ├── 任务描述 + 当前 subgoal │
│ ├── 最近 N 步完整观察 │
│ └── 历史步『摘要 + 索引指针』 │
└─────────────────────────────────────┘
│ retrieve(idx)
▼
┌─────────────────────────────────────┐
│ 经验数据库 (外部，文档完整保存) │
│ idx_001: 完整的 10-K 文档 50KB │
│ idx_002: 完整的 web page DOM 20KB │
│ idx_003: 完整的 tool call output │
└─────────────────────────────────────┘工作上下文里的『摘要 + 索引指针』是一条结构化的 JSON：
{
"step_id": 47,
"observation_type": "10-K filing",
"summary": "Apple FY2025 revenue $400B, R&D up 12%, ...",
"key_facts": ["revenue=$400B", "R&D=$32B"],
"index_ref": "idx_047",
"confidence": 0.92
}每条摘要平均 200 tokens（对应原文可能 50K tokens），压缩比 250×。Agent 在做决策时看到的就是这种结构化卡片堆——既知道历史发生了什么，又能在需要时『翻出原文』。
关键动作空间
Memex 把 Agent 的动作空间扩展为 4 类：
| 动作 | 何时使用 | 代价 |
|---|---|---|
| take_action(a) | 正常推进任务 | 无 |
| archive_to_index(obs) | 观察很重要、之后可能要查 | 一次小开销，写 200 tokens 摘要 |
| retrieve(idx) | 需要回取证据 | 把外部 record 拉回 context |
| proceed_without_recall | 历史不重要、直接跳过 | 无 |
每一步 Agent 都要在这 4 类动作里选一个。这是个序列决策问题，没有 ground truth——所以用 RL 训。
RL 训练设计
奖励函数：
R(s, a) = TaskSuccess × 1.0
- ContextTokenUsage / MaxContext × 0.3
- WrongRetrievalCount × 0.1
- ArchiveRedundancy × 0.05四项含义：
- 任务成功主奖励，做完任务 +1
- 上下文用量惩罚：context 越满惩罚越大，逼 Agent 学会压缩
- 错误回取惩罚：retrieve 了一个回来发现没用到，扣分
- 冗余存档惩罚：把无关紧要的观察也存进去，扣小分
训练设置：
- Base：Llama-3-8B-Instruct
- 算法：PPO with KL constraint to base policy
- 任务采样：12 个 long-horizon benchmark 任务池，每个 episode 1000-2000 steps
- 算力：24× H100，3 周
训练曲线 ablation 很有意思：
- step 0-50k：纯模仿专家 trace，成功率从 24% 到 38%
- step 50k-200k：RL 接管，Agent 开始探索 archive/retrieve 策略，成功率波动但整体上升到 65%
- step 200k-500k：收敛阶段，Agent 学到稳定的 archive/retrieve 策略，成功率 85.6%
最有意思的发现：训练后期 Agent 自动学会了预防性存档——遇到形如『公司财务摘要』这种语义结构清晰的内容会主动 archive，因为它『预感』后面会用到；遇到『按钮点击的反馈日志』这种一次性内容直接 proceed_without_recall。
实测对比
论文 Table 3 节选：
| Benchmark | Base Llama-3-8B | + RAG | + Sliding window | + Memex(RL) |
|---|---|---|---|---|
| WebArena | 18% | 31% | 22% | 65.1% |
| Mind2Web | 30% | 42% | 35% | 76% |
| LongDoc-QA | 41% | 58% | 39% | 92% |
| AGENTBOARD-Hard | 22% | 28% | 24% | 84% |
可以看到 Memex 在所有任务上都比 RAG、sliding window 显著胜出。最强的是 LongDoc-QA（长文档问答）类任务，从 41% 拉到 92%——这类任务里『先看完原文、记住关键点、回答时回取证据』的模式刚好契合 Memex 的设计。
工程落地路径
论文同步发了 GitHub：github.com/memex-rl/memex （注意识别真假仓库，以论文链接为准）
集成最简单：
from langchain_core.runnables import RunnableLambda
from memex import MemexAgent
agent = MemexAgent.from_pretrained("memex-rl/llama3-8b-memex")
result = agent.run(
task="抓取 SP500 前 10 大成分股的最新 10-K 关键财务摘要",
max_steps=2000,
context_budget=180_000, # 留 20K 给系统提示
)对接 LlamaIndex 类似：
from llama_index.agent.memex import MemexAgentRunner
runner = MemexAgentRunner(
model="memex-rl/llama3-8b-memex",
tools=[SECTool(), ExcelTool()],
memex_config={
"archive_threshold": 0.7,
"retrieval_top_k": 3,
}
)部署成本：单卡 A100 跑 8B 模型可以服务 ~10 个并发 Agent，每秒生成 60 tokens。如果是高并发场景需要 vLLM + tensor parallelism 上 2-4 卡。
我们的判断
Memex(RL) 是 2026 年长程 Agent 方向的关键论文之一。它把『context window 怎么用』从一个工程问题升级为一个学习问题——这是 RL 在 LLM Agent 上一次很干净的应用，不是 RLHF 那种泛对齐，而是针对具体认知机制的 RL。
它不是终点。论文最后承认了三个开放问题：
- 跨 task 泛化：Memex 学到的索引策略在新任务上需要 fine-tune 一段时间才稳定
- 索引爆炸：超长任务（5k+ steps）索引数量上万，索引检索本身变成瓶颈
- 错误回取的成本：retrieve 一次错误的 index 浪费 5K tokens，对 cost-sensitive 场景是大问题
这些问题大概率是接下来 12 个月的论文方向。如果你在做长程 Agent，Memex(RL) 是这周必读的论文之一，可以和 EverMemOS、MemoryArena 一起看，能搭出一个完整的 Agent 记忆栈。