RLM（递归语言模型）：让模型写代码自己调用自己，而不是调用工具
- RLM 就是让模型拥有「自己调用自己」的能力：主 Agent 写代码派出子 Agent 分工，上下文从模型窗口挪进变量和文件。
- 官方实测划出一条实用分界线：64k 上下文时开不开差别不大，到 128k 才明显拉开。
- 代价也一并交代了：延迟更高、token 更贵，换来的是准确率和确定性。
什么是 RLM（递归语言模型）
用大白话说，RLM 就是让 AI 模型拥有「自己调用自己」的能力。
这句定义容易听过就算，得跟传统做法摆在一起看才明白差在哪：
你给 Agent 一个超长文件，它必须把所有内容一次性塞进有限的记忆（上下文窗口）里去分析。
结果往往是前面记了后面忘，或者一做总结就丢掉大量细节。
模型的编排逻辑写在代码里。主 Agent 变身总指挥，可以编写代码去创造多个子 Agent 分工协作，也就是分治策略（divide and conquer）。
大部分上下文和中间数据保存在变量或本地文件中，而不是硬塞进上下文窗口。
差别落到实处是这样的：模型不再需要「把整本书背下来再回答」，而是「写一份处理流程，需要哪一页就翻哪一页」。
一个视频里没交代的背景：RLM 这个概念不是 LangChain 提出的。它出自 Alex Zhang 2025 年 10 月的一篇博客，后来有了正式论文（arXiv:2512.24601）。LangChain 做的事情是把这个范式接进自己的 Agent 框架，让它能直接用起来。
本文拆解的是 LangChain 开源工程师 Sydney Runkle 的一段 6 分 36 秒官方技术分享，主题就是怎么在 Deep Agents 里用上 RLM。
LangChain 官方演示全片，6 分 36 秒，本站配中英双语字幕。下面拆的就是这段视频讲的内容。
RLM 解决了什么痛点
它冲着三个问题去的，前两个是 Agent 的老毛病。
传统 Agent 处理上万行的文件时，很难做到确定性地逐行处理。它读一遍、凭理解回答，这种方式在数据量大起来之后就不可靠了，你没法保证每一行都被真正看过。
上下文窗口是有限的。长对话跑下去，迟早要做摘要来腾地方。而摘要是有损的（lossy），你不知道被压缩掉的那部分，是不是恰好包含关键的那一行。
改成代码驱动之后，循环（loops）、并行扇出（fan out）、流水线（pipelining）这些复杂的逻辑结构，模型都能轻松搭出来。凡是代码里能写出的编排方式，这里都能用。
把编排交给代码之后，换来的是两样东西：
- 确定性覆盖，代码能保证每一行都被处理到，不漏。这对大规模数据问题特别关键。
- 定制编排，想怎么组织工作就怎么组织，用的是代码级别的原语。
如何在 Deep Agents 中使用
Deep Agents 是 LangChain 的开源 harness（框架骨架），用来搭那种应付复杂真实任务的通用 Agent。在它里面开启 RLM 只有两步。
给主 Agent 挂载一个轻量级的代码执行环境。这里有个设计取舍值得注意：它足够轻，让模型能写代码、跑代码，而不必动用一整个沙箱那么重的东西。
主 Agent 编写代码，调用内置的 task 函数来启动和调度子 Agent，处理完毕后再由主 Agent 汇总结果。task 调用的前后还可以有别的代码，调用之前做数据准备，全部调完之后做聚合。
上手方式很简单：用 create deep agent 原语，把 code interpreter middleware 传进去，就开启了 code mode。
高亮那两行就是 RLM 的全部机密：编排逻辑是代码，task 是唯一的分叉点，它前后都还是普通代码。示意代码，非视频原文。
DEMO实际演练：16 个子 Agent 比赛写俳句
演示环境是 decode，LangChain 基于 Deep Agents 框架做的终端编码 Agent，命令行里敲 decode 就能启动。
触发 RLM 的关键词是 workflow。演示里给的指令是：跑一个 workflow，生成 16 首关于早餐食物的俳句，然后用锦标赛的方式选出最好的一首。
接下来发生的事情是这样的：主 Agent 自动生成了 16 个子 Agent，很快各自写出一首诗；然后它开始写代码（调用 JS eval 工具）分轮次比拼，16 强、四分之一决赛一路打下去；中途有一段代码写错了，模型自己发现并纠正；最后决出冠军，是一首关于浆果的俳句。
这个演示本身不复杂，但它把形态演出来了：先扇出 16 个并行，再按锦标赛结构逐轮收敛，这就是「用代码原语组织工作」落到实处的样子。
性能与基准测试对比
演示之外，官方给了一组实测。用的是 Oolong 数据集，专门考验模型长上下文推理和数据聚合能力的那类基准。
SETUP测试是怎么设计的
取的是 Oolong 的 AgNews 部分，结构是一张几千行的大表，每行有三样东西：日期、用户、一条没有标签的新闻标题。
任务分两步：先让模型给每条标题分类，四选一，world（世界）、sports（体育）、sci/tech（科技）、business（商业）；然后问关于这些数据的分布性问题。
问题按难度分三档：
| 难度 | 类型 | 例子 |
|---|---|---|
| 最简单 | 计数 | 所有标题里，哪个标签最少见 |
| 中等 | 先过滤再计数 | 某个特定用户名下，有多少条科技类标题 |
| 最难 | 时间推理 | 2004 年 8 月之前，体育类标题是不是比世界类多 |
难点全在数据量上：几千行一股脑塞给模型，再让它做这些分类、聚合和推理，没有 RLM 或者某种代码支持，这件事基本做不好。
RESULT两档上下文长度，结果完全不同
对照的是两个配置：不开代码解释器的普通 Deep Agent，和开了代码解释器、也就是启用 RLM 的版本。
两者差异不大，基本打平。这一档上不上 RLM，看不出明显好处。
启用 RLM 的版本优势极大。普通版开始大面积答不出来。
条长为趋势示意：视频只展示了图表走势，未公布具体分数。
更值得看的是普通 Agent 输在哪：在 128k 那一档，它给出的答案里有大量「我无法精确回答」「我被挡住了算不了」，模型是被过大的信息量压垮之后直接放弃了。而启用 RLM 的版本依然能按代码逻辑把任务拆开，算出正确答案。
由此可以推出一个判断：如果上下文再长一些，或者问题再难一些，启用 RLM 的那一版会继续拉开优势。
TRADE-OFF代价：更慢、更贵
代价在视频里一并交代了：RLM 模式的延迟明显更高，消耗的 token 也更多。换来的是准确率和确定性。
不过这块还有优化空间。讲者提到：如果进一步调优，比如设计一些 skills 来说明该怎么处理这类特定问题，token 用量和成本能砍下来不少。
核心价值总结
不再依赖庞大的上下文窗口，而是用「代码 + 子 Agent 分治」的方式来处理海量数据。上下文住进变量和文件，模型要哪块取哪块。
复杂的大规模分类、统计和逻辑推理交由程序去严格执行，而不是让模型凭理解给个大概。这大幅提升了 Agent 在复杂真实业务场景下的可用度。
落到「我该不该上」这个问题上，那条实测分界线是最实用的答案：数据量还没到把上下文撑爆的程度，上了也看不出好处，还白付延迟和成本；到了 128k 这种量级，或者任务本身就要求逐行不漏，它的价值才出来。
视频未交代的信息：实验用的是哪个模型全程没说，这直接影响结论能不能迁移到你自己的场景；延迟和成本只给了定性描述，没有倍数；准确率只展示了图表趋势，没有具体分数；task 函数的签名与子 Agent 的配置方式没有展开；演示中模型自我纠错是常态还是偶发，也没有交代。
模型学会写代码调用自己：上下文冲过 128k 才看出差距
LangChain 工程师 6 分半的官方演示，一页带图讲完机制、俳句锦标赛，和该不该上的实测判断
↓ 一页读完 · 有一张会动的图
RLM（递归语言模型）让模型有了「自己调用自己」的能力：主 Agent 写代码，派生出多个分身去处理数据，处理完再汇总回来。这个概念不是 LangChain 提出的，出自 Alex Zhang 2025 年 10 月的博客和后续论文，LangChain 做的是把它接进自己的 Deep Agents 框架。
把整份资料一次性塞进上下文窗口，装不下就先做摘要，摘要是有损的，被压掉的那部分可能刚好是关键的那一行。
编排逻辑写进代码里，主 Agent 当总指挥，写代码派生出多个分身分头处理；大部分资料存在变量和文件里，要哪块取哪块。
换来两样东西：代码保证每一行都被处理到（确定性覆盖），循环、并行扇出、多步流水线这些复杂调度也能轻松搭起来（定制编排）。
Deep Agents 是 LangChain 的开源框架，用来搭应付复杂真实任务的通用 Agent。加 RLM 只要两步：给主 Agent 挂一个轻量代码执行环境（不用一整个沙箱那么重），再让它用内置的 task 函数写代码调度子 Agent，调用前后都能写别的代码，比如准备数据、汇总结果。上手用 create deep agent 原语，把 code interpreter middleware 传进去，关键词 workflow 触发。
官方演示之外还有一组实测，用的是 Oolong 数据集里的 AgNews 部分，几千行没打标签的新闻标题。任务是先给每条分类（世界/体育/科技/商业），再答统计问题，难度从「哪个标签最少见」一路加到「某月之前体育是不是比世界多」。
128k 这一档，普通 Agent 大量回答「无法算」「无法精确回答」，是被信息量压垮直接放弃了；RLM 版依然按代码逻辑拆开算出正确答案。
这套东西换来两件事：一是不用再靠塞爆的上下文，资料放进变量和文件里按需取；二是大规模的分类、统计、推理交给代码严格执行，不再是模型凭印象给个大概。
✔ 任务本身要循环、并行扇出、多步流水线这类复杂编排
✘ 数据量还没到上下文吃紧的地步，延迟更高、token 更贵，好处看不出来
✘ 只是想省事、准不准无所谓的场景，普通 Agent 已经够用
视频没说用的是哪个模型，准确率也只有图表走势没给具体分数，延迟和成本只说了方向没给倍数，这些决定结论能不能套到你自己的场景。
for c in 16 份