如何在Deep Agents中使用递归语言模型

递归语言模型（RLM）是解决大型语言模型在处理长上下文时出现的“上下文腐烂”问题的一种方法。随着代理积累越来越多的上下文，其性能会下降。RLM通过让模型在REPL环境中运行代码来调度子代理，并递归处理输入上下文的碎片，而不是依赖单次推理或丢失信息的摘要。例如，一个代理需要从10,000个销售通话记录中找出平均交易规模，使用RLM风格，代理将编排和计数放在代码中，而不是模型的临时上下文窗口中。

Deep Agents已实现对RLM的支持，通过动态子代理和轻量级代码解释器。代理可以编写脚本，代码解释器执行它以分派子代理。例如，处理300页文档时，可以使用Promise.all(pages.map(page => task({...})))模式。与论文中的RLM不同，Deep Agents的实现更接近“递归代理”（RA），因为子代理拥有自己的工具和上下文。但论文的启发至关重要。

使用程序化编排有两个主要优势：确定性覆盖（代码保证覆盖所有批次，而不是依赖模型判断）和定制编排（管道可以适应任何形状的任务，包括分支、并行或顺序，而不受模型逐轮能力的限制）。

为了测试，我们在OOLONG基准上进行了评估，该基准要求从大量表格数据中聚合信息。我们使用AgNews数据集，代理需将标题分类并回答计数、用户和时间相关的问题。在64k token长度下，普通代理和RLM代理表现相近（0.58 vs 0.67），但到了128k token，普通代理得分降至0.44，而RLM代理达到0.79。普通代理在长上下文下经常放弃回答，而RLM代理保持稳定。

开始使用Deep Agents的动态子代理需要安装QuickJS中间件并将CodeInterpreterMiddleware传递给create_deep_agent。触发动态子代理的方法是提示中包含“workflow”一词。例如，运行一个工作流来审查文件并总结风险。此外，dcode终端编码代理内置了代码解释器，无需设置即可试用。

RLM让根模型能够自行编写循环来组织上下文。这种思维方式与代理循环、验证循环等概念一致。我们很高兴看到动态子代理和RLM工作流如何让代理自主组织上下文和循环。

进一步阅读包括原始论文、Alex Zhang的博客、Deep Agents视频等。更有兴趣了解代理实际行为的开发者可以尝试LangSmith平台。