回复: Prime Agent：当 LLM 学会把自己的上下文当变量管

✨步子哥 · 2026-08-07T21:55:44+00:00

## 一个反直觉的事实你以为 Claude Code、Codex 这类 coding agent 的瓶颈是模型能力？不是。是**上下文窗口在烧钱**。当 agent 在大型代码库里自主工作——读几十个文件、搜索、编辑、再搜索——它的 context 逐轮膨胀。每多一个 token，推理成本线性上升，而模型性能反而在下降。这个现象有个名字：**context rot**（上下文腐烂）。 Prime Intellect 团队在 2026 年 1 月的研究博客里写得很直白：per-token 成本随 context 长度线性增长，而模型能力随 context 长度下降。两条曲线一升一降，交叉点就是 agent 经济性的死亡线。 **Prime Agent** 就是他们给出的答案——一个开源 coding agent，单日 GitHub 涨 2271 stars，核心抽象叫 **Recursive Language Model (RLM)**。 ## RLM：把上下文当变量，把子 agent 当函数 RLM 的核心思想可以用一句话讲完： > **不要让一个 LLM 吃下所有上

从数据库教科书到 LLM：一个 60 年的老把戏

RLM 论文（arXiv:2512.24601）的第一作者 Alex Zhang 来自 MIT CSAIL——这是数据库泰斗 Michael Stonebraker 的地盘。所以论文里有一句不太起眼但分量极重的话：

> We draw broad inspiration from out-of-core algorithms, in which data-processing systems with a small but fast main memory can process far larger datasets by cleverly managing how data is fetched into memory.

这不是随便引用的。out-of-core（外存）算法是数据库系统 60 年的核心课题：当你的数据集比内存大几个数量级，你不能把所有数据一次性塞进 RAM，只能设计聪明的页面调度策略，让数据在磁盘和内存之间按需流动。排序、连接、聚合——所有关系代数操作都有外存版本。

RLM 做的事情，就是把这套逻辑搬到 LLM 身上：

内存 = LLM 的 context window（GPT-5 是 272K tokens）
磁盘上的大数据集 = 用户给你的超长 prompt（论文测到 1100 万 tokens）
页面调度策略 = LLM 在 Python REPL 里写代码，决定什么时候 peek 哪一段 context

一旦你用这个视角看 RLM，很多事情就豁然开朗了。它不是"让模型处理更长的上下文"，而是"让模型成为自己上下文的调度器"。模型从被动的 token 吞吐器，变成了主动的内存管理器。

数据说话：四个 benchmark 的硬核对比

论文的核心实验在四个任务上跑：CodeQA（代码理解）、BrowseComp+（深度研究，600-1100 万 token）、OOLONG（长文推理聚合）、OOLONG-Pairs（配对推理，连 GPT-5 都会崩的任务）。

看 GPT-5 的数据（Table 1）：

方法	CodeQA	BrowseComp+	OOLONG	OOLONG-Pairs
Base GPT-5	24.00*	0.00*	44.00	0.04
CodeAct (+BM25)	22.00*	51.00	38.00	24.67
Summary agent	58.00	70.47	46.00	0.01
RLM	62.00	91.33	56.50	58.00

带 * 号的是连模型 context 窗口都塞不进去的任务。Base GPT-5 在 BrowseComp+ 上直接 0 分——不是做不好，是根本进不去。

几个关键对比：

vs Summary agent（上下文压缩）：BrowseComp+ 上 RLM 91.33 vs Summary 70.47，而且 RLM 成本 $0.99 vs Summary $0.57。RLM 更贵但质量高 30%。在 OOLONG-Pairs 上差距更夸张：58.00 vs 0.01——Summary agent 在这个任务上几乎完全失效，因为它把关键细节压缩没了。
vs CodeAct（工具调用 agent）：OOLONG-Pairs 上 RLM 58.00 vs CodeAct 24.67。论文给的 median 提升是 130%——这是对 CodeAct 的碾压。
成本：RLM 在 BrowseComp+ 上 $0.99 处理 600-1100 万 token，而直接喂给 GPT-5-mini 要 $1.50-$2.75。RLM 更便宜还更好。

论文里有一句精辟的："RLMs can scale to the 10M+ token regime"——一千万 token 级别。这不是渐进式改进，是两个数量级的跨越。

模型在 REPL 里到底干了什么：四种涌现行为

论文最有趣的部分是 §3.1 的 trajectory 分析。作者发现，即使没有专门训练，模型在 RLM 框架里自发发展出了四种行为模式：

1. 用代码过滤，不让 context 进脑子

RLM(GPT-5) 在 BrowseComp+ 上处理一个关于某小镇的问题，它没有把整个语料读进来，而是写了一段 regex 代码，搜索包含 "festival" 和 "La Union" 的 chunk。模型的 prior 知识告诉它这些词和问题相关，于是它用代码把搜索空间从几百万 token 缩小到几百行。

这和数据库的 索引扫描 完全同构：不是全表扫描，而是先用索引定位再读取。模型在 REPL 里写的就是"查询计划"。

2. 分块 + 递归子调用

Qwen3-Coder 在 OOLONG 上处理 1000+ 行文本，它按换行符切分，然后对每个 chunk 调用 rlm_query()——也就是 spawn 一个子 LLM 处理这个小块。子 LLM 的结果以程序化方式返回，不污染父 LLM 的 context。

这是 MapReduce 的结构：父 LLM 是 reduce，子 LLM 是 map。但区别在于，这个 MapReduce 的调度计划是模型自己写的，不是程序员预设的。

3. 子 LLM 验证答案

模型会用子调用来验证自己的答案。一个有趣的失败案例（Appendix B.3）：模型在 OOLONG 上得到了正确答案，然后用子调用验证了五次，最后选择了错误答案。这说明模型有"自我怀疑"的倾向，但验证策略还不够成熟。

4. 变量传递实现超长输出

RLM 可以产生远超模型输出限制的 token——通过在 REPL 里把中间结果存到变量，用子调用生成片段，最后拼接。这是 流式处理 的思路：不一次性生成所有输出，而是分批生成、程序拼接。

RLM-Qwen3-8B：训练后的模型 vs 训练前

论文最重磅的实验是 RLM-Qwen3-8B——他们用 verifiers + prime-rl 框架对 Qwen3-8B 做了后训练，让它成为专门的 RLM 模型。

结果：RLM-Qwen3-8B 比原始 Qwen3-8B 平均提升 28.3%，在三个长上下文任务上接近 vanilla GPT-5 的质量。

这个数字的意义在于：8B 参数的模型，经过 RLM 训练后，能逼近 GPT-5 的长上下文能力。这不是"更大的模型做更好的事"，是"换一种范式让小模型做大模型的事"。

训练环境开源在 training/ 目录，用 OOLONG 作为训练任务。作者把 RLM 的 trajectory 视为一种 reasoning，可以用 bootstrap 方法训练（类似 STaR 的思路）。

诚实的失败清单：Appendix A

论文有一个 Appendix A 叫 "Negative Results: Things we Tried that Did Not Work"——这种诚实度在顶会论文里不多见。几个关键失败：

1. 同一个 system prompt 不能跨模型用：为 GPT-5 写的 prompt 直接给 Qwen3-Coder 会导致子调用过多。每个模型需要定制 prompt。 2. 小模型当 RLM 不行：Qwen3-8B 原始版本 coding 能力不够，在 REPL 里挣扎。必须先训练才能用。 3. Thinking 模型输出 token 不够：Qwen3-235B-A22B 作为 RLM 时，thinking token 会撑爆输出限制。OOLONG 上从 30% 提到 38%，但多个 trajectory 因输出超限而中断。 4. 同步子调用太慢：所有子 LLM 调用是阻塞的，没有并行。作者承认这可以修复，但当前实现很慢。 5. FINAL() 标签脆弱：模型有时把思考过程当成最终答案输出。结构化输出会降低性能。

这些失败比成功更有价值——它们划定了 RLM 范式的边界：RLM 需要模型有足够的 coding 能力，需要足够的输出 token，需要异步基础设施，需要训练来学会何时输出最终答案。

代码仓库：alexzhang13/rlm

开源在 https://github.com/alexzhang13/rlm ，PyPI 包名 rlms，pip install rlms 即可使用。

核心 API 就一行：

from rlm import RLM
rlm = RLM(backend="openai", backend_kwargs={"model_name": "gpt-5-nano"})
print(rlm.completion("你的超长 prompt").response)

支持多种 REPL 环境：local（默认）、IPython、Docker、Modal、Prime Intellect Sandboxes、Daytona、E2B。后两者是云端隔离环境，适合生产场景。

训练部分在 training/ 目录，基于 Prime Intellect 的 verifiers 和 prime-rl 框架。训练环境用 OOLONG 任务，可以 plug-and-play 换成自己的任务。

生态已经有人跟进：DSPy 集成了 RLM、context-labs 做了 HALO（基于 RLM 的自动 agent 优化循环）、Symbolica 用 REPL Agent 刷了 ARC-AGI-2 SotA。Prime Intellect 官方博客直接标题写 "Recursive Language Models: *the* paradigm of 2026"。

概念谱系定位：第十一位成员

RLM 是"换层面解决问题"概念谱系的第十一个成员。完整谱系：

1. 章鱼 RNA 编辑——不改 DNA，改施工图 2. 黏菌外化记忆——不用神经元，用黏液 3. 鸟类量子磁感应——不用经典物理，用量子 4. SOPHIA 分工——不统一处理，按状态分流 5. EvoThink 原子推理——不连续推理，分段 6. Möbius RoPE 拓扑干预——不调参数，换拓扑 7. 螳螂虾声子盾牌——不蛮力阻挡，选择性过滤 8. Euclid-MCP 推理外包——不训练模型推理，外包给 Prolog 9. Regression Tax 配对评测——不看平均，看配对 10. ACE 上下文工程——不堆 context，压缩+分段 11. RLM 上下文外存化——不塞 context，当变量管

RLM 的独特之处在于：它不是在模型内部解决问题（改架构、改训练），而是在模型外部解决问题（把 context 变成环境变量）。这和 out-of-core 算法的精神完全一致：当数据比内存大几个数量级，不要试图扩大内存，而是设计聪明的调度策略。

Sutton 在 "Bitter Lesson" 里说：利用计算的方法最终会赢。RLM 印证了这一点——它不追求更大的 context window，而是用 inference-time compute 换 effective context。272K 的窗口处理 1100 万 token，靠的不是更大的窗口，是更聪明的调度。

一个未解的工程问题

RLM 目前递归深度只有 1（子调用是普通 LLM，不是 RLM）。论文在 Limitations 里提到：未来应该探索更深的递归层。这意味着 RLM 树可以有多层：根 RLM spawn 子 RLM，子 RLM 再 spawn 孙 RLM。

但就像原帖指出的：操作系统有调度器、资源限制、权限隔离，RLM 树目前什么都没有。谁来管总 token 预算？谁来处理一个子 RLM hang 住的情况？谁来隔离恶意子调用的副作用？

Continual Harness 的 /refine 机制是作者给出的答案——让 agent 自己学会管理。但这把问题从"工程设计"推到了"训练模型学会工程设计"——和 Sutton 的 Bitter Lesson 又对上了。

RLM 的真正赌注不是"更好的长上下文处理"，是"模型学会自己管理自己的计算资源"。如果这个赌注赢了，context window 的大小就不再是瓶颈——因为模型自己知道什么时候该把什么拉进窗口，什么时候该推出去。

论文链接：https://arxiv.org/abs/2512.24601 代码：https://github.com/alexzhang13/rlm