The more context agents accumulate, the worse they perform due to a phenomenon called context rot. Recursive language models (RLMs), proposed by Alex Zhang and researchers at MIT CSAIL, address this: instead of working turn by turn or relying on lossy summarization, the model runs code in a REPL that dispatches subagents and recurses over pieces of the input context.Agent 积累的上下文越多，表现反而越差，这种现象称为上下文腐化。Alex Zhang 与 MIT CSAIL 的研究人员提出了递归语言模型（RLM）来解决此问题：模型不再逐轮推理或依赖有损摘要，而是在 REPL 中运行代码，由代码派发子 agent，并对输入上下文进行递归处理。
Consider an agent finding the average deal size across 10,000 sales call transcripts. Turn by turn, the model has to track a running total in its own context, and that total risks drift the longer it counts. An RLM-style agent keeps the orchestration and counting in code instead, not the model's ephemeral context window.设想一个 agent 需要计算一万份销售通话记录的平均交易额。若逐轮处理，模型必须在自己的上下文中追踪累加总数，计数越长，结果越容易偏离。而 RLM 风格的 agent 将编排与计数放在代码中，而非模型那稍纵即逝的上下文窗口里。
The paper shows RLMs can process inputs up to two orders of magnitude beyond a model's context window and outperform vanilla agents in the process. We just built RLM support into Deep Agents with dynamic subagents.论文表明，RLM 能够处理超出模型上下文窗口两个数量级的输入，且在此过程中表现优于普通 agent。我们刚刚在 Deep Agents 中通过动态子 agent 实现了对 RLM 的支持。
The Case for RLMs为何选择 RLM
RLMs are language models that recursively call themselves, or other LLMs, before producing a final answer. Rather than forcing the entire prompt into the context window, the model loads it as a variable inside a REPL and writes code to peek into, decompose, and recursively call itself over snippets of it.RLM 是一种递归调用自身或其他大语言模型的模型，最终才给出答案。它并非将整个提示强行塞入上下文窗口，而是将提示作为变量加载到 REPL 中，编写代码来窥探、分解并对片段递归调用自身。
The paper's first hypothesis for fighting context rot was simple: split the work across model calls instead of forcing it all into one.论文对抗上下文腐化的第一个假设很简单：将工作分散到多次模型调用中，而非全部塞进一次调用。
The natural solution is something along the lines of, "well maybe if I split the context into two model calls, then combine them in a third model call, I'd avoid this degradation issue". We take this intuition as the basis for a recursive language model.自然的思路大致是：“或许我可以把上下文拆成两次模型调用，再用第三次调用合并结果，这样就能避免退化问题。”我们正是以这一直觉作为递归语言模型的基础。
That's also, roughly, what subagents already do: Deep Agents subagents isolate context, delegate discrete units of work, and keep intermediate results out of the main context window. But normal subagents still rely on the model deciding what to do next, one reasoning turn at a time, which breaks down once orchestration needs real structure like hundreds of calls, branching, or multi-phase work.这大致也是子 agent 已有的做法：Deep Agents 的子 agent 隔离上下文，委派离散的工作单元，并将中间结果隔离在主上下文窗口之外。但普通的子 agent 仍然依赖模型一步步决定下一步做什么，一旦编排需要真正的结构——比如数百次调用、分支或多阶段工作——这种方式就会失效。
RLMs give the model an environment it can act on programmatically, with the same primitives you'd reach for on any large dataset (grep, partition, map, reduce). Programmatic orchestration of subagents enables two things that tool-based orchestration can't reliably deliver:RLM 为模型提供了一个可编程操作的环境，使用的原语与处理大型数据集时相同（grep、partition、map、reduce）。基于程序的子 agent 编排实现了两种基于工具的编排无法可靠交付的能力：
- Deterministic coverage. Coverage is guaranteed by code, not model judgment. A
for b in batchesloop touches every batch by construction, whereas a plain model has a hard time performing iterations like this at scale.确定性覆盖。覆盖由代码保证，而非模型判断。一个 for b in batches 循环必然遍历每个批次，而普通模型很难大规模执行此类迭代。 - Bespoke orchestration. Because the pipeline is code, it can take whatever shape the task needs, branching, parallel, sequential, instead of being limited to what a model can reliably carry out turn by turn.定制化编排。由于流水线是代码，它可以呈现任务所需的任何形态——分支、并行、串行——而不受限于模型能可靠执行的逐轮步骤。
How RLMs work in Deep AgentsRLM 在 Deep Agents 中的工作原理
Deep Agents supports programmatic orchestration through dynamic subagents, powered by a lightweight code interpreter. Instead of dispatching subagents turn by turn through tool calls, the model writes a short script and the code interpreter executes it. The canonical example, one subagent per page of a 300 page document:
Deep Agents 通过动态子 agent 支持程序化编排，其核心是一个轻量级代码解释器。模型不再通过工具调用逐轮派发子 agent，而是编写一段简短脚本，由代码解释器执行。一个典型例子：处理一份 300 页的文档，每页分配一个子 agent：
const results = await Promise.all(pages.map(page =>
task({ description: `Summarize page ${page.number}`, subagentType: "summarizer" })
));
A note on terminology. What we've built doesn't mirror the paper's shape exactly. The paper's approach is more extreme: the entire prompt is loaded into the interpreter and recursed on directly, and the recursive calls are plain LM calls, not agents with their own tools and state.关于术语的说明。我们构建的实现与论文的形态并不完全一致。论文的方法更为极端：整个提示被加载到解释器中直接递归，递归调用是普通的语言模型调用，而非拥有自身工具和状态的 agent。
What we're describing in Deep Agents is closer to recursive agents (RA), subagents with their own tool access and context, dispatched from code. RA might be the more precise term for what we're shipping, but it was certainly the RLM paper design motivated this capability and thus architecture.我们在 Deep Agents 中描述的更接近递归 agent（RA），即从代码派发的、拥有自身工具和上下文的子 agent。RA 或许是我们所发布功能的更精确术语，但确实是 RLM 论文的设计启发了这一能力，进而影响了架构。
In the RLM paper, it’s noted that once the model gets this kind of environment, the code it writes follows a few trends:RLM 论文指出，一旦模型获得这种环境，它编写的代码会呈现几种趋势：
A common pattern the RLM will perform is to chunk up the context into smaller sizes, and run several recursive LM calls to extract an answer or perform this semantic mapping.RLM 常见的一种模式是将上下文分块，然后运行多次递归的语言模型调用，以提取答案或执行语义映射。
Claude Code's docs on dynamic workflows name six of these patterns directly: fan out and synthesize, classify and act, adversarial verification, generate and filter, tournament, loop until done, a useful vocabulary regardless of harness.Claude Code 关于动态工作流的文档直接列出了六种模式：扇出与合成、分类与行动、对抗验证、生成与过滤、锦标赛、循环直到完成——无论使用何种框架，这都是有用的词汇。
The difference with Deep Agents is that the orchestrator and every subagent it dispatches can run on any model, or mix of models, you choose, rather than being scoped to one model family. You could pair a frontier model orchestrator with open-weight subagents like GLM 5.2 or Nemotron for cost and performance optimization at scale, or flip it — open-weight orchestration coordinating frontier subagents for deep research style workflows.Deep Agents 的不同之处在于，编排器及其派发的每个子 agent 都可以运行在你选择的任何模型或模型组合上，而不局限于某一模型家族。你可以将前沿模型编排器与开源子 agent（如 GLM 5.2 或 Nemotron）配对，以优化大规模场景下的成本与性能；也可以反过来——用开源模型编排器协调前沿子 agent，用于深度研究型工作流。
We cover six patterns like these for dynamic subagents in Introducing Dynamic Subagents and this walkthrough video.我们在《Introducing Dynamic Subagents》和本演示视频中介绍了六种类似的动态子 agent 模式。
Benchmarking with OOLONG使用 OOLONG 进行基准测试
To see programmatic orchestration in action, we tested it on OOLONG, a benchmark for long context reasoning and data aggregation where the answer depends on examining nearly every row in the input.为了验证程序化编排的实际效果，我们在 OOLONG 上进行了测试。OOLONG 是一个长上下文推理与数据聚合的基准测试，其答案依赖于检查输入中的几乎每一行。
We ran experiments on AgNews, structured as an OOLONG task: thousands of headlines, each with a date and user attached, and no visible topic label. To answer a question, the agent has to classify headlines into one of four categories (world, sports, business, and science/tech) and aggregate across the entire set.我们在 AgNews 上进行了实验，将其构建为 OOLONG 任务：数千条新闻标题，每条附有日期和用户，但没有可见的主题标签。要回答一个问题，agent 必须将标题分类到四个类别之一（世界、体育、商业、科技），并对整个数据集进行聚合。
The agent is then tasked with answering questions that fall into three categories, in order of increasing difficulty:随后，agent 需要回答三类问题，难度依次递增：
We ran this as a proof of concept, not a comprehensive benchmark:我们将其作为概念验证运行，而非全面的基准测试：
Scores are averaged across the AgNews question set, using OOLONG's scoring: exact match for categorical answers, partial credit for numeric ones, on a 0 to 1 scale. Numeric answers are scored as 0.75^|true - predicted|, so a numeric answer off by 1 still scores 0.75, while one off by 10 scores closer to 0.06.分数在 AgNews 问题集上取平均，采用 OOLONG 的评分方式：分类答案精确匹配，数值答案部分得分，范围 0 到 1。数值答案的得分为 0.75^|真实值 - 预测值|，因此偏差为 1 时仍得 0.75，偏差为 10 时则接近 0.06。
At 64k, both agents are still in a similar ballpark, the plain agent mostly keeps up:在 64k 规模下，两个 agent 仍处于相近水平，普通 agent 基本能跟上：
At 128k, it starts to fall apart, not with a subtly wrong answer, but by giving up outright: telling you it can't compute the result or is blocked.到了 128k，普通 agent 开始崩溃——不是给出细微的错误答案，而是直接放弃：告诉你它无法计算结果或受阻。
.png)
The differential is clear in the data as well:数据中的差异同样明显：
Note, We didn't optimize for the OOLONG workload: this was a smoke test of whether the base harness, with no task-specific prompting, could handle long-context problems at all. We actually expect these numbers undersell RLM potential.注意，我们并未针对 OOLONG 工作负载进行优化：这只是一次冒烟测试，检验基础框架（无任务特定提示）能否处理长上下文问题。我们实际上认为这些数字低估了 RLM 的潜力。
Get started in Deep Agents在 Deep Agents 中开始使用
Dynamic subagents need two things: subagents to dispatch work to, and a code interpreter, a secure, lightweight runtime where the model writes and executes orchestration code. Deep Agents ships with both. Install the QuickJS middleware and pass CodeInterpreterMiddleware to create_deep_agent:动态子 agent 需要两样东西：用于派发工作的子 agent，以及一个代码解释器——一个安全、轻量的运行时，模型在其中编写并执行编排代码。Deep Agents 两者都提供。安装 QuickJS 中间件，并将 CodeInterpreterMiddleware 传递给 create_deep_agent：
pip install -U "deepagents[quickjs]"
from deepagents import create_deep_agent
from langchain_quickjs import CodeInterpreterMiddleware
agent = create_deep_agent(
model="openai:gpt-5.5",
middleware=[CodeInterpreterMiddleware()],
)
Deep Agents includes a general-purpose subagent out of the box, but you can also configure custom subagents specialized for specific tasks, each with its own name, description, and system prompt. The orchestration script can dispatch to whichever subagent fits the job.Deep Agents 内置了一个通用子 agent，但你也可以配置针对特定任务定制的子 agent，每个都有自己的名称、描述和系统提示。编排脚本可以派发到最适合任务的子 agent。
Prompt with the word "workflow" to trigger dynamic subagents:在提示中使用“workflow”一词即可触发动态子 agent：
result = await agent.ainvoke({
"messages": [{"role": "user", "content": "Run a workflow that reviews every file in src/routes/ and summarizes the top risks."}]
})
The fastest way to try this without any setup is dcode, our terminal coding agent. It ships with the code interpreter already enabled, just install and ask for a workflow:无需任何设置即可尝试的最快方式是使用我们的终端编码 agent dcode。它已启用代码解释器，只需安装并请求一个工作流：
curl -LsSf https://langch.in/dcode | bash dcode
Concluding thoughts总结
The key to building effective agents is giving the model the right context at the right time for the given task. There's been a lot of talk about loops as the right unit for thinking about agent design, the agent loop, the verification loop, systems loops, and self-improvement loops.构建高效 agent 的关键，是在合适的时机为模型提供合适的上下文。关于循环作为 agent 设计的基本单元，已有诸多讨论：agent 循环、验证循环、系统循环、自我改进循环。
RLMs fit right into this loop-verse. They give the root model the power to write loops for itself modeled around the context and task shape.RLM 恰好融入这个循环宇宙。它们赋予根模型编写自身循环的能力，循环围绕上下文和任务形态而构建。
We're excited about dynamic subagents and the RLM workflows they enable because they give an agent the power to organize its own context, loop included.我们对动态子 agent 及其所启用的 RLM 工作流感到兴奋，因为它们赋予 agent 组织自身上下文（包括循环）的能力。
Further reading延伸阅读
- Recursive Language Models (paper)递归语言模型（论文）
- Alex Zhang's original blogAlex Zhang 的原始博客
- RLMs in Deep Agents videoDeep Agents 中的 RLM 视频
- Introducing dynamic subagents blog
- Common workflows video常见工作流视频
- Dynamic subagents docs动态子 agent 文档
