递归语言模型：教AI管理自己的上下文
上下文窗口已经大幅扩展：100K、200K，甚至100万token。[^1]然而，基本限制依然存在。线性内存成本、极端长度下的注意力退化，以及一旦消费就无法重新访问或重组信息，这些都限制了长上下文模型能够实现的目标。[^2]递归语言模型（RLM）采取了完全不同的方法。RLM不是把所有东西都塞进上下文，而是教会模型使用Python脚本和子LLM调用来主动管理自己的上下文。[^3]
摘要
MIT的RLM论文介绍了一种架构，其中主语言模型将工作委托给持久的Python REPL和可生成的子LLM实例。[^4]模型不是直接加载大量输入，而是以编程方式检查和转换数据。[^5]测试表明，RLM可以处理超出模型上下文窗口100倍的输入，同时显著优于基础模型和常见的长上下文脚手架。[^6]在CodeQA上，GPT-5的基线准确率为24%，而RLM达到62%。[^7]Prime Intellect已经实现了RLM训练基础设施，并预测这种方法将定义AI代理的下一个重大突破。[^8]
长上下文问题
Transformer注意力随序列长度呈二次方扩展。[^9]虽然高效注意力变体降低了这个成本，但基本挑战仍然存在：
上下文退化
研究表明，即使模型技术上支持该长度，模型性能也会随着上下文增长而下降。[^10]著名的"大海捞针"测试表明，长上下文中间的信息经常被忽略或遗忘。[^11]
静态上下文
传统的上下文窗口作为一次性写入缓冲区运行。一旦token进入上下文，模型就无法重新组织、总结或选择性地检索它们。[^12]不相关的信息与关键细节并存。
内存成本
上下文中的每个额外token都需要在推理期间为键值缓存分配相应的内存。[^13]百万token的上下文即使对于单个查询也需要大量GPU内存。
RLM解决方案
RLM将范式从"模型接收上下文"翻转为"模型管理上下文"。[^14]
核心架构
RLM为主模型提供三个关键能力：[^15]
| 能力 | 实现 | 用途 |
|---|---|---|
| Python REPL | 持久环境 | 存储、转换、检索数据 |
| 子LLM | 通过llm_batch()生成的实例 |
委托分析任务 |
| Answer变量 | answer["content"] + answer["ready"] |
迭代响应优化 |
主模型从不直接处理大量输入。相反，它编写Python代码来管理信息流。
控制平面设计
Python REPL充当Prime Intellect所说的"长上下文的控制平面"。[^16]该环境提供：
持久状态：变量在模型轮次之间保持，支持复杂的多步骤工作流程。[^17]
并行处理：llm_batch()函数同时生成多个子LLM调用，大大加速可并行化的任务。[^18]
工具隔离：只有子LLM获得工具访问权限（网页搜索、文件读取等），防止主模型上下文中的token膨胀。[^19]
预安装包：数学密集型任务自动获得numpy、scipy、sympy。[^20]
Answer变量模式
最终响应通过迭代产生，而不是单次生成：[^21]
# 模型写入answer变量
answer["content"] = "部分解决方案..."
answer["ready"] = False # 继续处理
# 后续迭代进行优化
answer["content"] = "完整解决方案..."
answer["ready"] = True # 发出完成信号
这种模式使模型能够通过多次REPL交互来修改和改进答案。[^22]
上下文折叠的工作原理
研究人员将RLM的方法描述为"学习的上下文折叠"而非总结：[^23]
不是总结
传统方法通过总结来压缩上下文，不可避免地丢失信息。[^24]RLM方法通过以下方式保留所有信息：
- 将原始数据存储在Python变量中
- 通过子LLM调用选择性查询
- 在需要时以编程方式转换
- 从不总结原始内容
委托给子LLM
当主模型需要分析大型文档部分时，它只用该部分生成一个子LLM：[^25]
# 主模型代码
results = llm_batch([
{"prompt": f"分析第1节: {section_1}"},
{"prompt": f"分析第2节: {section_2}"},
{"prompt": f"分析第3节: {section_3}"}
])
# 处理结果而无需加载完整文档
主模型的上下文保持精简，而子LLM处理token密集型操作。[^26]
基准测试性能
四个不同环境的测试揭示了显著的能力：[^27]
DeepDive（网络研究）
子LLM处理网页抓取和内容提取。主模型协调搜索策略并综合发现。[^28]
| 方法 | 奖励 |
|---|---|
| 标准LLM | ~45% |
| RLM（无提示） | ~55% |
| RLM（有策略提示） | ~70% |
Oolong（长上下文聚合）
真实世界的复杂文档（D&D会话记录）在约150万字符下测试了上下文处理：[^29]
| 方法 | 准确率 |
|---|---|
| 标准LLM | ~35% |
| RLM | ~75% |
值得注意的是，RLM在合成数据上表现不佳，这表明该方法在真实复杂性而非人工基准测试上表现出色。
CodeQA（文档问答）
也许最引人注目的结果：[^30]
| 模型 | 方法 | 准确率 |
|---|---|---|
| GPT-5 | 基线 | 24.0% |
| GPT-5 | 总结代理 | 41.3% |
| GPT-5 | RLM | 62.0% |
RLM的性能是基线的两倍多，同时大幅超越了总结方法。
Verbatim-Copy
通过迭代优化保持JSON结构：[^31]
| 方法 | 准确率 |
|---|---|
| 标准LLM | ~65% |
| RLM | ~77% |
Math-Python（注意事项）
RLM目前在数学任务上的表现比标准方法低15-25%：[^32]
| 方法 | 准确率 |
|---|---|
| 标准LLM | ~70% |
| RLM | ~50% |
研究人员将此归因于模型尚未经过训练以有效使用RLM脚手架进行数学推理。
Token效率
除了准确性之外，RLM大幅提高了token效率：[^33]
主模型Token：在同等或更好的结果下，主模型处理的token减少2-3倍。[^34]
总Token：由于子LLM调用可能会增加，但无论输入大小如何，主模型上下文都保持有界。[^35]
延迟权衡：与单次推理相比，顺序REPL操作增加40-80%的延迟。[^36]
Prime Intellect的2026预测
Prime Intellect已经构建了RLM训练基础设施，并做出大胆预测：[^37]
2026年的范式
他们基于三个前提将RLM定位为下一个重大突破：[^38]
1. 训练优势：与固定脚手架不同，RLM可以通过强化学习进行端到端训练以改进上下文管理。[^39]
2. 与注意力互补："高效注意力和上下文折叠都是真正长期代理所需的。更好的注意力延迟上下文退化。上下文折叠实现主动管理。"[^40]
3. 长期代理：RLM支持运行数周或数月的代理，跨扩展任务时间线管理上下文。[^41]
RLMEnv基础设施
Prime Intellect发布了RLM兼容的环境和训练基础设施：[^42]
- 在其Environments Hub上提供多个环境
- 与prime-rl训练框架集成
- 开放社区实验
未开发的潜力
当前模型显示"由于脚手架使用不当，存在显著的未开发性能。"[^43]未专门针对RLM训练的模型未充分利用其能力。这表明RLM原生训练可带来重大收益。
开源发布
MIT团队发布了完整资源：[^44]
- 论文：arXiv:2512.24601
- 代码：https://github.com/alexzhang13/rlm
- 环境：各种长上下文基准测试
对AI开发的影响
代理架构
RLM为构建强大代理提出了新模式：[^45]
- 协调器模型具有有界上下文
- 工作子LLM处理特定任务
- Python环境用于状态管理
- 迭代优化而非单次执行
训练要求
要充分利用RLM，模型需要包括以下内容的训练：[^46]
- 用于REPL交互的代码生成
- 子LLM委托策略
- 多轮答案优化
- 长期奖励信号
成本结构
RLM将成本从上下文长度转移到编排复杂性：[^47]
| 维度 | 传统 | RLM |
|---|---|---|
| 主模型上下文 | 随输入扩展 | 有界 |
| 子LLM调用 | 无 | 随复杂性扩展 |
| 延迟 | 单次 | 多轮 |
| 内存 | 随上下文扩展 | 有界 |
关键要点
递归语言模型在上下文处理方面引入了范式转变：
- 主动上下文管理：模型控制自己的上下文而不是被动接收
- 100倍扩展：处理远超原生上下文窗口的输入
- 信息保留：无基于总结的信息丢失
- Token效率：主模型token消耗减少2-3倍
- 训练潜力：预计RLM原生训练将带来重大收益
- 长期代理：适合扩展任务时间线的架构
Prime Intellect相信RLM代表"2026年的范式"，这反映了越来越多的人认识到上下文管理可能比上下文长度更重要。
