递归语言模型（RLM）：当大模型学会"自己管理记忆"

2025 年 10 月，MIT 博士生 Alex Zhang 发了一篇博客，标题朴素得像一篇课程笔记："Recursive Language Models"。

没有发布会，没有 demo 视频，没有任何营销噱头。

四个月后，AI 研究机构 Prime Intellect 在官网用加粗字体写下一句话："Recursive Language Models: the paradigm of 2026."

2026 年的范式。这是一个很重的词。

过去两年，整个行业都在做同一件事——把上下文窗口做得更大。4K、32K、128K、1M……各家模型的上下文长度像军备竞赛一样疯狂膨胀。

但 RLM 提出了一个完全不同的问题：如果不是给模型更多的记忆，而是教模型管理自己的记忆呢？

这个问题的答案，可能会改变你对大模型能力边界的理解。

---

为什么"更长的上下文窗口"解决不了问题？

你一定见过各家模型发布时的宣传语：

"支持 100 万 token 上下文！"

"200 万 token 超长窗口！"

听起来很厉害。但我问你一个问题：你真的用过 100 万 token 的上下文吗？

如果你试过，你大概率遇到过一个让人抓狂的现象——上下文腐烂（Context Rot）。

简单说就是：你把一本书丢进去让模型分析，模型对开头几页和最后几页记得清清楚楚，中间几百页？基本是一团模糊。

这不是某一家模型的 bug，而是 Transformer 架构的结构性问题。注意力机制在处理超长序列时，注意力权重会被"稀释"——要关注的东西太多，结果什么都关注不好。

打个比方：上下文窗口就像你的书桌。

4K token 是一张小课桌，放几张 A4 纸刚好。128K 是一张大办公桌，能摊开好几份文件。1M token？那是一张乒乓球台大小的桌子。

但问题来了——桌子再大，你同一时间也只有两只手。你不可能同时翻阅桌上所有文件。桌子越大，找东西反而越慢，遗漏反而越多。

更实际的问题是成本。处理 100 万 token 的输入，光 API 费用就够让你的 CFO 心跳加速。更不用说延迟——等模型读完这些内容再回复，你的咖啡都凉了。

所以，整个行业走到了一个岔路口：是继续把桌子做大，还是换一种完全不同的思路？

RLM 选择了后者——不是给你更大的桌子，而是给你一个会整理桌面的助手。

---

RLM 到底是怎么工作的？

RLM 的核心思想用一句话概括：让模型从"被动接收上下文"变成"主动管理上下文"。

传统模式下，你把所有内容塞进 prompt，模型被迫一次性消化所有信息。这就像把一本 500 页的书一口气怼到你面前说"现在回答我的问题"。

RLM 的做法完全不同。它建立了一个三层架构：

看这张图，关键在三个角色的分工：

主模型（Root LLM）——它是"项目经理"。它的上下文里只有系统提示和任务指令，绝对不会被原始数据淹没。它的工作是：想清楚该怎么拆解任务，然后写代码去执行。

Python REPL——它是"工作台"。所有原始数据都被加载到这里，作为一个 Python 变量存在。主模型通过写代码来切片、筛选、处理这些数据。

子模型（Sub-LLMs）——它们是"实习生"。主模型通过一个叫 llm_batch() 的函数，可以并行派出多个子模型，让它们各自分析一小块数据，然后把结果汇总。

这里有一个极其精妙的设计：原始数据对主模型完全不可见。

听起来反直觉对不对？你要分析的数据，模型居然"看不到"？

但这恰恰是 RLM 的天才之处。主模型不需要"看到"所有数据，它只需要知道数据在哪、怎么操作它。就像一个优秀的 CEO 不需要亲自读完公司所有的财报细节——他需要知道该问哪些问题，该派谁去调查。

来看一段简化的工作流程：

# 主模型生成的代码（自动执行）

# 1. 切片：把 150 万字符的文档按章节拆分
chapters = data.split("## ")

# 2. 派遣子模型并行分析每个章节
results = llm_batch([
    {"prompt": f"总结这章的核心论点：{ch[:8000]}"}
    for ch in chapters
])

# 3. 汇总结果，更新答案
answer["content"] = synthesize(results)
answer["ready"] = True

关键在第 5 行：llm_batch()。这个函数会并行启动多个子模型实例，每个实例只处理一小块数据。子模型可以使用搜索工具、文件读取等能力，但这些工具对主模型不开放——这防止了主模型的上下文被工具输出撑爆。

不是给模型更多信息，而是给模型管理信息的能力。这是 RLM 最根本的范式转移。

---

和 RAG、长上下文模型比，RLM 赢在哪？

你可能会想：这跟 RAG 有什么区别？不也是"不把所有东西塞进去，而是按需检索"吗？

好问题。但区别比你想的要大得多。

RAG 就像一个图书馆的检索系统。你问一个问题，系统根据关键词帮你找到最相关的几段文字，然后把这些文字塞进模型的上下文。

问题在哪？RAG 是"被动检索"——它只能根据你的问题去找答案，而且每次只能找固定几段。如果答案分散在 20 个不同的段落里，或者需要先理解 A 才能找到 B，RAG 就力不从心了。

RLM 不一样。它是"主动探索"。

打个比方：

• RAG 像你让图书管理员帮你找几本书。管理员根据你说的关键词，拿回来几本。如果关键词不够精确，或者你其实需要的是跨越多本书的信息，管理员帮不了你。
• RLM 像你派了一个研究助理去图书馆。他会自己翻目录、读摘要、决定哪些章节值得深读、把多本书的信息交叉比对，最后给你一份研究报告。

差距一目了然。

再看另一个维度：和"暴力扩展上下文窗口"相比呢？

"更好的注意力机制延缓了上下文腐烂，但上下文折叠让模型能主动管理上下文，突破真正的极限。两者都需要，但后者才是根本。"
—— Prime Intellect 研究团队

有意思的是，Prime Intellect 的研究者并不认为 RLM 和长上下文技术是对立的。他们的观点是：长上下文技术（包括稀疏注意力等）让模型在有限窗口内表现更好，而 RLM 让模型能处理远超任何窗口大小的输入。

这就好比——更好的发动机让车跑得更快，但如果你要从北京到纽约，你需要的不是更快的车，而是飞机。

RAG 是检索，RLM 是研究。检索给你答案片段，研究给你完整认知。

---

数据怎么说？

理论说得再漂亮，最终还是要看数据。

Prime Intellect 团队在四个不同场景下测试了 RLM，结果很有意思——不是全面碾压，而是"有的场景大幅领先，有的场景反而不如传统方案"。

这种诚实的呈现方式，反而让我更信服。

测试场景	传统 LLM	RLM	提升
CodeQA（代码理解）	24%	62%	+158%
Oolong（长文档聚合）	35%	75%	+114%
DeepDive（深度研究）	45%	70%	+56%
Math-Python（数学推理）	—	更低	-15~25%

先看亮点。CodeQA 场景下，GPT-5 的基线准确率只有 24%——因为代码仓库太大，远超上下文窗口，模型根本没法完整理解。而 RLM 版本达到了 62%，几乎是 2.6 倍的提升。

怎么做到的？RLM 模型自己写代码去遍历文件结构、读取关键文件、把分析工作分派给子模型。它不需要"看到"整个代码仓库，它用代码去"探索"代码仓库。

Oolong 场景更直观——这是一个长文档聚合任务，输入大约 150 万字符。传统 LLM 直接拒绝处理（超出上下文窗口），或者勉强处理后丢失大量信息。RLM 的准确率从 35% 跳到了 75%。

但 Math-Python 场景拉了胯，RLM 比标准 LLM 低了 15-25%。

为什么？

因为数学推理本身不需要管理大量外部信息——问题和所有需要的信息都在题目里。给这类任务加上"上下文管理"的架构，反而增加了不必要的开销。就像让一个人做口算题，你非要给他配一个秘书和一间办公室，反而把简单的事搞复杂了。

这里有一个关于效率的数据也值得注意：RLM 模式下，主模型消耗的 token 减少了 2-3 倍，但由于子模型的调用，总 token 消耗会增加。延迟增加了 40-80%。

这是一个经典的"时间换质量"的权衡。对于实时对话场景，RLM 显然不适合。但对于深度分析、长文档理解、代码仓库探索这类"慢思考"任务，多花 40% 的时间换来 100%+ 的准确率提升，这笔账太划算了。

RLM 不是银弹。它是一把狙击枪——在对的场景下精准致命，用错地方反而碍手碍脚。

---

这对开发者意味着什么？

如果你是做 AI 应用的开发者，RLM 的出现意味着你需要重新审视一些根深蒂固的假设。

假设一："上下文越长越好，我需要选上下文窗口最大的模型。"

不一定。对于复杂的长输入任务，与其选一个 200 万 token 窗口的模型然后把所有东西都塞进去，不如设计一个 RLM 式的架构，用普通窗口的模型反而能得到更好的结果。

假设二："RAG 是处理大量文档的最佳方案。"

对于简单的"查找特定信息"任务，RAG 仍然是最经济高效的选择。但如果你的任务需要跨文档推理、信息综合、多步分析——RLM 的思路值得尝试。

假设三："AI 应用的瓶颈是模型的能力。"

RLM 的启示是：很多时候瓶颈不是模型的能力，而是我们使用模型的方式。同样的模型，换一种架构，性能可以翻倍。

有一个有趣的花絮值得分享。RLM 的论文最早诞生在 MIT 的一个课程项目中——Alex Zhang 在研究如何让 LLM 处理超长输入时，灵感来自操作系统的内存管理。操作系统不会把所有数据都加载到内存里，而是用虚拟内存按需加载。RLM 本质上是给大模型实现了一套"虚拟上下文"系统。

这个类比精准得让人拍大腿——整个计算机科学的历史，就是在反复解决"有限资源处理无限需求"的问题。从磁盘到内存到 CPU 缓存，每一层都有自己的"上下文管理"策略。大模型走到今天，终于也到了需要这套管理机制的阶段。

真正厉害的不是让模型"记住更多"，而是让模型"学会忘记不重要的、聚焦重要的"。这才是智能。

---

写在最后：两个预测

聊到这里，让我把 RLM 的核心洞察串起来：

它不是又一个"长上下文优化技术"。它是一次交互范式的转变——从"把信息塞给模型"到"让模型自己获取信息"。从被动到主动，从接收者到管理者。

这个转变的意义，不亚于操作系统从"一次加载全部程序"到"虚拟内存按需加载"。

所以，我做两个预测，给自己设个 deadline：

预测一：2026 年底之前，至少两家主流模型提供商（OpenAI、Anthropic、Google 中的至少两家）会在 API 中原生支持 RLM 式的"递归调用"能力。不一定叫 RLM 这个名字，但核心机制——模型自主管理上下文、派遣子模型、通过代码操作数据——会成为标准功能。

预测二：2027 年 Q1 之前，"上下文管理"会像"Prompt Engineering"一样，成为 AI 开发者的一项必备技能。现在我们讨论"怎么写好 prompt"，到时候会讨论"怎么设计上下文管理策略"。

上下文窗口的军备竞赛不会停。但赢家不是窗口最大的那个，而是最会管理窗口的那个。

半年后回来看看，我说得对不对。