大型语言模型正在悄悄进化出一种新能力——它不再只是被动回答问题，而是能像程序员一样，在自己的“思维环境”里写出一段代码，这段代码还能自动调用自己，反复执行复杂任务。
这种能力叫“符号递归”（symbolic recursion），是普通智能体（比如Claude Code、Codex、Terminus等）所不具备的关键差异。
普通智能体虽然也能拆解任务、调用子工具，但所有子任务都必须由主模型一次性规划好，再逐个发出指令；而RLM（Recursive Language Model）却能在内部的REPL（读取-求值-输出循环）环境中动态生成并执行包含递归调用的程序逻辑，比如用for循环或map函数批量处理百万文件，甚至根据条件P动态决定是否发起子调用。
这种设计让RLM更接近真正的编程语言——子调用不是外挂工具，而是语言本身的语法特性，从而在处理高复杂度、高动态性任务时展现出更强的表达力与鲁棒性。
什么是RLM？它和普通AI代理到底差在哪？
想象一下，有一个超级聪明的图书管理员，任务是从一百万本书里找出某一段特定的代码。普通AI代理的做法是：先在脑子里列一张超长清单，把每一本书的名字写下来，然后一本一本地喊：“助手A，去查第1本！助手B，去查第2本！……助手Z999999，去查最后一本！” 这个过程全靠主脑一次性想清楚，中间不能偷懒、不能跳过、不能临时改主意。万一主脑打了个盹，漏掉几本，或者突然发现其实只需要查带“数据库”字样的书，那就得重来一遍——因为所有指令都是提前硬编码好的，没法动态调整。
而RLM的做法完全不同。它不急着摇人，而是先坐下来写一段小程序：“遍历所有文件，如果文件名包含‘db’，就打开它，搜索关键词，结果存到results变量里。” 写完之后，这段程序自动运行，系统自己决定查哪本、跳哪本、怎么存结果。
更神奇的是，这段程序里还能嵌套调用另一个RLM实例——比如在查某本书时，发现里面引用了另一份配置文件，于是程序自动触发一次新的RLM调用去解析那个配置。这种“在代码里调用自己”的能力，就是“符号递归”。它不是靠主模型硬记步骤，而是靠程序逻辑动态生成行为，就像递归函数调用自身一样自然。
为什么“在REPL里调用子模型”比“主模型直接发工具指令”强得多？
关键在于“执行环境”和“控制流”的分离与否。普通AI代理的工具调用机制，本质上是主模型输出一串JSON指令，外部系统再按指令执行。这就像老板给员工发邮件布置任务：“今天做三件事：A、B、C。” 员工做完回邮件，老板再决定下一步。整个流程是线性的、静态的，无法在执行中根据中间结果改变策略。比如，如果做A的时候发现需要先做D，老板就得重新发邮件——但主模型可能根本没意识到这个需求，因为它已经把上下文“固化”成指令了。
而RLM的REPL环境则像一个活的编程沙盒。主模型不是输出指令，而是直接写Python代码（或其他脚本），这段代码在REPL里实时运行。代码可以包含循环、条件判断、变量赋值，甚至函数定义。当代码执行到某一行需要调用子模型时，它不是“发指令”，而是“调用一个函数”——这个函数本身就是另一个RLM实例。于是，整个任务变成了一个可编程的、可组合的计算图。比如，要处理满足条件P的文件，只需写：
python
for file in os.listdir("codebase"):
if satisfies_property_P(file):
result = rlm_subagent(file) # 这里rlm_subagent就是另一个RLM
save_result(result)
这段代码天然支持任意复杂的逻辑分支，而无需主模型预判所有可能性。更重要的是，这种结构可以通过训练被模型内化——模型学会的不是“如何列清单”，而是“如何写程序”，从而具备更强的泛化能力。
从编程语言角度看，普通代理的工具调用为何“有点傻”？
如果把RLM的REPL看作一种新编程语言，那么“子模型调用”就应该是这门语言的一个原生操作符，就像Python里的def或for一样自然。但在Claude Code或Codex这类系统中，子代理调用却被当作外部工具，通过特殊格式的JSON块触发。这就相当于在Python里不能直接写函数调用，而必须先打印一段“请调用add(2,3)”的字符串，再靠外部系统解析执行——不仅啰嗦，还割裂了控制流。
这种设计导致表达能力受限。比如，想实现“对满足条件的文件并行调用子代理”，普通代理只能靠主模型猜测可能有多少文件、手动列出每个调用；而RLM可以直接写map(rlm_subagent, filtered_files)，让系统自动并行化。前者依赖模型的“记忆力”和“规划力”，后者依赖程序的“表达力”和“执行引擎”。显然，后者更接近人类程序员的工作方式——我们写代码，不是靠背诵步骤，而是靠组合逻辑。
符号递归如何解决百万文件搜索这种“脏活累活”？
假设任务是从一百万个代码文件中找一个叫calculate_tax()的函数。普通代理的做法是：主模型尝试在上下文中生成一百万个工具调用，每个对应一个文件。但上下文长度有限，根本塞不下；就算分批处理，也得靠主模型记住哪些查过、哪些没查，极易出错。更糟的是，如果中途发现其实只需要查2024年后的文件，整个计划就得推倒重来。
RLM则轻松得多。它先写一段脚本，用os.walk()遍历目录，用正则过滤年份，再用multiprocessing.Pool并行调用子RLM实例。每个子实例只负责一个文件，结果自动汇总。整个过程不需要主模型记住任何细节——逻辑写在代码里，执行交给系统。即使中途修改条件（比如加个“排除测试文件”），只需改一行代码，重新运行即可。这种“程序即任务”的范式，让复杂任务变得可维护、可调试、可扩展。
为什么说RLM的设计更利于模型训练和推理能力提升？
因为RLM把“任务分解”从“黑箱推理”变成了“白箱编程”。传统模型在内部隐式地拆解任务，但人类无法观察其过程；而RLM通过显式的代码输出，让每一步决策都可追溯。这为训练提供了宝贵信号：模型不仅能从最终答案对错中学习，还能从中间代码的合理性中学习。比如，如果模型写了低效的嵌套循环，可以通过反馈让它学会用向量化操作；如果它错误地调用了子代理，可以教它正确的函数签名。
更重要的是，这种结构天然支持“元认知”——模型可以写代码来监控自己的执行状态，比如记录进度、检测错误、重试失败任务。这种自我调节能力，正是迈向通用人工智能（AGI）的关键一步。当计算机能像人类一样使用计算机——写脚本、调工具、查日志、改bug——它就不再只是问答机器，而成了真正的数字同事。
结语：RLM不是小改进，而是范式跃迁
有人觉得RLM只是“把工具调用放进REPL”而已，没什么大不了。但正如当年函数式编程 vs 面向对象之争，表面是语法差异，实质是思维范式不同。RLM把AI代理从“指令执行者”升级为“程序生成者”，让模型真正掌握“如何思考复杂问题”的方法论。未来，随着训练数据中包含更多此类递归程序，模型将学会更高级的抽象——比如自动生成任务调度器、构建知识图谱、甚至编写自己的训练脚本。这不仅是技术优化，更是通向自主智能的桥梁。
极客一语道破
RLM递归模型 是一种符号形式： x+y=z
Claude Code是一种值内容：1+2=3
内容与形式区别：1+1=2背后的形式化思考