SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness
一句话概括
SoL-Pi 是一套在「智能体外壳」（agent harness）层面做自动化研究的方案：它把自动研究循环递归地扩展到大量、多样的环境中去筛选可复用的改进，最终留下四个机制，在 EdgeBench 的 51 个任务上以与 Pi 相当的表现为代价，把记录的 token 流量降低约 45%–49%、API 成本降低约三分之一。
问题背景
论文关注的对象不是模型本身，而是包裹模型的「外壳」——即负责组织推理、调用工具、处理反馈、管理上下文的那一层工程逻辑。作者指出，编码智能体正在从「有人监督的代码补全」转向「无人值守、全天候的自主探索」。这一转变带来两个直接后果：其一，智能体的工作单元从孤立的单次预测，变成包含推理、工具调用与反馈的长轨迹；其二，token 消耗随轨迹长度快速累积，成为制约「递归自我改进」（RSI）能否规模化的关键瓶颈。
换句话说，当智能体要长时间、反复地自我迭代时，每一轮循环里浪费的 token 都会被递归放大。因此，提升 token 效率不只是省钱问题，而是决定这类循环能否持续扩展的前提。论文的切入点是：与其只优化模型，不如把「外壳」本身当作可被自动搜索和优化的对象。
方法要点
论文采用一种受 RSI 启发的思路，但把尺度放在 harness 层：让自动研究循环在数量越来越多、种类越来越多样的环境中反复运行 harness rollout，用「能否在开发环境之外迁移」作为筛选标准。作者强调，在这种规模下，过程会产生可复用的改进，而不再只是针对单一场景的过拟合技巧。
经过选择后，有四个机制存活下来，构成 SoL-Pi，分别覆盖四个环节：
- 动作执行（action execution）：智能体实际调用工具、执行操作的方式；
- 上下文压缩（context compaction）：对不断增长的对话与推理历史做压缩，控制上下文体积；
- 观测处理（observation handling）：如何接收、裁剪和利用环境返回的观测；
- 委托阅读（delegated reading）：把部分阅读/检索工作委派出去，而非全部塞进主上下文。
这四个方向合起来指向同一个目标：在保持任务表现的前提下，减少无效的 token 往返。摘要没有给出每个机制的具体实现细节与消融数据，因此无法判断四者各自的贡献占比。
关键结论（仅基于摘要可合理推断的部分；不确定处标明「摘要未给出」）
在 51 个任务的 EdgeBench 评测上，SoL-Pi 的表现与 Pi 相当（分别在 GPT-5.6 Sol 与 Opus 5 上对比），同时：
- 记录的 token 流量下降 44.7%–49.0%；
- API 成本下降约 三分之一；
- 相对原生 Codex 与 Claude Code harness，估计每小时节省 $8.75–$13.50；
- 相对 Pi，估计每小时节省 $4.36–$5.71。
需要说明的是：摘要只给出「表现相当」（comparable），未给出具体分数或统计显著性；「每小时节省」是估计值，其计算口径（按何种调用量、何种定价）摘要未给出；EdgeBench 的任务构成、评测协议、基线配置等细节摘要未给出；四个机制各自的消融结果摘要未给出。
读后思考 / 适用场景
这篇工作的价值主张不在「更聪明的模型」，而在「更省的外壳」。如果结论成立，它意味着 harness 层的优化空间可能被长期低估：同样的模型、同样的任务，仅靠重组动作执行、上下文压缩、观测处理与阅读委派，就能砍掉近一半 token 流量。对于需要长时间自主运行、按 token 计费的生产场景——例如持续集成中的自动修复、长周期代码库维护、无人值守的探索型 agent——这类改进的边际收益会随运行时长放大。
另一个值得注意的点是「可迁移性」作为筛选标准。自动搜索很容易产出只对特定环境有效的补丁，而作者把「在开发环境之外仍然有效」当作选择压力，这更接近工程上真正需要的泛化，而非 benchmark 上的过拟合。这也解释了为什么最终只留下四个机制：能被保留的，是那些跨环境反复被验证的通用结构。
局限与开放问题
首先，摘要中所有效率数字都来自 EdgeBench 这一单一评测集，且仅覆盖 51 个任务；它在其他任务分布、其他模型、其他工具生态下是否同样成立，摘要未给出。其次，「表现相当」缺乏量化定义——是持平、略降还是略升，无法从摘要判断，而这直接关系到效率提升是否以能力为代价。第三，成本节省是「估计」值，依赖具体的定价与调用模式假设，实际部署中的节省幅度可能不同。
更根本的开放问题是：这四个机制是 harness 优化的终点，还是当前搜索规模下的阶段性产物？如果继续扩大环境数量与多样性，是否会出现新的、可迁移的机制，甚至反过来改变我们对「外壳应该做什么」的理解？此外，论文把 RSI 的思路用在 harness 层，但 harness 的改进本身是否也能被递归地用于改进搜索过程，摘要未给出线索。最后，token 效率与任务成功率之间的权衡曲线如何，以及在长轨迹后期压缩上下文是否会损失关键信息，都是需要正文实验来回答的问题。