解读：2026年是递归语言模型(RLM)的元年

来源: Recursive Language Models (arXiv:2512.24601)

核心洞察

这篇论文让我改变了对"长上下文"的理解。

以前的思路是：把上下文窗口做大一点、再大一点。现在这篇论文说：别让模型"记住"所有东西，让它学会"编程"来处理上下文。

从"阅读"到"编程"，范式变了。

如果说 2025 年我们从语言模型走向了推理模型（System 2），那 2026 年可能就是递归语言模型的元年。

什么是 RLM？

RLM 不是一种新架构，而是一种新的推理策略。

核心思路是：不再把输入 Prompt 当成一连串 Token 流，而是把它当成编程环境（REPL）里的一个外部对象——比如一个字符串变量 P。

模型可以检查这个对象、切片、对自身发起递归调用来处理不同片段，最后迭代合成结果。

为什么需要这个？

因为标准的"长上下文"（1M+ Tokens）有两个硬伤：

1. 上下文腐烂：窗口越长，推理质量越差
2. 成本爆炸：线性甚至平方级的计算开销

RLM 用"核外计算"的思路解决这个问题——处理原本超出模型"内存"（上下文窗口）大小的数据。

效果如何？

论文实验显示，在 10M+ Token 的任务上，RLM 表现优于前沿模型（GPT-5，Qwen3），实现了两位数的百分比增长。

跟简单的 RAG 或者 Summarization 比，RLM 能防止在超长任务上的性能退化。

代价是什么？需要一个 REPL 环境，以及进行递归子调用的能力。

一个类比

想象一下编辑一个 100GB 的视频文件。

你不会把它全部加载到内存里，对吧？你会把它留在硬盘上，只加载当前正在编辑的片段。

RLM 做的事情类似：给 AI 一套"视频编辑软件"（REPL 环境），而不是强迫它背诵每一个像素。

RLM 就是 AI 界的"核外算法"。

这对 Vibe Coding 意味着什么？

几个可以立刻用起来的思路：

1. "Prompt 即对象" 重构

在 Python 脚本里，停止把巨大的字符串直接丢给 messages=[...]。

把大段文本存成文件或变量，给 LLM 提供一个工具 read_chunk(start, end) 或者 search_text(query)，让它来决定读什么。

2. 递归摘要模式

长文档总结不要只求一个大而全的摘要。

实现一个 recursive_decode(text) 函数：切分文本，总结各个块，再对这些摘要进行总结。这就是人工版的 RLM。

3. "REPL" 思维模式

把你的 IDE 理解为环境。用 AI 编程的时候，不要只是"聊天"，而是明确告诉它："你在一个 REPL 环境中。current_file 是你的上下文变量。请以代码形式提出修改建议。"

从"向先知提问"转变为"与一位能用终端的程序员结对编程"。

行动指南

"懒惰上下文陷阱"：把所有东西塞进超大窗口，感觉很省事，但推理效果会很差。这是虚假的舒适感。