什么是 RLM
RLM（Recursive Language Model）由 Alex Zhang 等人在 2025 年 10 月提出，核心思想一句话：语言模型把输入 Prompt 视为一个环境，而非固定字符串。
具体做法：根 LM 获得一个 REPL，其中 prompt 被绑定到一个变量，模型可以编程方式检查、切分、按区域划分。当它认定某个区域值得细看时，发起一个递归子调用——调用自己或其他 LM——处理那个切片，并把结果合并回来。递归最终在基础模型的普通前向传播处终止。
一个直接结果：输入大小不再受 context window 的硬性限制。论文报告 RLM 处理了比底层模型 context window 高两个数量级的输入，并在四个长上下文任务上优于普通前沿 LLM 和常见长上下文脚手架。
推理与工具调用：两条能力轴的融合史
推理关注模型如何将推理时计算分配给问题：分解、探索替代方案、验证中间步骤、回溯、选择更好答案。早期的推理进展来自 Chain-of-Thought、Self-Consistency、Tree-of-Thought 等方法——这些方法改善的是模型"如何思考"，即使它从不接触外部世界。
工具调用关注模型是否能够决定调用外部函数、搜索引擎、计算器、浏览器、代码运行器或 UI 操作；传递正确参数；解释结果；继续。这部分是一个推理问题，但也是接口和可靠性问题：schema、参数格式化、重试、停止条件、状态跟踪、错误恢复。
历史上两条轴是分开的：
- 2022：推理 without 工具。Chain-of-Thought 证明要求模型生成中间推理步骤可以显著改善多步推理
- 2022 末：ReAct 成为推理和行动之间的桥梁，模型在推理 trace 和外部行动（检索、环境交互）之间交替
- 2023：工具调用成为 API 规范，Toolformer 让模型可以在生成过程中学习何时调用工具、调用哪些工具、如何incorporate结果
- 2024：OpenAI o1 发布，推理模型成为独立产品类别，但功能调用尚未包含——强有力地证明了推理和工具调用在产品层面仍然是可分离的
- 2024-2025：Anthropic 的 Claude 3.5 Sonnet 强化了编程和 agentic 任务的工具使用；Google Gemini 2.0 明确围绕"agentic 时代"和原生工具使用设计，但仍把"思考"作为独立能力保留
- RLM 是这两条轴最终合并的抽象层
RLM 的三个失败模式
RLM 的实证结果经历了三个连续的单一 forward pass 失败模式，每个都有各自的 benchmark：
1. Long Context（Oolong，2025 年 11 月）
比 needle-in-a-haystack 检索更难：模型需要分析多个局部 chunk，然后将它们聚合成全局答案。发布时，GPT-5、Claude-Sonnet-4、Gemini-2.5-Pro 在 128K 下两个 split 均低于 50%——这使得 Oolong 成为 RLM 试图解决的"上下文作为工作区推理"的早期 benchmark。
2. Memory（LongMemEval，2024-2025）
定义了长期交互记忆的 benchmark：跨越提取、多会话推理、时间推理、知识更新和弃权的 500 个问题。RLM 风格系统是否能用递归/工具介导的处理充当记忆系统，而非仅仅一个长上下文 hack？DSPy.RLM 在 LongMemEval 上取得了竞争性数字，低于 Mastra 的 94.87%，但已是有力证据。
3. Long Reasoning（LongCoT，2026 年 4 月）
2500 个专家设计的长时间 chain-of-thought 推理问题。发布时最佳模型仍低于 10% 准确率（GPT-5.2 为 9.8%，Gemini 3 Pro 为 6.1%）。但 RLM + DSPy.RLM 立即打破了这个局面：
- Claude Sonnet 4.5 + DSPy.RLM：45.4% vs 无递归/tools 的 2.6%
- Qwen3-8B + DSPy.RLM：6.5%（vs 0%）
- Qwen3.5-9B + DSPy.RLM：15.69%，约 1.6× GPT-5.2
- Qwen3.5-27B + DSPy.RLM：22.18%，超过 GPT-5.2 两倍以上
RLM 的限制
成本和时间：RLM 很贵，需要很长时间。更糟的是，在朴素实现中，时间不可预测且无界，因为模型自己在决定如何分解问题。解法：每个子调用用更小更快的模型，将 agent-native 的"自相似"分解与确定性图拓扑和时间线控制相结合。
更深层的挑战：让语言模型"递归地行动"：递归的概念在预训练数据中，推理和平行工具调用是 post-training 激励的行为，子 Agent 可能是 RLM 的近亲行为类比。但任何使用过 RLM 的人都会告诉你，模型通常对递归行为表现很差——它们不会本能地把 prompt 分解成多个子查询来帮助解决各自的问题。
这可能是一个价值数十亿美元的问题：最优递归的奖励函数是什么？
最令人惊讶的结果
小型本地模型 + RLM 的潜力。Qwen3-8B 这类小到可以在消费设备上运行的模型，配合 RLM 可以在 LongCoT 上超越 GPT-5.2。如果这是正确的方向性判断， frontier 将不再只是最大实验室才能触及的地方——个人或财团在负担得起的/遗留的/本地计算基础设施上运行多个小模型实例，现在可以访问与前沿实验室最昂贵 LLM 相当或超过它们的模型能力。
如何开始
- rlm（Alex Zhang 等人）：参考实现，最干净的核心递归 loop 解读
- DSPy.RLM：DSPy 集成，将 RLM 作为可组合模块用于更大的 DSPy 程序
- AxAgent（TypeScript）：具有一流 RLM 支持的 TypeScript DSPy 风格框架
- raw-repl：作者的 CLI wrapper，围绕目录即上下文、JSON-first 输出、自文档化命令
- recursive_coder：作者在本地构建的递归编码 agent，基于 jj workspaces 的隔离递归执行
这篇文章的核心洞察不是"RLM 比其他方法更好"，而是推理性能越来越不像单一 forward pass 的属性，而更像模型如何管理可执行外部计算的属性。