SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness作者Haozhe Liu, Tian Ye, Sensen Gao, Qihang Cao, Yitong Li, Mingchen Zhuge, Duomin Wang, Ruihua Zhang, Ping Luo, Jiawang Bian, Lei Zhu, Ligeng Zhu, Enze Xie, Song Han核心发表机构NVIDIA、NTU、MIT论文链接arXiv:2609.20519v1发布于arXiv 预印本cs.AI二、研究背景与动机 / Background Motivation论文的出发点是一个正在发生的范式转变编码智能体从受监督的代码补全走向无人值守、全天候探索其工作形态也从孤立的预测扩展为包含推理、工具使用与反馈的长轨迹。一旦任务从一次补全变成持续数小时甚至更久地与环境交互累积的交互历史、反复发送的观测、重复的模型往返就会让 token 消耗成为主导成本项。论文点名自主研究、软件工程智能体、自演化个人助手、早期形式的递归自我改进RSI等场景认为在这些场景里task-level token efficiency 已经是一等的系统问题。已有降低 token 成本的努力大致分布在三个层面一是降低每 token 的单价例如更快的 attention kernel 与推理服务基础设施FlashAttention、vLLM二是模型压缩例如量化SmoothQuant、GPTQ三是调用更便宜的模型例如 FrugalGPT、RouteLLM。作者明确把自己的路线与这三类区分开本文优化的是agent harness即模型与环境之间的中介层不需要额外训练模型因此与基础设施层、模型层的方案互补而不是替代。但 harness 优化本身很困难。工具调用、上下文管理、验证、委托、恢复、终止这些环节紧密耦合一处局部有益的改动可能在下游引发失败或者把 token 成本从流程的一个阶段转移到另一个阶段。人工做这件事需要检视长执行轨迹、识别反复出现的失败模式、再把认识翻译成代码改动成本高且难以跨任务、跨环境规模化。这正是自动研究的动机。在自动改进 harness这条线上已经有两类代表性工作。Meta-Harness 在可执行的 harness 程序空间上搜索并评估其对 held-out 数据集与模型的迁移RHIRecursive Harness Self-Improvement针对单个任务迭代精炼 agent loop 的 prompt 级规范。更重要的是论文引用了一项使用 held-out 任务的否定性证据演化出来的 harness 会过拟合搜索期任务在未见任务上只有边际收益。这个已知失效模式直接塑造了 SoL-Pi 的核心设计约束——搜索反馈与最终评估必须明确分离目标是发现真正可迁移的效率改进而不是把验证失败打补丁成任务特化解。由此论文提出三条设计原则。第一是breadth and depth广度用于扩大假设覆盖深度用于对候选反复实现、评审与加固。第二是independent validationheld-out 证据只在候选冻结之后才评估且永不回流搜索防止优化过程把验证失败消化成任务特化补丁。第三是scalable orchestration隔离的、可丢弃的 lineage 让漏斗可以跨更多想法与更多环境扩张同时失败不会在候选之间耦合。|—|| Action Fusion | action execution动作执行 || Online Context Compact | context management上下文管理 || ObservationPack | observation storage观测存储 || Evidence-Preserving Reducer | delegated reading委托式阅读 |图 4 说明四个机制在 agent–environment loop 中作用于不同位置灰色为基线流量绿色为机制路径与节省红色为超额成本或验证失败。下面逐个展开。Action Fusion动作执行。动因是 base Pi 常常先编辑文件再单独发一条命令去测试、构建或运行它这中间多了一次模型往返。Action Fusion 把两个动作合并为一个 tool request并在同一条 observation 中返回两者结果从而消除中间的模型往返图注给出的具体效果是把 API 调用从 3 次降为 2 次。边界也很明确需要检查 mutation 结果的命令仍然保持分开执行。Online Context Compact上下文压缩。它关注的不是是否压缩而是何时压缩。agent 通过update_plan维护计划harness 在每个 plan-step 完成边界重新考虑压缩首先根据已完成步骤之间观测到的请求数与未完成步骤数估计剩余模型请求数然后用按观测增长率填满当前上下文窗口所需的请求数对该估计设上限接着用**成本门cost gate**比较 projected input savings 与重写 prompt cache 的估计额外成本后续压缩还要额外计入未回收的 rewrite 成本并要求更大的节省 margin。当成本门通过或上下文使用量接近窗口上限且压缩确实能缩短上下文时harness 调用 Pi 的原生 compaction。门的实现从上下文大小与 cache-write / read 价格比估计 cache-rewrite 开销作者也承认这是一个近似——它不单独为 summarization 调用定价。ObservationPack观测存储。动因是大工具输出即使后续相关性很低仍会在之后的请求中反复出现。做法是本地归档超过阈值10 KiB 10\ \text{KiB}10KiB的结果在接下来 2 个 provider request 中仍完整发送从第 3 个请求起替换为稳定的 handle 原始大小 头尾完整行的短摘录agent 可通过 handle 按需取回精确分页exact pages较小结果保持不变。这是一种延迟降级 可恢复的观测生命周期管理。Evidence-Preserving Reducer委托式阅读LUNA-EPDR。它作用于来自预定义命令集的、至少4 KiB 4\ \text{KiB}4KiB的 build / test 日志而文件读取与搜索结果明确绕过 reducer。流程是harness 归档精确输出请更低成本的模型实现中使用 GPT-5.6 Luna 的high档把关键证据抽取成紧凑receipt再由确定性验证器检查 receipt 的 schema、source hash、exit status、exact quotes 与 size。只要出现验证失败、怀疑凭证泄露或 receipt 未带来任何大小缩减就回退到原始日志。它与 ObservationPack 有顺序与互锁关系Reducer先于ObservationPack 处理工具结果ObservationPack 识别 reducer 的 receipt marker 并跳过这些结果以保留已验证证据。职责划分也很清楚辅助模型只做证据抽取主 agent 仍保有诊断与动作选择的责任。四个机制在流程中协同编辑代码时Action Fusion 把编辑与后续命令合并环境返回输出时Evidence-Preserving Reducer 从 build/test 日志抽取已验证证据ObservationPack 避免反复完整发送大结果agent 完成一个 plan step 时Online Context Compact 判断压缩累积上下文是否省 token。作者认为这些机制针对互补的开销来源最终通过端到端评估验证联合效应。在实现层面四个机制都作为 Pi 的扩展实现Action Fusion 给文件 mutation 工具增加可选的 follow-up command把两个结果放在一条 observation 返回Online Context Compact 在 plan-step completion 时检查 cache-cost gate同时支持接近上下文上限时的压缩ObservationPack 本地归档大输出并提供稳定 handleEvidence-Preserving Reducer 用 GPT-5.6 Lunahigh抽取证据验证 receipt 后才交给主 agent。评估前需要冻结机制源码、配置、指标、能力容差与接受规则全部 EdgeBench 输出保持在搜索循环之外。EdgeBench 的 51 个公开任务中11 个用于对冻结候选做单向接受剩余 40 个保留用于泛化的最终评估。|—|—|—|—|—|—|—|—|—|| EdgeBench official 2h | GPT-5.5 | — | — | — | — | — | — | 31.2 | — || Codex | GPT-5.6 Sol | 0.0053 | 3.0287 | 0.0145 | 0.0052 | 3.0537 | 1,787 | 34.738 | 1.0086 || OpenSquilla | GPT-5.6 Sol | 0.0001 | 1.2533 | 0.0776 | 0.0044 | 1.3353 | 1,243 | 24.506 | 0.9945 || Oh-My-Pi | GPT-5.6 Sol | 0.1135 | 2.0448 | 0.0484 | 0.0168 | 2.2235 | 1,832 | 26.921 | 1.3347 || OpenCode | GPT-5.6 Sol | 0.0012 | 2.2625 | 0.2865 | 0.0164 | 2.5668 | 3,422 | 29.552 | 2.2704 || Oh-My-Opencode | GPT-5.6 Sol | 0.0044 | 2.4373 | 0.1286 | 0.0121 | 2.5825 | 2,678 | 38.523 | 1.3633 || Pi | GPT-5.6 Sol | 0.0011 | 2.1326 | 0.0141 | 0.0059 | 2.1538 | 1,339 | 44.833 | 0.5855 ||SoL-Pi [Efficiency]| GPT-5.6 Sol | 0.0009 | 1.0605 | 0.0316 | 0.0061 |1.0990|894| 42.003 |0.4174||SoL-Pi [Performance]| GPT-5.6 Sol | 0.0002 | 2.0005 | 0.0160 | 0.0056 | 2.0224 | 1,271 |47.208| 0.5280 |粗体 8 个受测行中的最优破折号 未报告。跨后端迁移是另一个重点。SoL-Pi 使用 GPT-5.6 Sol 开发随后直接应用到 Opus 5不再进一步搜索或适配。在 Opus 5 上SoL-Pi [Efficiency] 的总 token 为1.3101 B 1.3101\text{ B}1.3101B相对 Pi 的2.3697 B 2.3697\text{ B}2.3697B减少约 44.7%token cost 从 $1,741 降到 $1,158减少约 33.5%平均分保留约 94.3%42.224 / 44.756。作为参照Opus 5 上 Claude Code 为 2.0045 B、$2,535、43.689、1.1377。论文把这一结果称为对 unseen LLM backend 迁移的 preliminary evidence。Terminal-Bench 4 与 IMO 2026 用来检验效率增益能否泛化到 EdgeBench 之外。在 Terminal-Bench 4 的 63 个 CPU-only 任务上Codex 解决 18 个、总成本 $272.35、每解决任务 $15.13Pi 解决 18 个、总成本 $286.45、每解决任务 $15.91SoL-Pi 解决 15 个、总成本 $211.12、每解决任务 $14.07。也就是说SoL-Pi 相对 Pi 降低总模型成本 26.3%、降低每解决任务成本 11.6%但解题数少 3 个。在 IMO 2026 上Codex 通过 5/6、总成本 $114.47、每通过问题 $22.89Pi 通过 3/6、总成本 $75.95、每通过问题 $25.32SoL-Pi 通过 3/6、总成本 $62.69、每通过问题 $20.90。SoL-Pi 通过数与 Pi 持平、低于 Codex但总成本与每通过问题成本都是最低。多智能体 kernel 优化实验把 SoL-Pi 放进协调式 agent swarm 中评估。三种配置分别是单个 Codex agentCodex coordinator 20 个 Pi baseline workerCodex coordinator 20 个 SoL-Pi worker使用全部四个机制。single agent 与 coordinator 使用 GPT-5.6 Solxhigh所有 worker 使用 GPT-5.6 Lunaxhigh。两个 swarm 中 worker 分成 5 组、每组 4 人每组有独立 workspace 与 shared evidence boardworker 交换 notes 以复现或结合 promising findingscoordinator 跨组 relay findingsshared best result 只在 coordinator 提交 immutable candidate snapshot、且独立验证确认严格改进时才更新。结果SoL-Pi swarm 达到 1,127 cycles、成本 $60.11Pi baseline swarm 达到 1,366 cycles、成本 $82.12单个 Codex agent 达到 1,333 cycles、成本 $39.20。SoL-Pi swarm 相对 Pi baseline swarm 减少 API 成本 26.8%达到更优的 cycles所有最终候选通过官方 correctness checkSoL-Pi swarm 与 single agent 通过全部 8 个 speed thresholdsPi baseline swarm 通过 7 个、错过最终阈值。论文据此认为更高效的 harness 可以帮助 agent swarm 把固定预算转化为更有效的集体探索。图 5 中(a) 显示 group board 支持局部协作coordinator 跨组分享发现并提交候选供独立验证(b) 中 filled points 表示正确提交候选open circles 表示 accepted commitsstep lines 追踪 best accepted resultcost chart 显示 cumulative API cost。4.3 消融实验 / Ablation Study消融采用 add-one 形式每一行表示在 Pi 基础上加入一个机制最后一行是四个机制的完整组合 SoL-Pi [Efficiency]SoL-Pi [Performance]则是每个后端选出的性能导向单机制配置。表 2 在两个后端下报告结果表注用浅绿色与\dagger标识每个后端被选为 SoL-Pi [Performance] 的配置用深绿色高亮 SoL-Pi [Efficiency]。GPT-5.6 Sol 块配置InputCache R.Cache W.OutputTotalToken CostAvg. ScoreToken Eff.Pi Baseline0.00112.13260.01410.00592.15381,33944.8330.5855 ActionFusion0.00111.87180.01800.00601.89681,23546.6640.5190 OnlineCompact0.00081.26020.02170.00551.288193541.9930.4365 LUNAEPDR0.00511.90890.01810.00551.93751,20044.6300.5274 ObservationPack†0.00022.00050.01600.00562.02241,27147.2080.5280SoL-Pi [Efficiency]0.00091.06050.03160.00611.099089442.0030.4174Opus 5 块配置InputCache R.Cache W.OutputTotalToken CostAvg. ScoreToken Eff.Pi Baseline0.00002.32030.03480.01452.36971,74144.7560.7625 ActionFusion†0.00002.05200.03520.01442.10161,60550.4820.6235 OnlineCompact0.00001.86180.03880.01451.91521,53749.1550.6130 LUNAEPDR0.00001.86850.03150.01311.91311,45643.4050.6578 ObservationPack0.00001.39600.03560.01021.44181,17647.0470.4899SoL-Pi [Efficiency]0.00001.26260.03520.01231.31011,15842.2240.5376消融的主要结论有几点。第一每个组件在两个后端下都降低了总 token 数。第二GPT-5.6 Sol 下 ObservationPack 记录最高平均分 47.208Opus 5 下 Action Fusion 记录最高平均分 50.482——这两个配置正是各自后端被选为 SoL-Pi [Performance] 的单机制。第三完整堆叠 SoL-Pi [Efficiency] 在两个后端块中都具有最低 total token count 与最低 token cost。第四每个单机制配置相对 Pi 都降低了 cost per score pointGPT-5.6 Sol 上 Pi 为 0.5855ActionFusion 0.5190、OnlineCompact 0.4365、LUNAEPDR 0.5274、ObservationPack 0.5280、Efficiency 0.4174Opus 5 上 Pi 为 0.7625ActionFusion 0.6235、OnlineCompact 0.6130、LUNAEPDR 0.6578、ObservationPack 0.4899、Efficiency 0.5376。第五一个诚实的细节是Opus 5 上完整堆叠的 Token Eff.0.5376并不是最低ObservationPack 的 0.4899 更低但完整堆叠的 total token 与 token cost 最低——这说明效率点是按总资源定义的而不是按单位分数的成本定义的。机制行为随后端与配置而变。图 6 从 trigger rate、trigger intensity 与 token-efficiency gain 三个角度展示后端依赖的激活模式Opus 5 下 trigger rate 与 trigger intensity 都更低论文推测原因是 harness 只在 GPT-5.6 Sol 轨迹上优化但 Opus 5 下每个配置在其 triggered tasks 上仍改善 token efficiency完整堆叠在两个后端上保持类似的 aggregate score–efficiency trade-off。图 7 比较每个 standalone 配置与 full stack 的合并行为ObservationPack 在 full stack 中变得更 selective可能与 LUNA-EPDR 在 observation-heavy trajectories 上存在重叠对每个机制而言full stack 在其各自 triggered-task 子集上的 token-efficiency gain 都大于 standalone 配置。论文认为这与机制间互补性一致但明确强调这种比较没有隔离交互效应。源码还专门讨论了 cache reuse 这个容易被误读的成本维度。缩短上下文可能减少 prompt-cache reuse因为它改变了之前已缓存的 prefix但 cached input 也有成本因此在整个任务上保留长 prefix 不一定最便宜。Online Context Compact 与 ObservationPack 用部分 prefix reuse 换取更少的重复输入。在 GPT-5.6 Sol 上完整堆叠把 cache-read traffic 从 2.1326 B 降到 1.0605 Bcache-write traffic 从 0.0141 B 增到 0.0316 B尽管 cache-write 增加总模型成本仍从 $1,339 降到 $894。每个单机制配置在两个后端下也都降低了 cost per score point。论文的结论是应该同时评估完整任务成本与任务质量而不是只看 cache reuse。最后学习过程的案例分析聚焦 Action Fusion 如何从机会走向保留。图 8 记录了横跨 27 iterations 的谱系分四个阶段oracle analysis、baseline construction、prompt and tool-schema optimization、final held-out validation。Stage 03 记录了 18 个 prompt-optimization explorations图中有 10 个 retained steps有些步骤并行评估多个候选只保留每个并行批次中最好的结果。oracle-analysis 面板识别出重复的相邻动作并投影在 full triggering 下可减少 11.5% token因此催生专门的 ActionFusion lineage。baseline construction 阶段发现 prompt-only triggering 不可靠agent 因此扩展 tool schema直接暴露 fused action建立了无 invalid calls 的稳定 baseline。随后在 development tasks 上精炼 prompt 与 schema把 trigger rate 与 task score 并列为中间接受指标最终用这两个指标选择配置、冻结并在 held-out validation 后保留。论文认为这证明了两件事lineage-local auto-research loop 可以稳定机制的接口与触发行为agent 自己引入 trigger rate 说明 auto-research 能发展出机制特定的中间指标与端任务性能一起指导优化。六、局限性与展望 / Limitations Future Work论文在结论中给出四点局限与未来方向值得逐条保留。第一是pre-training the harness。泛化通过 RSI 发现的 harness artifacts 仍是持续挑战本文结果提供了初步证据扩展 auto-research loops 可以缓解该挑战。作者用预训练作类比harness 暴露给许多任务并从产生的轨迹更新。一个假设是同时扩展 executable environments 与 research ideas 的多样性可以带来持续增益。长期方向被命名为 pretraining the harness。第二是multi-backend training。当前 harness 从单一 LLM 生成的轨迹更新在其他评估后端上机制触发更少、更弱尽管触发时仍改善 token efficiency。跨多个后端训练和验证 harness可能提升鲁棒性同时保持任务质量与效率。第三是recursive efficient improvement。效率可能变得递归更高效的 harness 可以降低构建其后继者的 auto-research 成本。作者计划把 SoL-Pi 作为下一轮研究周期的起始 harness更低的 per-run 成本可以让固定预算覆盖更多 executable environments、trajectories 与 research ideas。在这种视角下效率既是 harness 研究的结果也是扩展后续搜索的资源。但作者明确强调这是长期研究愿景不是本研究中展示的 compounding effect。第四是search coverage and cost。在其实验环境中运行完整 auto-research loops 计算昂贵在固定预算下比较搜索广度与深度尤其困难沿这些维度的 scaling laws 是有前景的研究方向留给未来工作。此外从可复核性角度看还有若干需要在阅读时保留的限定搜索计数152 个方向、535 个环境、3000 次运行、60000 次交互只描述搜索范围不构成 scaling lawproposal family 不是实现位置的约束capability 只在固定容差内检查容忍度与指标由搜索 loop 之外定义所有 token 成本基于 2026-08-17 的 API 价格会随时间变化EdgeBench 仅 51/134 任务开源评估受限于公开子集其中 11 个用于冻结候选的单向接受、40 个用于最终泛化评估Online Context Compact 的成本门不单独为 summarization 调用定价这是一个已知近似图 1 的符号化元素是示意性的非真实数据点。源码可见片段也未给出损失函数、优化器、网络结构、完整 auto-research 算法伪代码、候选生成器细节、搜索预算、随机种子、方差或置信区间以及 ActionFusion 之外其他机制的发现谱系。七、总结 / ConclusionSoL-Pi 的核心主张可以概括为一句话在长时、无人值守的编码智能体场景里token 效率是规模化递归自我改进的系统级前提而harness 层是一个可以在不训练模型的前提下被自动搜索的优化面。论文把 harness 改进形式化为跨多样可执行环境的 RSI 式搜索用 broad-to-deep 漏斗在 152 个方向、535 个环境中筛选用能力容差门 效率改善门 非支配保留的双重门控保证候选既有效又不牺牲任务能力并用候选冻结后再做 held-out 评估、结果永不回流的隔离设计直接回应了既有工作中演化 harness 过拟合搜索任务的失败模式。最终存活并组合成 SoL-Pi 的四个机制——Action Fusion、Online Context Compact、ObservationPack、Evidence-Preserving Reducer——分别作用于动作执行、上下文压缩、观测处理与委托阅读共同目标是减少重复工作同时保留后续决策所需的信息。在 EdgeBench 的 51 个任务上SoL-Pi [Efficiency] 相对 Pi 降低 recorded token traffic 44.7–49.0%、降低 API 成本约三分之一同时保留 93.7%GPT-5.6 Sol与 94.3%Opus 5的平均分SoL-Pi [Performance] 则把平均分从 44.833 提到 47.2085.3%同时 token traffic 减少 6.1%、token efficiency 改善 9.8%。跨模型迁移的初步证据、Terminal-Bench 4 与 IMO 2026 上更低的成本、以及 agent swarm 中 26.8% 的 API 成本下降说明这些效率增益并非只在开发环境内成立。与此同时论文对自身的边界相当克制搜索计数不构成 scaling law、hosted 后端上触发更弱、搜索本身计算昂贵、跨后端训练与预训练 harness仍是未完成的长期方向。对于关心长时智能体系统成本的读者这篇工作最值得带走的三点是第一token 效率可以被当作一个独立的、可自动搜索的系统目标而不只是模型或基础设施的副产物第二自动研究的可信度取决于评估隔离——held-out 结果一旦回流搜索效率提升就很可能退化为任务特化第三机制层面的改动合并动作、延迟降级大观测、按计划边界压缩、用带验证的 receipt 替代原始日志虽然朴素但在长轨迹上能叠加出可观且可迁移的成本节省。原文摘要:As coding agents move from supervised code completion to unattended, around-the-clock exploration, their work expands from isolated predictions into long trajectories of reasoning, tool use, and feedback. Token efficiency therefore becomes important for scaling recursive self-improvement. We take an RSI-inspired approach at the harness layer, scaling auto-research loops across increasingly numerous and diverse environments for harness rollouts. At this scale, the process yields reusable improvements that transfer beyond their development setting, moving automated harness discovery toward production-level outcomes. Four mechanisms survive selection and form SoL-Pi, spanning action execution, context compaction, observation handling, and delegated reading. On the 51-task EdgeBench evaluation, SoL-Pi achieves performance comparable to Pi across GPT-5.6 Sol and Opus 5 while reducing recorded token traffic by 44.7-49.0% and API cost by about one third. In other words, estimated hourly savings are $8.75-$13.50 relative to native Codex and Claude Code harnesses, and $4.36-$5.71 relative to Pi.PDF链接:https://arxiv.org/pdf/2609.20519v1部分平台可能图片显示异常请以我的博客内容为准