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 找关键词、按章节切开。碰到值得细看的切片，就对该切片递归调用自身或子模型，结果存成变量。最后汇总，给出答案。递归出口是基础模型一次普通的调用。

![图片](https://developer.qcloudimg.com/http-save/yehe-2881505/59694ccf4c201c1c342e46855f6dffee.jpg)上下文本身变成了计算的对象。决定看哪里（推理）和对上下文执行代码（工具使用），落进同一个抽象。

论文的作者认为 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。
![图片](https://developer.qcloudimg.com/http-save/yehe-2881505/4b9da5699b45250e4691be16ad41fca2.jpg)后续工作把同一套路接到记忆上。《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`）。

![图片](https://developer.qcloudimg.com/http-save/yehe-2881505/49f41d311257080a232567ca0704c30d.jpg)第一次跑，最适合带实时树。
```shell
pi-rlm "Analyze the architecture of this repo" \
&nbsp; --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"&nbsp;--max-nodes 8 --max-branching 2
```
规划器提示词里带着 `remainingNodeBudget`，并被要求绝不超过 `maxBranching`。预算耗尽时，剩余节点会被取消，合成器明确汇报缺口。这些设置参数就是成本与质量权衡的艺术。

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

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

`pi-rlm` 主要关注点是任务轴上的递归分解与合成、深度与节点预算、分支控制、环检测，以及按节点可见的成本与延迟。它并没有复刻论文的另一半，那就是对上下文本身做 REPL，切片、检索、对切片再发子查询，换句话说，超长上下文和“当记忆用”这两块的论文数字，靠任务树工具复现不了。
![图片](https://developer.qcloudimg.com/http-save/yehe-2881505/a7e97425380f004a18f9d159cbc9cf7b.jpg)`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 月）

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

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

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

人工智能

编程语言

算法

本文解析递归语言模型（RLM）技术，通过将超长上下文作为可计算对象，在推理时用代码递归切分处理，解决上下文腐化问题。实测支持千万级token输入，性能提升显著，并介绍Pi扩展pi-rlm的工程实现、护栏参数及与论文机制的差异，为长上下文Agent提供新思路。

代码解释

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

RLM 火了，Pi 作者也在跟的递归语言模型-腾讯云开发者社区-腾讯云

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐