RLM 火了，Pi 作者也在跟的递归语言模型

Pi 的作者 Mario Zechner（GitHub `badlogic`）最近在递归语言模型 RLM (Recursive Language Models ) 很显眼。Prime Intellect 开源的 `prime-agent` 自称 self-improving RLM agent，基于 Pi 开发。与此同时，Pi 扩展生态里出现了 `pi-rlm`，把递归拆任务做成能看见的树。两边都绕着同一个缩写转。

我通读了 Alex Zhang 的论文《Recursive Language Model》，也花了点时间在 Pi 中试了下 `pi-rlm`。理解下来，前者讲上下文变成 REPL 中的计算对象，后者则是描述任务级递归分解的过程。

RLM 这项技术是为了上下文腐化（context rot）这个问题。我们知道，随着工具输出、文件内容、对话历史、搜索结果的增长，窗口再大也会有天花板：开头的约束不遵守，推理也跟着混乱起来。

## RLM 到底改了什么

RLM 属于推理时的组织方式，并不改模型的训练配方。与当前的Agent Harness的最显著差异是，模型把超长提示词当成外部环境里的一个变量，自己写代码去检查、切分，再对切片发起子调用。换句话说，RLM 以Context为重心，而不是以待解决的问题为中心。

根模型待在类似 Jupyter 的 Python REPL 里，大致有四步：提示词和文档先以变量形式加载进环境，不直接塞进模型输入。根模型写代码看长度、用 grep 找关键词、按章节切开。碰到值得细看的切片，就对该切片递归调用自身或子模型，结果存成变量。最后汇总，给出答案。递归出口是基础模型一次普通的调用。

上下文本身变成了计算的对象。决定看哪里（推理）和对上下文执行代码（工具使用），落进同一个抽象。

论文的作者认为 Cursor、Claude Code、ROMA 式子 Agent，拆解路径多半由人的直觉预先设计。RLM 把“如何拆解”交给模型，并且主要拆在上下文维度上。推理类模型已经证明，回答时多想一会儿、多花一点算力，成绩会上去。RLM 接着问多出来的算力该怎么花，是继续堆更长的内心独白，还是拿去**写代码、切上下文、再对自己发子查询**？社区里有人觉得，后一种算力的花法可能也是一条能把模型做强的路。

## 几组数字为什么让人惊喜？

**输入可以超出模型原生上下文窗口约两个数量级**。在千万级 token（约 1000 万到 1100 万）的深度研究任务上，性能没有明显衰减。基于 GPT-5 的 RLM，在四个长上下文基准上的中位数提升大致如下。相对上下文压缩约 26%，相对带子调用的 CodeAct 约 130%。跟 Claude Code 比，大约还有 13%，成本大致相当。

更夸张的一组在 OOLONG / OOLONG-PAIRS。这是长上下文上的推理加聚合，要先啃大量局部片段，再合成全局答案。发布时 GPT-5、Claude-Sonnet-4、Gemini-2.5-Pro 在 128k 下都低于 50%。RLM-GPT-5 在 32k 拿到约 58%，同设置下原版 GPT-5 几乎接近 0；到 100 万 token 仍约 50%。BrowseComp 多文档深研上，RLM-GPT-5 约 91.3%，原版 GPT-5 因上下文限制甚至交不出答案，摘要式 Agent 约 70.5%。

花销这边也有故事。基于 GPT-5-mini 的 RLM，在 OOLONG 某个子集上正确数超过 GPT-5 两倍以上，单次查询还更便宜。首个围绕 RLM 后训练的开源小模型 RLM-Qwen3-8B（80 亿参数、原生约 3.2 万 token 窗口），平均比基座 Qwen3-8B 高约 28.3%，在三个长上下文任务上接近原版 GPT-5。

接下来的工作，沿着同样的思路把这套方法延伸到了记忆机制上。《Recursive Language Models as Memory Systems》（2026 年 2 月）给出的结果很直接：在 LongMemEval 上，基于 Gemini 3 Flash 的配置，成绩大致从 87.2% 提升到了 89.8%。这也说明了一点，**记忆本质上也可以是对上下文进行计算，而不是一上来就先搭一整套向量库和检索器**。

但是，别过度递归

热度起来以后，复现工作很快泼了一瓢冷水。《Think, But Don't Overthink》（2026 年 3 月）发现，深度为 1 的递归在 Oolong 上有帮助，更深反而可能伤准确率，同时把耗时和 token 打爆。递归深度要调，不能默认越大越好。

还有几条保留意见值得并排看。Oolong、LongMemEval 与真实 Agent 任务的相关性并不强，LongCoT 也很新。递归系统会拆成许多小调用，中位数成本好看，尾部查询可能很贵，千万 token 的端到端延迟也不轻松。

这些保留意见很重要。后面动手时，我们会看见它们被写成了代码里的护栏。

先看清任务递归长什么样

论文里对上下文做 REPL 的那一半，需要论文和官方库才能完整感受。想先摸到“拆开任务、子节点干活、再汇总”这一半，可以先把过程写成一段很短的伪代码。`pi-rlm` 做的事，大致就落在这棵调用树上。

```python

def solve(task):

if is_atomic(task): # Step 1: Atomizer

return execute(task)# Step 2: Executor

else:

subtasks = plan(task) # Step 2: Planner

results = []

for subtask in subtasks:

results.append(solve(subtask))# Recursive call

return aggregate(results) # Step 3: Aggregator

# Entry point:

answer = solve(initial_request)

```

代码很直接。任务够小就执行；不够小就规划出子任务，对每个子任务再调用一次 `solve`，最后把结果聚起来。Atomizer 决定何时停拆，Planner 决定怎么拆，Executor 干活，Aggregator 聚合。递归落在那一行 `solve(subtask)` 上。

Pi 扩展 `pi-rlm` 把这套逻辑做成了带护栏的引擎。根节点开一个规划器，严格输出 JSON，在 `solve` 和 `decompose` 之间二选一。选分解就长出子节点，每个子节点像一个 worker。子结果回来后，合成器汇总，已完成的当证据，失败的当缺口。叶节点不再往下拆，只做一次普通求解。

默认护栏比较严格。`maxDepth` 默认 2，到顶就强制直接解。`maxNodes` 默认 24，剩余预算会塞进规划器提示词。`maxBranching` 默认 3，子任务会被裁到预算内。任务血缘里出现环，就强制求解，避免无限递归。有效子任务不足两个时，自动回退到直接解（除非你强行 `mode=decompose`）。

第一次跑，最适合带实时树。

```shell

pi-rlm "Analyze the architecture of this repo"

--tools-profile read-only --live

```

屏幕上会出现深度 0 的根节点，规划器决定直接解还是拆开，子节点在 depth 1 各自开 Pi 会话，最后合成器合并输出。树本身就是递归。每个节点对应一次模型调用，根侧上下文只接收子节点的结果，不会被整个塞满。每个决策里的 `reason` 字段，会写清为什么此刻选择分解或求解。

护栏实验是教学价值最高的一组。同一句任务，分别用浅深度、更深深度、以及完全关掉递归的 `mode=solve` 跑三遍，对比达到深度、访问节点数、耗时和输出质量。

```shell

pi-rlm "Find top reliability risks in this codebase" --max-depth 1 --json

pi-rlm "Find top reliability risks in this codebase" --max-depth 3 --json

pi-rlm "Find top reliability risks in this codebase" --mode solve --json

```

`mode=solve` 接近论文里的非递归基线。`--max-depth 1` 接近论文默认深度，`--max-depth 3` 则把“更深不一定更好”的理念写到了工程当中，由人类经控制。引擎还会在分解无益时自动回退。

预算也能单独控制，如下。

```shell

pi-rlm "Write a README for this repo"--max-nodes 8 --max-branching 2

```

规划器提示词里带着 `remainingNodeBudget`，并被要求绝不超过 `maxBranching`。预算耗尽时，剩余节点会被取消，合成器明确汇报缺口。这些设置参数就是成本与质量权衡的艺术。

后端选择对应论文那句“递归子调用可以指向自身或另一个 LM”。`sdk` 在进程内复用，开销最低，接近自我递归。`cli` 每个节点起一个全新 `pi -p` 子进程，隔离清楚。如果用`tmux` 加上 `--live` 最戏剧化，窗格按 `depth-0`、`depth-1` 递归变成可见的进程树。

每次运行还会落到 `/tmp/pi-rlm-runs//`，里面有 `events.jsonl`、`tree.json`、`output.md`。事件日志记每次调用的字数、耗时和阶段（planner、solver、synthesizer），树文件则是完整解释链。自上而下读 `decision.reason`，能讲清模型在哪里选择了分解。

务实的定位

pi-rlm真正聚焦的，其实是任务轴上的那一套能力：递归拆解与合成、深度和节点预算、分支控制、环检测，以及以节点为单位可观测的成本与延迟。它并没有把论文的另一半也一并照搬过来——那部分说的是对上下文本身做 REPL，包括切片、检索、再对切片继续发起子查询。说白了，论文里关于超长上下文，以及把上下文“当记忆来用”这两块的数据表现，单靠任务树工具是复现不出来的。

`pi-rlm` 只是 RLM 风格的递归脚手架。MIT 论文里对上下文递归的那一半，才是解锁超长输入与记忆能力的机制。`pi-rlm` 展示编排，论文展示机制。另外它还只是个雏形，v0.1.3、几十个 star、二十来次提交，适合演示和教学，还远远不够当成生产方案。

风头正盛，是个不错的探索期。2025 年 10 月 Alex Zhang 博客首发，年底到 2026 年初论文与开源库落地，这一段时间又有 DSPy.RLM、Prime Intellect 的 `prime-agent`、ypi 这类递归编码 Agent。Pi 仓库里也出现过把 RLM 做成 thinking mode 或扩展的讨论。

我建议大家也在本安装运行一下，环境安装需要 Node.js 20 左右、可用的 Pi coding agent 与模型密钥，再 `pi install npm:pi-rlm` 或从仓库安装。命令和源码对应关系，在 `src/engine.ts`、`src/prompts.ts`、`src/backends.ts` 里写得很干净，用 ai 对照着读比会有更好的效果。

## 参考

[1] Zhang, Kraska & Khattab，《Recursive Language Models》，编号 arXiv 2512.24601（arxiv.org/abs/2512.24601）

[2] Alex Zhang 博客 alexzhang13.github.io/blog/2025/rlm/

[3] 开源库 rlm，github.com/alexzhang13/rlm

[4] Prime Agent，github.com/PrimeIntellect-ai/prime-agent

[5] pi-rlm（v0.1.3），github.com/manojlds/pi-rlm

[6]《Think, But Don't Overthink》（2026 年 3 月）； [7]《Recursive Language Models as Memory Systems》（2026 年 2 月）","createTime":1786458492,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"fa vNum":0,"html":"","isOriginal":0,"likeNum":0,