SoL-Pi：让 AI 自己研究怎么给自己省钱，token 账单砍掉近一半
你有没有算过一笔账：一个 coding agent 跑一整天无人值守的任务，光 API 账单就要烧掉多少钱？我之前跑 overnight 的 agent 实验时，最肉疼的不是 GPU，而是那一行行往上滚的 token 计费——模型每多轮一次对话，上下文就膨胀一圈，cache read 像雪球一样越滚越大。
这篇 arXiv 2609.20519 的论文给了一个挺有意思的答案：不动模型，只动 harness——也就是夹在模型和环境之间的那层"胶水代码"。更妙的是，这层胶水不是人手写的，而是让 AI 自己跑了几千次自动研究循环"搜"出来的。
核心摘要
SoL-Pi 是 NVIDIA、NTU、MIT 联合团队（Song Han、Enze Xie 等参与）提出的 agent harness 优化方案。痛点很实在：coding agent 从单次补全进化到全天候自主探索后，token 效率成了一阶成本问题。方案很"递归"：用 RSI 思路，在 152 个提议方向、535 个可执行环境里跑了 3000+ 次自动研究循环，最后只有四个机制活过了筛选——分别管动作执行、上下文压缩、观测处理和委托阅读。效果很能打：在 51 任务的 EdgeBench 上，性能与基线 harness Pi 相当的同时，token 流量砍掉 44.7%–49.0%，API 成本降约三分之一，折算每小时省 \(4.36–\)13.50。我的判断：这不是底层突破，但它是把"自动发现系统工程优化"这条路走通的一个扎实样本，而且消融和隔离设计做得比大多数同类工作诚实。
📖 论文信息
- 标题：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
- 发表：2026 年 9 月 17 日，arXiv:2609.20519
- 链接：https://arxiv.org/abs/2609.20519 ｜ 代码：https://github.com/NVlabs/SoL-Pi
🎯 为什么需要这篇论文？
先厘清一个概念。Agent harness 就是智能体的"外壳"：决定什么时候调模型、上下文怎么拼、工具结果怎么回传、什么时候压缩历史。Codex、Claude Code、OpenCode 这些都是 harness 产品。
现有的降本路子基本都在别处下功夫：更快的 attention kernel、量化、换小模型。这些都对，但有个共同的盲区——它们假设 harness 是固定的。可实际跑过 agent 的人都知道，一个设计粗糙的 harness 能干出多离谱的事：改完文件再单独发一条命令跑测试（多一次往返），一个 50KB 的编译日志在接下来十轮对话里被原封不动地重复发送，上下文快爆了才想起来压缩……
问题是，人工优化 harness 极其痛苦。工具调用、上下文管理、委派、恢复这些环节是紧耦合的，你在这里省了点 token，可能在那里引入了一个隐蔽的失败模式。靠人盯轨迹找规律，不可扩展。
作者的想法顺势就出来了：既然 harness 是一堆代码和策略，而 coding agent 恰好擅长改代码——那让 agent 自己研究自己的 harness 不就行了？这其实就是 RSI（递归自我改进）的一个务实版本：不改进模型权重，改进模型的"工作环境"。
图 1：上半部分是 SoL-Pi 的自动研究循环——从公开仓库和 AutoLoop 开放环境构建多样化研究环境，Research AI 观察执行轨迹后提出想法进入 idea pool，经过性能与成本两道门控后保留的机制合并冻结为 SoL-Pi harness；下半部分是 held-out EdgeBench 结果，相对 Codex 和 Claude Code 分别省下 50.0% 和 54.3% 的 API 成本。
🧠 方法：152 个想法进，4 个机制出
整个搜索过程是一个漏斗。说实话，漏斗的淘汰率相当残忍——152 个提议方向，覆盖上下文、进度、工具、委派、提示策略、改进评估六大家族，在 495 个仓库衍生环境（GitHub issue + 修复前仓库状态 + 离线依赖）加 40 个合成验证器任务上跑，最后活下来的只有 4 个。
真正让我对这篇论文加分的是它的隔离设计，三条原则值得单独说：
- 广度与深度分离：外层广撒网，内层对每个候选跑标准的 autoresearch 循环（提议→实现→跑实验→审查→保留/丢弃），还引入了独立的实现者和审查者角色。
- 独立验证：held-out 的 EdgeBench 只在候选冻结后才用，结果绝不回流到搜索。验证失败就是拒绝，不给你"针对性修补"的机会。这一条直接回应了此前研究发现的痛点——进化出来的 harness 容易过拟合搜索时用的任务。
- 一次性谱系：每次搜索实例用完即弃，失败不会跨候选传染。
过了两道门控（能力指标不降 + 至少一项效率指标改善）之后，只保留 Pareto 前沿上的非支配结果。最终存活的四个机制，看图最直观：
图 2：四个存活机制的示意图。(a) Action Fusion 把"编辑文件+跑命令"合并成一次工具调用，3 次 API 调用变 2 次；(b) Online Context Compact 在计划步骤完成处设成本门控，上下文增长从 1.9 倍压到 0.75 倍；(c) ObservationPack 对超过 10 KB 的工具结果，前两次请求发全文，第三次起换成稳定句柄加 1 KB 摘录；(d) Evidence-Preserving Reducer 用小模型从构建日志提取证据收据，确定性验证器把关后才交给主智能体。
(a) Action Fusion：少一次往返就是省一轮上下文
基线 Pi 的习惯是：编辑文件 → 等模型下一轮 → 再发命令跑测试。Action Fusion 把变更和后续命令合成一个工具请求，单个观测返回两个结果。API 调用从 3 降到 2。
别小看这一轮往返。省掉的不只是这次调用本身，而是这次调用会携带的整个膨胀后的上下文。当然边界也划得清楚：需要先看到变更结果才能决定下一步的命令，不许硬融。
(b) Online Context Compact：压缩也要算账
传统的上下文压缩是"快爆了才压"。这个机制换个思路：智能体本来就在用 update_plan 维护计划，那就在每个计划步骤完成时算一笔账——根据已完成步骤的请求速率和剩余步骤数，估计剩余请求量，再比较"预计的输入节省"和"重写 prompt cache 的成本"。划算才压，不划算就继续扛。
有个细节挺聪明：后续每次压缩都要把之前没收回的重写成本累计计入，所以越到后面压缩的门槛越高。这避免了"压缩上瘾"导致的 cache 反复重写。
(c) ObservationPack：大输出别一直带着走
超过 10 KiB 的工具结果会被本地归档，前两个请求照常发全文（因为短期内大概率还有用），从第三个请求起替换成稳定句柄加首尾摘录（约 1 KB）。真需要原文？拿句柄按需分页检索。
这个设计背后的观察很朴素：一个大日志的相关性衰减得很快，但 harness 默认会把它带进每一次后续请求里。
(d) Evidence-Preserving Reducer：让小模型先读日志
这是四个机制里最"重"的一个。对超过 4 KiB 的构建/测试日志：归档原文 → 让低成本模型（GPT-5.6 Luna）提取关键证据成一张紧凑"收据" → 确定性验证器检查收据的 schema、源哈希、退出状态、精确引用。验证不过、疑似涉及凭据、或者收据根本没变小——一律回退原始日志。
职责划分得干净：小模型只负责"读"，诊断和决策权还在主智能体手里。它和 ObservationPack 还有协作——reducer 先处理，ObservationPack 认出收据标记就跳过，不做二次压缩。
📊 实验：数字说话
主战场是 EdgeBench（开源的 51 个任务，其中 11 个用于冻结前单向接受测试，40 个留给最终评估）。价格统一按 2026 年 8 月 17 日的 API 定价算。
主表：EdgeBench（GPT-5.6 Sol 后端）
| Harness | Total Token (B)↓ | 成本 ($)↓ | 平均分↑ | Token 效率 ($/score)↓ |
|---|---|---|---|---|
| Codex | 3.0537 | 1,787 | 34.738 | 1.0086 |
| OpenSquilla | 1.3353 | 1,243 | 24.506 | 0.9945 |
| Oh-My-Pi | 2.2235 | 1,832 | 26.921 | 1.3347 |
| OpenCode | 2.5668 | 3,422 | 29.552 | 2.2704 |
| Oh-My-Opencode | 2.5825 | 2,678 | 38.523 | 1.3633 |
| Pi | 2.1538 | 1,339 | 44.833 | 0.5855 |
| SoL-Pi [Efficiency] | 1.0990 | 894 | 42.003 | 0.4174 |
| SoL-Pi [Performance] | 2.0224 | 1,271 | 47.208 | 0.5280 |
几个点值得展开：
- Efficiency 工作点（完整四机制栈）相对 Pi：token 少 49.0%，成本少 33.2%，分数保留 93.7%（42.0 vs 44.8）。分数掉了 2.8 分，这是真实代价，作者没有藏。
- Performance 工作点（GPT-5.6 Sol 下只上 ObservationPack）反而把分数推到 47.2，比 Pi 高 5.3%，token 还少了 6.1%。一个省 token 的机制把性能也抬了——大概率是因为上下文干净了，模型不被过期的大日志干扰。
- 看 OpenCode 那行：token 比 Codex 少，成本却接近两倍（$3,422 vs $1,787）。这是 cache 利用率差导致的，说明只看 token 总量会误判，全任务成本才是真相。
跨模型迁移：GPT-5.6 Sol 上开发，Opus 5 上零适配直接用
| Harness（Opus 5） | Total Token (B)↓ | 成本 ($)↓ | 平均分↑ |
|---|---|---|---|
| Claude Code | 2.0045 | 2,535 | 43.689 |
| Pi | 2.3697 | 1,741 | 44.756 |
| SoL-Pi [Efficiency] | 1.3101 | 1,158 | 42.224 |
| SoL-Pi [Performance] | 2.1016 | 1,605 | 50.482 |
这是全文我最在意的一张表。harness 只在 GPT-5.6 Sol 的轨迹上优化过，搬到 Opus 5 上不做任何适配：token 减 44.7%，成本降 33.5%，分数保留 94.3%。更夸张的是 Performance 点（Opus 5 下只上 Action Fusion）拿了 50.482 分，超过所有基线。
不过这里有个诚实的细节：Opus 5 下各机制的触发率和触发强度都更低——毕竟机制是按 GPT-5.6 Sol 的行为模式调出来的。作者自己也承认这一点，并把它列为"多后端训练"的未来方向。这种不藏拙的写法我挺欣赏。
消融：每个组件单独都能打（EdgeBench，GPT-5.6 Sol）
| 配置 | Total Token (B)↓ | 成本 ($)↓ | 平均分↑ |
|---|---|---|---|
| Pi Baseline | 2.1538 | 1,339 | 44.833 |
| + Action Fusion | 1.8968 | 1,235 | 46.664 |
| + Online Context Compact | 1.2881 | 935 | 41.993 |
| + Evidence-Preserving Reducer | 1.9375 | 1,200 | 44.630 |
| + ObservationPack | 2.0224 | 1,271 | 47.208 |
| SoL-Pi 全栈 | 1.0990 | 894 | 42.003 |
单拎出来看：Online Context Compact 是省钱主力（单机制就把 token 砍了 40%），但分数掉得也最多（42.0 vs 44.8）；ObservationPack 是保分主力。全栈的成本最低但不是各项都最优——组合不是简单的叠加，ObservationPack 在全栈里变得更"挑剔"了，因为它和 Reducer 在观测密集的轨迹上功能有重叠。
还有个反直觉的发现：压缩上下文会减少 prompt cache 重用（cache read 从 2.13B 降到 1.06B，cache write 反而翻倍），乍看是亏的，但算上总账还是从 $1,339 降到 $894。盯着缓存命中率优化是个陷阱，端到端成本才是对的指标。
加分实验：Terminal-Bench 4、IMO 2026 和 agent 群体
- Terminal-Bench 4（63 个 CPU 任务）：SoL-Pi 解决 15 题（Pi 和 Codex 各 18 题），但总成本比 Pi 低 26.3%（$211.12 vs $286.45）。少解决 3 题换 26% 的成本，这笔账划不划算见仁见智。
- IMO 2026（6 道 Lean 4 形式化证明题）：SoL-Pi 过 3 题（Codex 过 5 题），但单题成本最低，$20.90。这里 Codex 解题数更高，值得注意。
- Agent 群体 kernel 优化：20 个 worker 两小时优化 kernel，SoL-Pi 群体跑到 1,127 个周期（越低越好）且花费 $60.11，Pi 群体只到 1,366 周期还花了 $82.12——同样的预算，高效的 harness 转化成了更深的集体探索。这个实验挺有意思，它暗示了效率的"复利"：harness 省钱，省下的钱能买更多搜索。
🤔 我的判断
亮点在哪：
一是定位务实。RSI 这个词被太多科幻叙事绑架了，这篇论文把它落地成"用自动研究循环搜 harness 优化"，不碰权重，不搞自指，出来的东西今天就能用。二是方法论干净。搜索集和评估集严格隔离、冻结协议、Pareto 前沿筛选、held-out 绝不回流——这套设计直接对着"harness 过拟合搜索任务"这个已知痛点打。三是诚实。"搜索规模不构成 scaling law"、"合并行为对比只是描述性的"、Opus 5 上触发率下降，这些限定都写在明处。
问题在哪：
说实话，四个机制单看都不惊艳。合并工具调用、大输出归档、成本门控压缩、小模型读日志——每一个都是工程老手的直觉清单里有的东西。这篇论文真正的贡献不是这四个机制本身，而是证明了"自动搜索能找到并验证它们"这个过程可扩展。152 个想法只活 4 个，这个漏斗背后烧掉的算力（3000+ 次运行、60,000+ 次交互）也不便宜——搜索成本本身没有详细的总账，这是个缺憾。另外 EdgeBench 上 Efficiency 点掉的那 2.8 分、TB4 上少解的 3 题，提醒我们 token 砍掉一半不是免费的午餐，只是代价在可接受范围内。
对工程的启发：
如果你在做 agent 产品，这篇论文里至少有现成可抄的部分：ObservationPack 的大输出句柄化、build log 的小模型收据加确定性校验，这两个机制不依赖任何搜索框架，今天就能在自己的 harness 里实现。而"用成本门控决定什么时候压缩上下文"这个思路，比市面上"到阈值就压"的做法精细得多。
更深一层的启发是：当 token 成本成为一阶约束，harness 就该像编译器优化一样被系统地自动搜索，而不是靠工程师拍脑袋调。这篇论文可能只是这个方向的第一步，但方向感是对的。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我