SOTA Sync
← 返回 FEED
AGENT2026-04-20

RLM：把 llm.completion() 变成递归调用——MIT 的无限长上下文推理引擎

语言模型在推理长文档、处理多步问题时，面对一个根本性限制：上下文窗口是固定的，而任务的深度往往是不固定的。

传统应对方式——分块、滚动窗口、RAG 检索——都是在"外部"裁剪上下文。RLM 走的是另一条路：让模型自己决定怎么拆解任务，并在 REPL 环境里递归调用自身。

核心范式：用 REPL 取代静态上下文

RLM 的核心替换只有一行：

# 传统方式
result = llm.completion(prompt, model)

# RLM 方式
result = rlm.completion(prompt, model)

表面上看只换了前缀，背后的执行模型完全不同：

  • 传统 LLM 推理：模型接收完整 prompt，一次性生成输出，上下文在调用前就必须确定
  • RLM 推理：模型在 REPL 环境里运行，可以把上下文作为变量存储，可以写代码读取变量，可以发起子调用（sub-LM call）并收集结果，再继续执行

这个机制让模型能以"程序"的方式处理问题——不是一次性回答，而是分解、执行、聚合。

技术架构

三层调用结构

一次 RLM 推理通常包含：

  1. 根调用（Root LLM Call）：接收原始任务，决定是否需要递归拆解
  2. REPL 执行层：运行代码、读写中间变量、调用工具
  3. 子调用（Sub-LM Calls）：针对子任务递归发起更小粒度的 LLM 调用，每个子调用独立有自己的上下文

这种三层结构让模型在理论上可以处理任意深度的任务分解，同时每层的上下文窗口保持在可管理范围内。

六种沙箱环境

RLM 支持隔离与非隔离两类执行环境：

非隔离环境（适合本地测试）：

  • local（默认）：在宿主进程内通过 Python exec 执行，共享同一虚拟环境
  • docker：通过 Docker 镜像隔离，支持自定义基础镜像

完全隔离环境（适合生产）：

  • modal：Modal Sandboxes，按需云执行
  • prime：Prime Intellect Sandboxes（beta）
  • daytona：Daytona 开发沙箱
  • e2b：E2B 代码执行沙箱

环境配置只需一行：

rlm = RLM(
    environment="modal",  # "local", "docker", "modal", "prime", "daytona", "e2b"
    environment_kwargs={...},
)

模型提供商支持

目前支持：OpenAI、Anthropic、OpenRouter、Portkey，本地模型可通过 vLLM + OpenAI 兼容接口接入。

快速上手

pip install rlms

from rlm import RLM

rlm = RLM(
    backend="openai",
    backend_kwargs={"model_name": "gpt-5-nano"},
    verbose=True,
)

result = rlm.completion("Analyze this 50,000 word document and extract all key decisions.")
print(result.response)

轨迹可视化

RLM 内置了一套基于 shadcn/ui 的 Web 可视化工具，可以展示每次推理的完整执行轨迹——包括根调用、REPL 代码执行记录、子调用路径和最终聚合过程。调试长链推理时尤其有用，因为递归调用链一旦超过三层，凭日志很难理清执行顺序。

from rlm.logger import RLMLogger
from rlm import RLM

logger = RLMLogger(log_dir="./logs")
rlm = RLM(..., logger=logger)

# 运行后打开可视化
# cd visualizer/ && npm run dev

背景：MIT OASYS Lab + DSPy 血统

RLM 出自 MIT OASYS 实验室，论文作者包括 Alex L. Zhang、Tim Kraska（数据库+ML 系统领域著名研究者）和 Omar Khattab——DSPy 的作者。

这个血统值得关注：DSPy 的核心思路是把 LLM 的 prompt 工程变成可组合、可优化的程序模块；RLM 把这个思路延伸到了执行层面——不只是 prompt 可以是程序，LLM 的推理本身也可以是递归执行的程序。

两者是互补关系：DSPy 解决"怎么写 prompt"，RLM 解决"推理时怎么执行"。

与 Agent 框架的关系

现有 Agent 框架（LangGraph、OpenAI Agents SDK 等）的递归/循环执行通常是在框架层面编排的：框架决定何时调用哪个模型，模型本身不知道自己处于递归调用链中。

RLM 的做法是把这个递归决策权下放给模型自身：模型在 REPL 里判断是否需要拆解，决定拆成几个子任务，并直接发起子调用——框架只提供执行基础设施，不干预拆解逻辑。

这在长文档分析、代码库理解等"无法预知递归深度"的任务上，比固定拓扑的 Agent 图更灵活。

论文 arXiv 链接：arxiv.org/abs/2512.24601

相关