大家好。我是雷蒙德·怀特科姆，今天我要讲的是递归编码智能体，这是一个将递归语言模型（RLM）的经验应用于编码智能体的概念。这项工作既源于我独立研究期间的 Raw Works 项目，也来自我最近在 OpenProse 的角色。为了说明这一点，我们都想要结果。我们都希望有代表我们工作的智能体。我们希望有可靠的同事，在我们做有趣的事情、去徒步旅行、悠闲放松或忙碌工作时，他们能把事情办好。

我的观点和经验是，瓶颈不在于智能。模型已经足够智能，它们无所不知，甚至知晓整个互联网。但它们无法可靠地交付结果，因此我无法信任它们。举一个非常简单的例子，有一天，我通过一个提示词（虽然很长）几乎得到了一个完全可用的 SaaS 应用。但第二天，我发誓这真的发生了，Cloud Code 清空了我 Solana 钱包里的所有内容。哎呀。好吧，这确实让人无法产生信任感。

在这里我们可以看到一个进程，我们都希望向右移动，即我们坐在那里冥想，事情就会显现。这来自 AI 工程师代码，实际上出自一件 T 恤的背面，时间是 2025 年 11 月。天哪，我希望那时你们能在那里。如果没去，可以在 YouTube 上看，那太棒了。

论点如下：今天的智能体是管理不善的天才。智能是存在的，缺失的层是如何指定、管理、重用和验证工作。这个“管理不善的天才”的说法来自 MIT 的 Alex Zeng、Z Li 和 Omar Khattab。Alex 和 Omar 也是原始递归语言模型论文的作者之一。我最近也在 Turning Post 上简要讨论过这一点。别忘了，这些幻灯片实际上是一个网站，recursivecodingagents.com，你可以点击访问，里面所有内容都是交互式的。

什么是递归语言模型？我喜欢说，在 RLM 中，上下文本身就是计算的对象。这本质上是工具调用和推理的结合。我们将在下一张幻灯片中详细讨论这一点。想法是，完整的提示词不仅仅是一个简单的用户查询，它是一个变量，可以是一个文件或许多文件。我们有一个代理与之交互的读-评-印循环（REPL）。在原始论文中，那是 Python。

RLM 被指示对该提示词进行符号操作。不要只是把整个东西读入你的上下文窗口，而是以符号方式探索它。更进一步，你甚至不直接进行符号探索，或者只是稍微试探一下，而是让其他 LLM（如果允许递归深度大于 1，则是其他 RLM）——这些递归子代理——进行这种符号操作，以拆解答案，然后逐步回到最终答案。

这看起来像下面这棵树。我的观点是，RLM 是新的推理模型，我认为这是测试时计算（inference time compute）的下一个范式。为什么这看起来显而易见？我认为它非常优雅，因为它是推理和代码执行的完美结合。代码执行就是推理。

我们曾经有作为提示策略的思维链，它演变成了推理模型，明确地将思维链表达为推理令牌。我们已经有函数调用、工具调用、并行工具调用，而 RLM 真正将这些结合在一起，取得了惊人的结果。这里有三个非常简单的例子，一个来自原始论文。RLM 可以处理比其上下文窗口大几个数量级的信息，达到数千万个令牌。

我在独立研究中展示的是，默认的 RLM 框架本身就是一个非常强大的记忆系统。未经修改的 RLM 本质上就像一个排名前 10 的记忆系统，与那些定制记忆系统的人齐名，而后者可能投入了数十亿美元。稍加修改，你就可以用它作为记忆系统获得惊人的结果。

我还展示了最先进的结果，RLM 框架，特别是其 DSPy 实现，在长推理任务上取得了最先进的结果。现在有一个新的基准测试 Long CoT。我不深入细节，但这个基准测试的想法是，问题很难，因为它们需要大量的推理步骤，大多数推理模型，包括顶级的，都无法保持足够的线程。

如果允许 RLM 使用代码和递归调用子代理的组合来解决问题，那么一个非常小的模型 Qwen 3.59B（你可以在笔记本电脑上运行它）实际上可以击败 Opus 和 GPT-5.4 等顶级前沿模型。它们非常强大，强大到可以说在基准测试中过于热门。

左边是一个非常高调的案例，Symbolica 团队有一个名为 Agentica 的 RLM 代理框架。在 Arc AGI-3 发布后的几个小时内，当时所有前沿模型的得分都在 2% 或 3% 左右，Symbolica 团队展示了 30% 多的得分。这太疯狂了，他们在几个小时内就通过 RLM 框架将其彻底超越。

这甚至让 Arc Prize 团队非常不满。他们发了一条我解读为安慰性质的推文。就我目前的理解，情况基本上是说，恭喜你，但你们没有以正确的方式解决问题，我们不喜欢 RLM 框架。所以，你可以拥有这条漂亮的推文，但我们拒绝真正完成 ArcadeGI 评估的私人部分。在我看来，这简直疯了。

在我自己的工作中，以及在 Long COT 基准测试上，我的结果以及来自 MIT 的 Alex 的结果……

RLM的第一作者鼓励，或者说，鼓励排行榜维护者建立一个独立的开源基准测试排行榜。这样，RLM的结果就可以被展示出来，而不会污染排行榜原本“不允许工具调用”的初衷。对此我的看法是，我不在乎。我不在乎它是潜在空间、推理令牌还是代码执行。我只想要结果，我想要能得出这些结果的AI程序。

这听起来可能与其他许多概念相似，所以我制定了一个小评估标准。有一个配套的GitHub仓库供你查看。那么，成为RLM需要什么条件呢？我们需要一个可执行环境，提示词是外部化的，有代码实际调用模型，模型能够选择将问题分解为子调用或子代理，且状态本身保持符号化。显然，普通的LLM、RAG等都不符合这些条件。编码代理、子代理和循环接近了，但还不够。这个标准不是为了挑起争论或吹毛求疵，而是为了解释RLM和递归编码代理的本质。

另一个接近但仍未达标的例子是硬编码的MapReduce。我会将Lambda RLM项目归入此类，它本质上是一种通过λ演算将问题分解为MapReduce的方法，然后在执行MapReduce时进行LLM调用。但LLM或RLM并不决定如何分解问题。我认为这是使其具有“代理原生”特性的关键要素。

那么递归编码代理呢？在我看来，它们看起来是一样的，只是将RLM和LLM替换为代理和子代理。我们拥有的不也是同样的东西吗？是的，确实如此。你可以认为这是一个“哈哈，陷阱问题”，即RLM就是一种编码代理，它已经是递归的。这种说法没错，但并没有推动事情向前发展。我感兴趣的是：如何将RLM的原则应用于编码代理，使其真正对编码代理有用？自2025年10月RLM博客文章发布以来，我一直痴迷于这个问题。

我将展示一些关于递归编码代理的实验。第一个实验很简单，就是将Alex的RLM包封装为命令行工具（CLI）。想法是给我的编码代理提供一个RLM作为工具调用。例如，我们需要筛选1亿令牌的语料库，我直接使用这个工具，然后RLM执行其操作。这很有趣且非常有用，其他人也构建了类似的东西。但我接着想，真正让编码代理完全递归意味着什么？即编码代理的框架调用其自身的确切版本，以及如何实现？

我将此称为Y Pi。Y代表λ演算中的Y组合子。Pi是一个极其出色的编码代理，它极其精简，专门设计为可扩展的。Mario希望你为Pi编写扩展以实现新功能，而不是试图将想法塞入主代理。它是一个极简的核心，你可以按需扩展。最初我想用Pi实现递归编码代理，但无法通过Pi扩展实现，因此不得不分叉它。

很高兴地报告，为了这次演讲，我重新审视了这个问题。现在Pi及其扩展已进化，你可以仅通过纯扩展使其完全递归。我既有纯递归扩展包“Pi Recursive”，也有作为便捷封装的“Y Pi”。这字面意义上是一个递归编码代理，因为Pi调用Pi，Pi调用Pi……你可以设置任意深度。

我想展示该领域其他一些值得注意的项目。首先是Alex RLM的原始实现。DSPY和pi.rlm是我进行基准测试时的首选，正是通过这些工具我获得了这些惊人的基准测试结果。AXE非常有趣，因为它极具代理原生特性。AXS最初是DSPY的TypeScript变体，RLM出现后，他们以允许AXE代理编写整个TypeScript接口给另一个AXE代理的方式实现了它，从而深入递归的兔子洞，这非常酷。

为了展示REPL可以是任何东西，OpenProse的Dan制作了一个Unix RLM。这是纯Bash，环境仅仅是Linux文件系统。这提供了思考RLM可能性的另一个角度。最后，我们将更多谈论OpenProse。作为一种语言，OpenProse实际上允许你将任何编码代理转换为RLM。我将在演讲末尾简要介绍如何实现这一点。OpenProse仓库还包含一个执行框架，它是一个编码代理框架，允许你在底层使用Codex SDK或Cloud Code，并以RLM风格执行这些Prose程序。

Cloud Code是RLM吗？这是被反复问到的问题。博客文章发布当天的原始回答是：不，它不是。这是发布推文当天被问到的第一个问题。它基本上是说：“嘿，这是Cloud Code子代理，对吧？”如果你想深入细节，可以回顾我的评估标准。但可以说，现在它确实是了。Omar评论道：“恭喜Anthropic，现在有了动态工作流，Cloud Code终于成为RLM了。”

那么，什么改变了？我认为通过这个例子可以很好地解释递归编码代理的强大之处以及RLM的本质。动态工作流几周前发布，它使Cloud Code具备递归能力，能够执行这些递归工作流。

鼓励大家阅读一篇名为《A Harness for Every Task》的博客文章。它展示了六种非常强大的工作流模式。显然，你可以实现的模式远不止这些。为了说明这一点，我为 Cloud Code 编写了两个工作流。一个是明确非 RLM 的，类似于硬编码的 MapReduce 工作流；另一个是我认为可以看作是对文件系统进行的深度研究。例如，选择一个句柄，将其分配给一个智能体，让它进行分析，带回发现的结果等。这些都在配套仓库中。

接下来介绍 OpenProse。动态工作流很酷，但它们目前仅在 Claude Code 中可用，而且也不是实现这一目标的唯一方式。如果你不喜欢 Claude Code，或者虽然喜欢但不想使用动态工作流，想要其他方案，这就是 OpenProse 的用武之地。OpenProse 在技术上是一种编程语言，但它不是由计算机编译，而是由你的编码智能体编译。它是一种 Markdown 规范，是逻辑化的英语，你不需要学习任何复杂的语法。

实际上有一个命令 prose write，可以让 Claude Code、Codex、Pi 或你喜欢的其他编码智能体为你编写一个 .prose.md 文件。在这方面，它类似于 Claude Code 中的 ultra code 命令，后者可以决定并为你编写工作流。OpenProse 能够将任何拥有文件系统和子智能体的智能体转化为 RLM。这是一个开源仓库，大家可以去查看。

我还为 Turing Post 撰写了一篇更深入的文章。关于 RLM，我想强调的关键点是，OpenProse 可以显式声明子智能体的工作。我在配套仓库中制作了两个演示用的 .prose.md 文件，如果你想深入研究代码可以查看，但我不打算在幻灯片中进行演示。你可以将问题分解为较小的部分并分配给子智能体，然后在父智能体会话中验证子智能体的工作。

更酷的是，在 OpenProse 中，你可以添加我加入语言的功能，或者添加技能和工具作为显式依赖项。你可以想象一种工作流，其中某些子智能体需要特定的技能来履行其在流程中的角色，或者必须访问特定的 CLI 工具，否则无法运行并完成任务。因此，在 OpenProse 中有一种方法可以将这些作为依赖项连接起来，以确保不仅工作方式符合你的预期，而且子智能体还专门配置了成功完成你所声明任务所需的工具和技能。

那么，实际上能做什么呢？我有两个来自 Cloud Dynamic Workflows 的例子，以及两个来自 OpenProse 仓库的例子。例如“规模迁移”，这是发布帖子的示例；“重构”，这是一个巨大的任务，使用大规模并行智能体群完成，然后将所有内容合并在一起，这非常酷。另一个想法是进入一个目录，然后以递归方式对该目录进行深度研究、深度分析或深度处理。

你可以进行审计、漏洞扫描，或者进行对抗性操作，例如让一个怀疑论智能体或红队智能体组尝试以对抗性或并行方式改进系统。最近我添加的一个非常酷的功能是回到我最初的幻灯片内容。有一天我得到了一个惊人的结果，第二天他们就把我所有的加密货币都交易掉了，幸好金额很小。

那么，我们如何使这些结果更可靠？我们有一个“黄金会话”和美好的一天，现在我们想捕获它并反复使用。因此，我构建了一个系统，你可以从 Cloud Code、Codex、Pi 等获取黄金会话。它是一个 Prose 程序，实际上会让智能体解构该会话并将其转化为可重用的 Prose 工作流。这再次涉及递归编码智能体的概念，以帮助你以可靠的方式反复达到那种卓越的性能状态。

递归式编码智能体万岁。我真的认为这非常强大。RLM 刚出现时简直让我大开眼界。正如你可能通过这场演讲看到的，我完全痴迷于将 RLM 的理念应用于编码智能体。我希望你们从这次演讲中带走三点：第一，信任即可靠性。我们如何信任一个不可靠的事物？

我的论点以及“管理不善的天才”这一概念是，下一步不是更多的原始智能，而是行为层面的，实际上是编排。我个人认为，RLM 代表了测试时计算、推理时计算的新范式，其中工具调用和推理是统一的。我们通过工具调用进行推理，并且可以递归迭代。其中一个工具是调用另一个智能体去执行某些特定任务或问题子集。

此外，我希望我们能平息一些关于“LLM 真的是新的吗？它们难道只是编码智能体吗？”的争论。编码智能体可以是 LLM，但它们并不自动就是 LLM。我展示了几种不同的 Claude Code 动态工作流，可以将 Claude Code 转化为 LLM，以及一些使用 OpenProse 的方法，你可以将其与任何编码智能体一起使用。

我认为这是一种与编码智能体协作的极其强大的方式。希望大家深入研究 recursivecodingagents.com。但是，能力越大，责任越大。因此，下次见，请负责任地递归。非常感谢。