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 月）