Recursive Agent Harnesses：将代码优先的 Agent 递归推向长上下文推理

  • 关联论文：2606.13643
  • 作者：Tom
  • 更新：2026-07-22

一句话结论

RAH 将递归 LLM（RLM）中"模型调用递归"拓展为"完整 Agent harness 递归"——父 Agent 生成并运行可执行脚本，脚本内并行 spawn 子 Agent harness，在 Oolong-Synthetic 上以 GPT-5 为 backbone 将基线从 71.75% 提升至 81.36%，用更强的 backbone（Claude Sonnet 4.5）更进一步达到 89.77%。

解决什么真问题

长上下文推理（long-context reasoning）是当前 LLM 能力的一个关键瓶颈：当上下文长度超过一定阈值（ often 128K–1M tokens）后，模型性能普遍下降，且计算成本急剧上升。

两条独立的研究路线试图解决这个问题：

  1. Recursive Language Models（RLM）：通过在模型调用层面实现递归——让 LLM 生成"继续思考"的特殊 token，触发下一轮模型调用，形成链式递归。核心递归单元是单个模型调用（无工具）。
  2. 生产级 Coding Agent（如 Anthropic Claude 的 Workflows）：在代码中直接 spawn 子 agent 处理子任务，递归粒度是完整 Agent（含工具）。

这两条路线在各自的维度上有效，但存在一个中间地带未被充分研究：如果递归单元不是"裸模型调用"也不是"完整应用层 Agent"，而是"具备文件系统、代码执行和规划能力的 Agent harness"，效果如何？

RAH 正是对这一问题的系统性命名与研究。

核心方法

概念命名：Harness Recursion

论文将 RLM 的"模型调用递归"扩展为harness recursion——其递归单元是一个完整的 Agent harness，包含：

  • 文件系统工具（读/写文件）
  • 代码执行工具（运行脚本、获取输出）
  • 规划能力（子目标分解、任务调度）

父 Agent 生成一个可执行脚本，该脚本负责在运行时动态创建和调度子 Agent harness：

Parent Agent
  ↓ 生成
Executable Script (spawns sub-harnesses in parallel)
  ↓
Sub-harness 1 (fine-grained sub-task A)
Sub-harness 2 (fine-grained sub-task B)
  ↓ results
Parent Agent (aggregates + continues)

与 RLM 的关键区别

维度 RLM RAH
递归单元 单个 LLM call（无工具） 完整 Agent harness（含工具）
并行化 主要链式 主要并行（parallel sub-harnesses）
粒度 模型调用级 工作流级（workload-level）
适用任务 长链推理（逻辑链） 多路并行推理（分支探索）

工作负载分配策略

RAH 的设计哲学是：让父 Agent 做高层次的规划与合成，子 harness 做细粒度的执行。

  • 小而多的子任务：通过结构化 function calling 分配给子 harness；
  • 大而独立的并行任务：spawn 多个子 harness 实例并行处理，利用硬件并行性；
  • 结果汇总：子 harness 的输出由父 Agent 汇总，形成最终答案。

关键实验与数据

评测基准：Oolong-Synthetic（199 samples，13 个 context-length bucket，最高至 4M tokens）

评测设置：backbone 模型固定，公平比较 harness 设计本身带来的增益。

Backbone Baseline RAH Gain
GPT-5 71.75% 81.36% +9.61 pp
Claude Sonnet 4.5 原文未给出基线 89.77% —

关键claim：增益完全来自 harness 设计本身，而非来自更强的基础模型（backbone 在所有配置中保持一致）。

⚠️ 原文未明确：Oolong-Synthetic 的具体任务类型（是 synthetic 推理还是真实长文档 QA？）、Claude Sonnet 4.5 的 baseline 数字、以及 RAH 在其他标准 benchmarks（如 RULER、InfiniteBench）上的结果。

亮点与局限

亮点

  1. 概念创新：首次命名并系统研究了"harness recursion"这一中间粒度——它填补了"模型调用递归"与"应用层 Agent 递归"之间的空白；
  2. 实验控制严谨：明确将模型能力与 harness 设计解耦，证明了 harness 本身的价值；
  3. 揭示了 scaling 方向：在更强的 backbone（Claude Sonnet 4.5）上，RAH 设计依然有效，表明该架构具有可扩展性；
  4. 并行化优势明确：多路并行 harness 的设计对 GPU 利用率和延迟都有正向价值。

局限

  1. 评测范围有限：仅在 Oolong-Synthetic 一个 synthetic benchmark 上验证，缺乏在真实长上下文任务（如长文档问答、代码库分析）上的结果；
  2. 子 harness 之间的协调机制未深入：当子 harness 的结果相互冲突时，父 Agent 如何裁决？论文未充分讨论；
  3. 开销分析缺失：并行 spawn 多个 harness 的计算开销是否值得？论文未与串行方案做 cost-performance 权衡分析；
  4. 通用性待验证：RAH 在 coding agent 场景优势明显，但对于非代码类任务（如纯文本推理）的适用性尚未充分探索；
  5. 归属问题：Oolong 基准由本文提出，官方数字由 RAH 论文给出，存在一定自评风险，需独立复现。

对工程落地的启发

适合哪些团队：

  • 正在构建复杂代码生成/分析 Agent（如自动化测试生成、代码审查、PR 分析）的团队；
  • 需要处理超长上下文（>1M tokens）的 agent 系统开发者；
  • 关注多路并行推理以降低延迟的在线服务团队。

可借鉴的设计思路：

  1. 父子分工的 Agent 架构：父 Agent 专注高层规划，子 Agent 专注细粒度执行，这是复杂任务分解的自然延伸；
  2. Harness 作为一等公民：不只考虑"用哪个 LLM"，而是考虑"用哪个 harness 配置"——工具集、执行环境的差异对性能有显著影响；
  3. Synthetic benchmark 的价值：Oolong-Synthetic 通过控制 context length buckets，系统性地揭示了长上下文场景下的问题分布，这套方法论值得借鉴。

待验证的工程假设：

  • 子 harness 数量 vs. 任务质量的拐点（多少个并行 harness 是最优的）；
  • 不同工具集配置（有无代码执行、有无文件访问）对 harness 递归效果的影响；
  • RAH 在生产环境中的延迟和成本是否可接受。

与同方向工作的关系

工作 与 RAH 的关系
Recursive Language Models (RLM) RAH 将 RLM 的"model recursion"扩展为"harness recursion"，是后者的代码优先版本
Anthropic Claude Workflows 同样是生产级 agent 递归，但 RAH 提供了系统性的框架和分析
Code Agent (Claude Agent, GPT Agent) RAH 在这些系统的基础上研究了 sub-agent 并行化问题
Long-context LLMs (Gemini, GPT-4o) RAH 提供了一种在模型能力受限情况下的工程解决方案， orthogonal to 模型侧的长上下文优化
Tree-of-Thought (ToT) ToT 通过显式树结构探索解空间，RAH 通过 harness 递归实现类似的探索能力，但机制不同

适合谁读

  • Agent 系统工程师：正在设计复杂多步任务的多层分解方案，RAH 提供了父子 harness 分工的具体框架；
  • LLM 推理效率研究者：关注如何在不无限扩展上下文窗口的前提下提升超长任务性能；
  • Coding Agent 开发者：Anthropic/Claude Workflows 的用户或竞品开发者，理解 RAH 有助于更好地设计 sub-agent 架构；
  • Benchmark 设计者：Oolong-Synthetic 的设计方法论（context-length bucketing）值得参考。

前置知识：需要熟悉 LLM Agent 的基本架构（工具调用、ReAct）、Recursive Language Models 的基本概念、以及长上下文推理的主要挑战。

工程落地与核查（Jay）

事实核查

  1. "Claude Sonnet 4.5"模型名称存疑：Anthropic 历史上最新正式版 Sonnet 为 Claude 3.5 Sonnet（2024 年中），并无"Claude Sonnet 4.5"正式发布。若原文如此，此处为 AI 幻觉或未公开的预发布版本，引用时须注明"⚠️ 模型名称待核实"。
  2. GPT-5 名称存疑：截至 2026 年中，OpenAI 正式发布的 GPT 系列为 GPT-4o / GPT-4o-mini，"GPT-5"尚未正式发布。若原文如此，需标注"⚠️ 基座模型名称待核实，可能是内测代号"。
  3. Oolong-Synthetic benchmark 任务类型未披露：原文仅给出样本数和 bucket 分布，具体任务是 synthetic 推理题还是真实长文档 QA 尚不明确，影响对实验结论泛化性的判断。
  4. Claude Sonnet 4.5 baseline 缺失：89.77% 的绝对值在无 baseline 对照的情况下无法判断提升幅度，⚠️ 原文未给出该模型的 baseline 数字（原文用"原文未给出基线"标注，已诚实）。

实际系统怎么用

实现 RAH 的最小可行架构（基于论文描述推断）：

User Query / Long Document
  → Parent Agent（规划 + 脚本生成）
      → Sub-Harness Pool（并行执行）
          → Harness A：文件系统读 + 代码执行
          → Harness B：文件系统读 + 代码执行
          → Harness C：代码执行 + 结果汇总
      → Parent Agent（结果合成 + 响应）

工程框架选择： - OpenAI Agents SDK：handoffs API 支持子 Agent 并行 spawn，适合快速复现； - LangGraph：更细粒度的状态机控制，适合复杂协调逻辑； - 自定义 Python orchestration：最灵活，需自行处理进程管理、超时、和上下文注入。

核心依赖： - LLM API（支持 function calling / tool use）； - 代码执行沙箱（Docker container 或 VM isolation，防止恶意脚本）； - 文件系统隔离（子 harness 只能访问授权路径）； - 并发任务队列（Celery / asyncio + ThreadPoolExecutor）。

坑在哪

坑 1：上下文窗口污染 父 Agent 生成的可执行脚本本身占用上下文 token 数，当子 harness 数量增加时，脚本体积也增加。若用 JSON / Python 脚本作为媒介，需限制脚本最大行数（建议 ≤200 行）。

坑 2：子 harness 结果冲突无自动裁决 当多个子 harness 返回矛盾结论时（如代码分析的两个 harness 对同一个 bug 给出不同解释），父 Agent 需要有能力判断而非简单投票。论文未给出具体机制，这是生产部署的最大空白。

坑 3：并行度的资源非线性 并行 spawn N 个 harness，内存占用约为 N × 单 harness 上下文。4M token 上下文 + 4 个并行 harness = 约 16M token 等效上下文。⚠️ 建议基准测试：2/4/8 个并行 harness 的端到端延迟和 GPU 显存曲线，找到质量-成本拐点。

坑 4：超时与部分失败 子 harness 超时或崩溃时，父 Agent 如何降级？论文未讨论。需要为每个子 harness 设置独立超时（建议 30s-2min），并设计 fallback 策略（用父 Agent 自身的结果或仅用已返回的结果继续）。

坑 5：沙箱安全 子 harness 执行用户提供的代码存在安全风险。必须用 Docker 或 gVisor 隔离运行环境，限制网络访问、文件系统写权限和进程数。

坑 6：成本不可控 并行 harness 的成本是串行的 N 倍。若子 harness 之间有重复计算（如都加载相同上下文），可用向量数据库预先过滤或使用 KV cache 复用。

评估结论

RAH 框架的工程可行性中等偏高（基于现有 Agent 框架可快速复现），但核心挑战在于子 harness 协调机制缺失（生产环境最大风险）和开销-质量权衡未量化（采购决策缺乏数据支撑）。建议先在代码审查 / PR 分析两个场景做 POC，监控并行 harness 数量 vs. 准确率曲线，再决定是否扩展到其他任务类型。