Recursive Language Models(RLM)2025 年 12 月提交、5 月 11 日最近一次修订,提出通过给 LLM 一个可递归调用的 Python REPL,把可处理的 prompt 长度推到模型原生 context window 之上两个数量级。Alex L. Zhang、Tim Kraska(MIT)和 Omar Khattab(Stanford,也是 DSPy 和 ColBERT 的作者)报告:在 GPT-5 上比压缩方法高 26%,比带子调用的 CodeAct 高 130%,比 Claude Code 在四项长上下文任务上高 13%,成本相当。微调后的 RLM-Qwen3-8B 比 baseline 的 Qwen3-8B 高 28.3%,在三项长上下文任务上接近 vanilla GPT-5。arXiv 2512.24601。
机制:父 LLM 跑在一个 Python REPL 里,用户上下文绑定到一个 `context` 变量,一个 `llm_query()` 函数派生 RLM 子实例,每个子实例有自己的全新 REPL。让整套东西跑通的关键架构选择是:子的响应作为 Python 变量返回,而不是作为文本被倒回父的 context window。父通过变量引用来组合最终答案 —— "我让子调用 A 构造的字典"、"我让子调用 B 列的国家清单" —— 不用付重新把它们的输出 inline 进去的 token 成本。这就是它跟 Anthropic Claude Code 的 subagents 以及 CodeAct 的结构性差别 —— 那两个都是把文本返回到父正在跑的上下文里。
对应到现有的智能体架构分类:ReAct(单智能体加 tool loop)、CodeAct(智能体调用用户定义的 Python 函数)、Self-Loops(智能体用总结后的历史重新提示自己)、Subagents(主智能体通过文本委派给专家子智能体)。RLM 最接近 Subagents,但语义是返回符号引用而不是返回文本。经济性 claim —— 在四项上都赢的同时成本相当 —— 来自不把父上下文用子输出撑爆,父只需要按引用拿到这些输出。论文提出但还没完全为生产环境解决的两个问题:当一半推理藏在不透明的变量引用后面时怎么 debug,以及子计算怎么跨 run 做缓存。
周一上手:如果你在运营一个智能体系统,因为子智能体或 tool 的输出吃光了 context 预算而撞墙,符号返回这个模式今天就可以落地,不必整套搬 RLM —— 把你的 subagent 调用包一层,让父拿到的是"输出存在哪里"的句柄,而不是输出本身。Qwen3-8B 的结果(同一个模型上 28.3% 的提升)说明这个技术是跟你正在跑的任何模型组合相加的,不限于前沿模型。看 Anthropic、OpenAI 或 Google 在未来两个季度,是否会把符号返回的语义吸进它们第一方的 subagent 产品里。