你把一本 20 万字的技术手册塞进最新的大模型。你问它，第 85 页的那个配置参数应该怎么配。模型想了很久。它吐出了答案，但错得离谱。它不仅胡编了一个参数，还顺便花光了你 10 块钱的 token。
这种事每天都在发生。现在的模型窗口越来越大，理论上能读几十万、甚至几百万字。但你把文本塞得越长，模型往往答得越差。Chroma 团队做过一次测试。他们找来 18 个模型，把长文本塞入窗口，测试理解能力。结果发现，18 个模型无一例外，性能全都退化了。这种现象，行业里叫作 context rot。
这说明，光靠把窗口拉大解决不了问题。Anthropic 的工程团队也发了文章。他们说，提升长文本能力的出路，绝非盲目拉大窗口。
而且，文本越长，任务越难，模型就忘得越快。比如，在一堆文本里找一根针（NIAH 任务），它勉强能应付。但在复杂的 OOLONG 任务里，需要比对每行语义，模型就无能为力了。
为了解决这个头疼的问题，Alex Zhang 提出了一个新方案：递归大语言模型（RLM）。
这个方案换了个方式处理 context。它没有去解决无限上下文的计算瓶颈。但是它指明了一条路：我们不应该再指望无休止地拉大模型的原生窗口。
RLM 改变了游戏规则。过去，我们把 context 塞进 prompt，让模型一次性读完。RLM 把 context 当作外部的数据对象。模型自己写代码，在外部有策略地去查。
这个改变在理论上很吸引人。但从目前的证据看，它也有明显的边界。该方案只有在 depth=1 配置下有效。此时，系统是一个根模型带一堆工作模型。
如果在当前的模型上跑多层递归调度，根本行不通。对于未训练过的模型，RLM 甚至跑得更慢、花钱更多、答得更差。所以，RLM 现阶段更像是一种接口约定。它还不是成熟的万能钥匙。
为了解决窗口不够大、大模型变笨的问题，业界目前有四种主流做法。但在面对需要高保真的任务时，它们都有自己的短板。
第一种是压缩（compaction）。有人尝试把 token 变少。比如 Context Folding 方案，或者 JetBrains 团队的做法。但这些方法在应对精细任务时，会丢掉关键细节。在 OOLONG-Pairs 测试中，压缩方案只有 0.1% 的 F1 分数。这说明，一旦任务对细节要求高，压缩就丢了关键信息。
第二种是普通 RAG。用 RAG 时，得预先切好文档（chunking）。但你没法预知运行时的各种查询维度。当任务需要跨段落找线索时，向量检索很难找准。它容易漏掉关键片段。
第三种是会写代码的 Agent。比如 OpenCode。遇到大文件时，它会自己写脚本或者跑 grep。这种做法擅长找关键字。但是，一旦要拼凑、对比语义，它就不灵了。在 OOLONG-Pairs 测试中，OpenCode 方案只有 4.8% 的 F1。
第四种是直接往大窗口里塞。这受物理限制。超出限制，模型就罢工了。而且，文本太长，即使没超限制，模型也会漏看埋在深处的重点。
也有人尝试做虚拟内存管理。MemGPT 就是其中之一。但在处理数据时，它还是要不断把 context 搬回大模型的窗口里。它没摆脱对原生窗口的依赖，本质上还是”先加载再管理”的缓存。
RLM 换了个思路。它彻底扭转了模型和 context 的关系：它不把文本塞进窗口，而是让文本留在外面，当成外部数据。
主模型（Root LM）开始干活时，窗口里只有元数据（metadata）。也就是长文本的结构、大纲和行号，并没有具体的文本。真正的长文本以变量形式，存在外部的交互式解释器（REPL）里。
主模型不需要一次读完所有 token。它像一个指挥官，通过写代码来主动查数。它给 REPL 发指令，比如预览（peek）或者搜索（grep）。它也可以把长文本切分成更小的块（chunk）。
如果发现某些片段有用，它就呼叫并行的工作模型（sub-LLM）。这些工作模型拿到筛选过的文本切片，在后台分析或计算。
最后，主模型把各个工作模型传回的结果拼起来，输出最终答案。
这种做法和 CodeAct 方案有本质区别。传统的写代码 Agent 虽跑代码，但它们仍要把数据读回窗口里做决策。
而 RLM 有一个硬约束：原始的长文本绝对不能进主模型的窗口。这是一种“不加载数据”（never-load）的设计。它打破了过去那种“先加载、再管理”的老路子。
我们来看看这个方案的数据表现。在论文里，研究员让 RLM 带着 GPT-5-mini 跑 OOLONG 测试。132K 上下文里，它比原生 GPT-5 的成绩高了 34 点。
BrowseComp-Plus 测了 1K docs（6-11M tokens）。原生 GPT-5 得了 0%，而 RLM 拿到了 91.3% 的准确率。在 OOLONG-Pairs 任务上，原生 GPT-5 只有 0.04% 的 F1。使用 RLM 方案后，这个分数上升到了 58.0%。
开源社区也对这个模式展现了热情。alexzhang13/rlm 项目在 GitHub 上拿到了 5230 stars。目前它有 850 forks，以及 81 open issues。
有人做过独立复现。调用深度为 depth=1 时效果不错。DeepSeek v3.2 在 OOLONG 上的成绩从 0% 到 42.1%。
研究员用 1000 个样本微调 8B 模型。微调后，模型的中位数性能提升了 28.3%。
但这些亮眼的数据背后，藏着不少漏洞和局限。
BrowseComp-Plus 测试的 91.3% 准确率可能注水了。Anthropic 团队评估时发现，该测试集有 20 多个数据泄露源。这意味着，模型可能早就看过了答案。
OOLONG-Pairs 是作者自己设计的测试集。原生模型只有 0.04%，自己的方案得 58.0%。这有自造嫌疑。而且，对比方案全由作者实现。他们很难把对手的参数调到最好。
如果把调用深度设为 depth=2，系统就会彻底失控。复现数据显示，模型处理两层以上调度时会犯糊涂，逻辑开始混乱。这会导致 28x latency 延迟和 100x token 消耗。在实际使用中，depth=2 几乎无法运行。
有些任务用 RLM 反而跑得更差。Prime Intellect 跑了消融实验，公布了坏消息：在数学和科学研究（DeepDive）任务中，RLM 的表现变差了。这些任务需要严密的逻辑推导，不适合用 RLM。
模型在运行时动态查数据，这导致查询次数极不稳定。复杂任务下，高分位数（Q95）的账单能飙到中位数的 10 倍以上，成本完全不可控。
开源圈子对此也有怀疑。AI 开发者 Teknium 在社交媒体上发表了质疑：Can someone explain to me how RLM is not just grep that all coding agents already use but in a subagent。
我们以前聊过“Context Governance”（上下文治理）这个概念。当时主张由模型外面的系统来管 context。系统帮大模型切片和过滤，再把特定数据喂进窗口，并限制大模型能读什么。
RLM 则是把这个权力交给了模型自己。它让模型自己决定：什么时候读、读多少、怎么聚拢数据。
这并不是说 RLM 可以取代外面的治理层。在实际工程里，治理层干的是粗活、管大方向。比如隔离安全权限、审计 API 调用、卡死预算、兜底可靠性。
而 RLM 干细活。它在运行中帮大模型挑选、寻址局部数据。
没有治理层卡预算，RLM 会变成无限循环的花钱黑洞。但没有 RLM 这种接口约定，治理层就只剩写死规则的僵硬 pipeline。
所以，这两者可以配合。RLM 是上下文治理的下一步：系统定规矩，模型自己查数。
目前的 RLM 跑不通 depth=2，也面临漏题、成本高昂等麻烦。但它提供了一个很有启发性的新角度。
大模型处理长文本，出路大概率不是无底线地拉长注意力窗口。我们要去探索怎么在外部 REPL 里，给数据配上调度接口。
RLM 真正的价值不是分数。它把 context 变成了外部数据空间。在这个空间里，模型通过运行代码指令，自己去查找、预览和处理数据。
把这种接口约定做成标准产品，或许才是我们管好长文本的真正方向。