PredictRLM：让大模型自己操控子模型的生产级 AI 运行时

2026 年 3 月，一篇来自 MIT CSAIL 的论文在社交网络上被大量转发——作者 Alex L. Zhang、Tim Kraska 和 Omar Khattab（DSPy 的原作者）提出了一种全新的 LLM 调用范式：递归语言模型（Recursive Language Model, RLM）。三个月后，Trampoline AI 将这一理念落地为开源项目 predict-rlm，仅靠 README 和几行代码，就登上了 GitHub Trending。

这个项目解决了一个困扰 AI 工程师许久的问题：当任务需要模型反复调用工具、子模型或外部服务时，传统 Agent 的上下文会不断膨胀，最终导致模型"宕机"——上下文腐败（Context Rot）。

背景：从"手写提示"到"自我驾驭"

理解 RLM 之前，需要先了解它的前身——Harness（测试框架）。

传统 Agent 框架（如 LangChain Agent、AutoGPT）像一个包揽一切的秘书：模型接收用户指令后，一边思考、一边调用工具、一边生成回复，所有操作都在同一个上下文窗口内完成。这种方式的问题在于：随着任务推进，上下文不断累积，模型需要同时处理"原始任务""中间结果""工具调用"等混杂信息，容易出现指令退化（Instruction Degeneration）和上下文腐败——模型开始重复操作、忘记目标，甚至输出错误结论。

Harness 尝试用"分离"来解决：把主模型（Root Model）放在外层，只负责任务规划；把具体执行（子模型调用）交给子模块。但这种分离是机械的——主模型仍然需要按照预定义的循环结构反复调用子模块，无法根据中间结果动态调整策略。

RLM 提出了一个更优雅的方案：让 Root Model 真正"自己决定"何时调用、如何调用子模型。模型不再被动执行预定义循环，而是像人类专家一样，写一段小程序（Python 代码）在沙箱中执行，通过 predict() 调用子模型，完成后自主决定下一步——继续探索、修正错误、或直接提交结果。这个过程完全可解释：用户可以看到模型写出的每一行代码、每一次 predict 调用、每一个中间输出。

核心原理：沙箱 + REPL + DSPy Signature

PredictRLM 的执行流程可以概括为五个步骤：

1. 定义 Signature：用户通过 DSPy Signature 描述任务输入、输出和策略（如 question -> answer）
2. Root Model 编写 Python 代码：在沙箱（默认 Deno/Pyodide WASM 虚拟机）中，Root Model 根据任务写一段 Python 代码
3. predict() 调用子模型：代码中调用 predict(signature, **kwargs)，触发子模型完成特定子任务（如图像理解、PDF 解析）
4. REPL 迭代循环：代码执行结果反馈给 Root Model，它决定是继续探索、修正错误还是提交结果
5. SUBMIT() 输出最终结果：当 Root Model 认为任务完成，调用 SUBMIT() 提交结构化输出

这个设计的精妙之处在于：上下文控制权完全在 Root Model 手中。子模型调用通过 predict() 完成，Root Model 只看到最终结果，不需要处理中间过程的 token 消耗。这意味着即使用户要求模型处理 100 万 token 的文档，Root Model 的上下文始终保持在舒适范围内。

架构设计：多后端沙箱体系

PredictRLM 支持三种执行后端，后端之间共享相同的协议契约，但执行环境不同：

后端	执行环境	传输方式	状态持久性	适用场景
JSPI（默认）	Deno 进程 + Pyodide WASM 虚拟机	stdio JSON-RPC	Pyodide VM 内存	通用场景、跨平台
Direct	本地 CPython 子进程 + JSON-RPC Server	stdio JSON-RPC	CPython Kernel 内存	本地开发调试
SBX	Docker Sandboxes 隔离容器	WebSocket JSON-RPC	CPython Kernel 内存	生产环境隔离

每个后端都遵循Supervisor 协议：一个长期存活的管理进程负责接收 execute 请求、执行用户代码、处理超时、返回结果。在 JSPI 模式下，Supervisor 是 Deno 进程中的 JavaScript 桥接层；在 SBX/Direct 模式下，Supervisor 是一个独立的 Python 进程。

超时恢复机制是架构亮点：协作式超时（Cooperative Timeout）时，Supervisor 发送 SIGINT，内核保留完整 REPL 状态并返回 state.preserved=true；硬超时或崩溃时，Supervisor 杀掉并重启 Kernel，恢复预超时快照（仅保留基础 Python 对象），并告知模型哪些全局变量丢失。这种设计保证了即使单次执行失败，整个任务仍然可以继续。

图1：Harness 模式（主模型被动循环调用子模块）vs RLM 模式（主模型自主写代码控制子模型调用）

图2：从手写提示词到 RLM 的演进——RLM 性能随模型能力提升而自动提升，不受人工提示工程限制

技术栈与核心依赖

PredictRLM 的技术选型非常克制：

• Python >= 3.11：最低支持 3.11，充分利用结构化联合类型（|）
• DSPy >= 3.2.1：签名定义和模块化是核心依赖
• Deno >= 2：默认 JSPI 后端的运行时（轻量、无需安装额外依赖）
• Pydantic >= 2.8.2：结构化输出验证和类型安全
• Tenacity：重试机制，应对子模型调用的临时故障
• Nest-Asyncio：解决 Python 异步嵌套执行问题

可选依赖组：

• [gepa]：RLM-GEPA 优化框架，基于执行轨迹自动优化 Skill 指令
• [codex-lm]：Codex-backed DSPy LM，提供 Claude/Codex 等模型的统一接口
• [sbx]：Docker Sandboxes 支持（需要 sbx CLI 和 Docker Desktop）

Skills 机制：可组合的能力扩展

PredictRLM 用 Skill 来扩展沙箱能力。一个 Skill 包含四个维度：

• instructions：字符串指令，告诉模型如何执行某个任务（如"用 pymupdf 打开 PDF，以 200 DPI 渲染页面"）
• packages：PyPI 包列表，安装后在沙箱中可用（如 pymupdf、openpyxl）
• modules：自定义 Python 模块，直接 import 到沙箱命名空间
• tools：DSPy 工具函数

内置 Skills 包括 pdf（PDF 解析与渲染）、spreadsheet（Excel 操作与公式验证）等。项目还提供 RLM-GEPA 优化框架：收集执行轨迹（RunTrace），由 GEPA Proposer 分析并生成 Skill 指令的增量修改，实现自动化能力迭代。

Skills 可以组合（自动合并 packages 和 instructions），这意味着一个 RLM 可以同时处理"从 PDF 提取数据 → 写入 Excel → 验证公式"的全流程。

可观测性：每一次调用都透明可见

PredictRLM 对可观测性（Observability）的重视程度远超一般 Agent 框架。

每一次 PredictRLM 调用返回一个 prediction.trace，包含：

• 每次迭代的生成代码（IterationStep.code）
• 代码执行输出（IterationStep.output）
• 所有 predict() 子调用详情（含 token 消耗和耗时）
• 工具调用记录
• 错误和异常信息

同时，默认开启彩色 stderr 输出，人类可以直接阅读执行故事。verbose=False 可静默执行，debug=True 则输出 RLM 和沙箱的生命周期诊断（进程启动、请求、停机）。

项目还支持 Lifecycle Callbacks：继承 dspy.utils.callback.BaseCallback，重写 on_rlm_iteration_start 和 on_rlm_iteration_end，将执行进度广播到 WebSocket、写入结构化日志或接入可观测性管道。回调异常被隔离，不会影响主任务。

局限性与挑战

尽管 PredictRLM 设计优雅，但实际落地仍有挑战：

1. 沙箱限制：Pyodide WASM 环境不支持所有 Python 包（如 numpy、torch），重度数值计算任务受限；SBX 模式虽然支持完整 Python，但需要 Docker。

2. 模型要求高：Root Model 需要足够强才能写出有效的控制代码——它必须理解任务、规划步骤、处理错误。目前主要依赖 GPT-5.4 等顶级闭源模型，开源模型效果参差不齐。

3. 调试成本：RLM 的能力上限取决于模型写出的代码质量——模型写错代码时，排查根因比传统 Agent 更复杂，因为问题可能出在代码逻辑而非提示词。

4. 速度成本：每次子模型调用都经过 predict() → HTTP → 子模型 → 返回的完整链路，延迟高于直接在 Root Model 中嵌入 Few-shot 示例。

行业意义与未来展望

PredictRLM 的出现代表了 AI 工程领域的一个重要转向：从"让模型适配框架"到"让模型自己设计执行方案"。

MIT CSAIL 的论文显示，在相同子模型条件下，RLM(GPT-5-mini) 的表现超越了 base GPT-5——这验证了 RLM 架构对 Token 效率的显著提升。伴随着 GEPA 优化框架的成熟，Skill 指令的自动化迭代将进一步降低 RLM 的工程门槛。

从更长远的视角看，RLM 模式可能是通往 AGI"分层推理" 的一条路径：顶级模型负责任务分解和策略生成，具体执行由专用子模型完成——正好对应了人类专家团队的工作方式。

PredictRLM 目前处于 Alpha 阶段（v0.7.0），API 尚未稳定，但鉴于 MIT + Trampoline AI 的学术工程双重背书，以及 DSPy 生态的既有用户基础，它有潜力成为 AI Agent 时代的基础设施级项目。