Recursive Agent Harnesses：当AI学会分身术，长文本推理从71%飙到89%

一个53万token的文档，怎么读？

想象你面前有一份536K token的超长文档，里面散落着1,772个键值对。你的任务是逐一提取每个条目的信息并回答问题。

如果你是一个编程Agent，你会写一个正则表达式脚本，循环匹配所有条目。快是快，但正则只能抓表面——遇到需要推理的条目就傻眼了。

如果你是一个递归语言模型（RLM），你会把文档切成小块，逐块推理。能推理了，但你看不到文件系统，没法用工具。

那如果……每个条目都派一个"分身"去处理呢？每个分身都有完整的工具箱、文件系统和推理能力？这就是Recursive Agent Harness（RAH）的核心思路。

什么是"递归Agent线束"？

先拆解这个名字：

• Harness（线束）：把LLM变成真正能干活的Agent的那套东西——工具、文件系统、上下文工程、编排逻辑。就像汽车线束把发动机、方向盘、仪表盘连成一辆能开的车。
• Recursive（递归）：线束自己能生出线束。父Agent写一段代码，这段代码会为每个子任务启动一个完整的子Agent线束。
• 关键区别：RLM的递归单元是"模型调用"（没有工具），RAH的递归单元是"完整线束"（有工具、有文件系统、有推理能力）。

两种分身模式

RAH的父Agent根据任务规模选择不同的分身策略：

代码执行分身（Code-Execution Spawning）：当条目数量很大时，父Agent写一个可执行脚本，脚本里用Task()函数为每个条目启动一个子Agent，并行运行。就像工厂流水线，一个调度员写好生产指令，每条产线独立运转。

JSON工具调用分身（JSON Tool-Call Spawning）：当只有1-5个条目时，直接用结构化函数调用启动子Agent。就像老板直接口头安排几个任务，不需要写正式文件。

子Agent继承了父Agent的分身能力，可以继续递归分解，直到达到设定的深度限制。

实验结果：线束的胜利

研究团队在Oolong-Synthetic基准上测试了RAH，这个基准专门测长上下文推理，包含199个样本，覆盖1K到4M token的13个上下文长度桶。

为了公平比较，他们固定使用GPT-5作为骨干模型（和Codex基线一致），这样任何差异都只能归因于线束设计而非模型能力：

几个关键发现：

1. 增益来自线束而非模型：同一个GPT-5，从71.75%到81.36%，纯靠架构改进 2. 全长度桶一致提升：包括4M token的超长文档，没有在极端长度上掉链子 3. 编程Agent的瓶颈在推理：正则匹配够快但不够聪明，遇到需要推理的条目就卡住 4. RLM的瓶颈在工具：能推理但看不到文件，就像蒙着眼睛做数学题

为什么这很重要？

RAH揭示了一个被忽视的设计空间：递归单元的选择。

之前大家默认递归=模型调用递归。但当你把递归单元升级为完整线束时，你同时获得了推理能力和工具访问——这是编程Agent和RLM各自缺失的一半。

更重要的是，RAH的分身逻辑是普通程序代码，不是固定的递归调用约定或预定义的工具schema。这意味着父Agent可以用它写代码的同一套语言来参数化并发度、每个条目的指令和输出路径——灵活性远超硬编码的递归框架。

Anthropic的动态工作流（dynamic workflows）已经在生产环境中采用了类似的代码驱动分身模式。RAH的工作是第一次系统地命名、定义和评估这个模式。

诚实评价

RAH不是银弹。它的代价是更高的计算成本和延迟——每个条目都启动一个完整子Agent不便宜。论文也坦承了失败模式：当条目间存在依赖关系时，并行分身可能错过跨条目的推理链。

另外，RAH目前只在Oolong-Synthetic上验证了，这个基准的结构化程度较高（键值对格式），在更开放的长上下文任务上效果如何还需要验证。

但核心洞察是清晰的：在Agent架构中，递归单元的选择和模型选择一样重要。同样的模型，换个递归策略，就能提升近10个百分点——这个信号值得所有做Agent系统的人关注。

---

论文: Recursive Agent Harnesses 作者: Elias Lumer, Sahil Sen, Kevin Paul, Vamse Kumar Subbiah (PwC US) 领域: Multi-Agent Systems, Long-Context Reasoning