AI Agent

SoL-Pi：让编码智能体先学会“少花 Token”——NVIDIA、MIT、NTU 的递归自动研究框架

yiwan-cat2026-09-20 19:20

当编码智能体从一次补全几行代码，走向连续数小时甚至数天的自主工作，真正昂贵的往往不只是模型本身，而是不断重放的上下文、重复的工具调用、冗长日志和低效的验证链路。SoL-Pi 的思路很直接：既然 AI 已经可以改代码，为什么不让它反过来研究并改进承载自己的 Agent Harness？

图 1：SoL-Pi 通过自动研究发现更高 Token 效率的智能体 Harness

一、这篇论文为什么值得看？

今天讨论 Agent 成本，很多人首先想到三件事：换更便宜的模型、压缩模型，或者优化推理引擎。但在长轨迹编码任务里，还有一类浪费发生在模型之外：

文件修改后，模型再发起一次测试命令，中间白白增加一次推理往返；
几万字的工具输出在后续请求里被反复重放，即使真正有用的只有头尾几行；
已完成的子任务长期留在上下文中，缓存读取量越滚越大；
为定位一个错误，前沿大模型亲自通读整份构建日志，而真正决定下一步的证据可能只有几条。

这些问题都属于 Agent Harness：它位于大模型与文件系统、Shell、测试器等环境之间，决定模型能看到什么、能调用什么工具、历史如何组织、结果如何反馈。换句话说，同一个模型装进不同 Harness，可能产生完全不同的任务质量、Token 流量和调用成本。

SoL-Pi 的价值不只是提出四个省 Token 的技巧。更重要的是，它把 Harness 优化从“工程师凭经验调参数”改造成一条可扩展的自动研究流水线：AI 观察轨迹、提出机制、修改 Harness、执行验证、保留有效方案，再把通过筛选的机制带入下一轮研究。

论文在 51 个公开 EdgeBench 任务上报告：相较 Pi，完整 SoL-Pi 在 GPT-5.6 Sol 与 Opus 5 两种后端上将记录到的 Token 流量降低 44.7%–49.0%，API 成本降低约三分之一，同时维持相近任务表现。按论文采用的 2026 年 8 月 17 日 API 等价价格估算，一名持续工作的研究者每小时相较原生 Codex / Claude Code 可节省 8.75–13.50 美元，相较 Pi 可节省 4.36–5.71 美元。

但先别急着把它理解成“成本砍半、能力完全不掉”。论文实际上提供了两个工作点：

Efficiency 模式：四种机制全部启用，追求最低 Token 与成本，平均分会有一定下降；
Performance 模式：选择最适合当前模型的单项机制，在减少 Token 的同时提高平均分。

这个区分很重要：SoL-Pi 证明的不是“任何情况下免费提速”，而是 Harness 层存在一条可以被系统搜索的“质量—成本”前沿。

二、SoL-Pi 到底在研究什么？

传统 Auto-Research 往往让 Agent 围绕某个具体任务循环：提出改动、跑实验、看分数、继续修改。问题是，如果直接在少数 benchmark 任务上进化 Harness，Agent 很容易学到只对这些题有效的策略；一旦换仓库、换模型、换任务，收益可能消失。

SoL-Pi 把研究过程设计成“广度搜索 + 深度打磨”的漏斗：

从基础 Harness 的真实执行轨迹中寻找重复劳动；
生成 152 个候选研究方向，覆盖上下文、进度控制、工具、委派、提示策略和评估机制六类问题；
每个方向进入相互隔离的研究分支，独立经历实现、审查和开发集验证；
先检查能力是否处于预设容差，再检查是否改善至少一项效率指标；
将通过筛选的机制冻结后，才进入完全隔离的 held-out 测试。

图 2：开发反馈与 held-out 评测严格隔离

这里最关键的不是循环本身，而是“冻结边界”。开发过程可以不断看验证结果、反复修正；但候选方案一旦冻结，held-out 结果不能再回流给搜索过程。失败就是淘汰，而不是根据测试题继续打补丁。

为了给自动研究提供足够多样的环境，作者构建了 535 个可执行环境：

495 个仓库任务：来自 GitHub Issue—Pull Request 对，使用修复前的仓库状态，并以隐藏回归测试验证“修复前失败、修复后通过”；
40 个验证器驱动任务：先定义可执行成功标准，再允许 Agent 用不同路径完成任务。

整个搜索覆盖约 150 个方向、约 500 个环境，累计超过 3,000 次运行和 60,000 次 Agent—环境交互。作者也明确提醒：这些数字说明搜索规模，并不构成已经验证的 Scaling Law。

图 3：两类搜索环境与 EdgeBench 隔离

三、152 个想法，最后为什么只留下四个？

SoL-Pi 不是把所有“看起来能省 Token”的招数都塞进系统。每个机制必须先满足能力不明显退化，再证明效率提升，并经过独立审查和可执行验证。最终只有四个机制进入完整 Harness，它们分别作用在一次 Agent 运行的不同位置。

图 4：四种机制分别优化动作、上下文、观测和日志阅读

1. Action Fusion：把“修改 + 验证”合成一次动作

编码 Agent 常见的节奏是：

模型决定修改文件
→ 调用编辑工具
→ 模型读取编辑结果
→ 决定运行测试
→ 调用 Shell
→ 模型读取测试结果

如果修改后的验证命令本来就可以预判，中间那次模型往返并没有产生新的决策价值。Action Fusion 在文件修改工具中增加可选的 then_run，让“编辑 / 写入 + 后续命令”在一次工具请求里完成，再把两个结果作为一个 observation 返回。

它不是无条件批处理。若下一条命令依赖模型先检查修改结果，仍然维持分开的动作。这个边界使它减少的是可预测往返，而不是砍掉必要推理。

论文对 Action Fusion 的开发过程做了完整追踪：最初只靠提示词诱导模型主动合并动作，触发并不稳定；之后 Agent 进一步修改工具 Schema，显式暴露融合能力，才形成可可靠调用的接口。整条研究分支经历了 27 次记录迭代，并把“触发率”发展成除任务分数之外的中间指标。

2. Online Context Compact：不是“越早压缩越好”

上下文压缩会减少后续输入，但也会打断已经建立的 Prompt Cache 前缀，并产生重写缓存的成本。因此，简单规定“达到固定 Token 数就压缩”未必最省钱。

Online Context Compact 选择在计划步骤完成时重新评估：根据已完成步骤之间实际消耗的请求数、剩余步骤数和上下文增长速度，估算后续还能省下多少输入；再把潜在节省与缓存重写代价比较。只有预计收益大于成本，或上下文已接近窗口上限时，才调用 Pi 原生的压缩机制。

这实际上把“什么时候压缩上下文”从静态阈值问题，变成了一个在线经济决策问题。

3. ObservationPack：大结果先完整看两次，之后改用句柄

工具返回的大段文本会被写进对话历史，之后每次模型调用都可能重新携带。ObservationPack 对超过 10 KiB 的结果做本地归档：

前两次模型请求仍发送完整结果，保证 Agent 有机会建立正确理解；
从第三次请求开始，只保留稳定句柄、原始大小和约 1 KB 的首尾完整行摘录；
如果后面确实需要细节，Agent 可以用句柄按页精确取回原文；
小结果保持原样，不额外增加管理成本。

它和粗暴截断最大的区别，是原始证据并没有消失，只是从“每轮重复支付”变成“需要时再取回”。

4. Evidence-Preserving Reducer：可以压日志，但必须证明没编造

构建日志和测试日志往往很长，却只含少量关键错误。Evidence-Preserving Reducer 对特定命令产生、长度至少 4 KiB 的日志启用低成本模型压缩；文件读取和搜索结果不会进入这条路径。

真正有意思的是它的验证设计。小模型生成的不是自由摘要，而是一张结构化“证据回执”。确定性验证器会检查：

Schema 是否合法；
源内容哈希是否对应；
退出状态是否保留；
每一处引用能否在原日志中逐字找到；
压缩后是否真的更小。

只要验证失败、疑似包含凭据，或者没有产生尺寸收益，系统就回退到原始日志。辅助模型只负责提取证据，最终诊断与行动决策仍由主 Agent 完成。

这条机制揭示了一个值得复用的工程原则：Agent 可以用小模型压缩信息，但不能把“相信摘要”当成安全边界；关键证据必须能由确定性程序回查。

四、实验结果：省 Token 的同时，到底牺牲了多少能力？

1. EdgeBench：效率模式与性能模式是两种不同选择

EdgeBench 当前公开 51 个长轨迹可执行任务。SoL-Pi 将其中 11 个仅用于对冻结候选做单向验收，其余 40 个用于最终泛化评测；这些输出不进入研发循环。

核心结果如下：

后端与配置	总 Token 流量（B）	API 成本（美元）	平均分	相较同后端 Pi 的解释
GPT-5.6 Sol + Pi	2.1538	1,339	44.833	基线
GPT-5.6 Sol + SoL-Pi Efficiency	1.0990	894	42.003	Token -49.0%，成本 -33.2%，保留 93.7% 平均分
GPT-5.6 Sol + SoL-Pi Performance	2.0224	1,271	47.208	平均分 +5.3%，Token -6.1%
Opus 5 + Pi	2.3697	1,741	44.756	基线
Opus 5 + SoL-Pi Efficiency	1.3101	1,158	42.224	Token -44.7%，成本 -33.5%，保留 94.3% 平均分
Opus 5 + SoL-Pi Performance	2.1016	1,605	50.482	平均分 +12.8%，同时减少 Token

一个容易被宣传数字遮住的事实是：完整四机制栈追求极致效率时，平均分从约 44.8 降至约 42.0；“性能不掉”更准确的表述应是处于同一能力区间、但存在约 5%–6% 的点估计下降。另一方面，按模型选择单项机制，则可以找到分数更高、Token 仍更少的性能点。

2. 跨模型迁移：搜索只看 GPT-5.6 Sol，Opus 5 仍有效

SoL-Pi 的机制是在 GPT-5.6 Sol 轨迹上搜索和更新的，迁移到 Opus 5 时没有再次搜索或适配。四种机制在 Opus 5 上的触发率和触发强度整体更低，但只要触发，每项配置都能改善对应任务的 Token 效率。

图 5：不同后端上的触发率、触发强度与 Token 效率收益（对应论文 Fig. 6，来源：论文原图）

这说明机制确实具有一定跨模型可迁移性，但作者使用“初步证据”而不是“彻底解决泛化”。论文的局限部分也明确提出，未来需要用多种后端共同训练和验证 Harness。

3. 四种机制不是简单相加，而是会互相改变触发条件

完整栈中，ObservationPack 的触发变得更谨慎，因为部分长日志已被 Evidence-Preserving Reducer 提前压缩。与此同时，在各机制实际触发的任务子集上，完整栈的 Token 效率收益都高于单机制配置。

图 6：独立机制与完整栈的触发和效率对比

作者把这解释为“与互补性一致”，但没有把它说成严格的因果证明，因为不同配置比较的是各自触发的任务子集，不能完全隔离交互效应。这种克制是合理的。

4. 不只 EdgeBench：Terminal-Bench、IMO 与 Agent Swarm

在 63 个仅 CPU 的 Terminal-Bench 4 任务上，Codex 和 Pi 均解出 18 个，SoL-Pi 解出 15 个；但 SoL-Pi 相较 Pi 总成本下降 26.3%，单个已解任务成本下降 11.6%。这再次说明它的 Efficiency 点不是无损优化。

在 6 道 IMO 2026 形式化题目上，SoL-Pi 与 Pi 都通过 3 题，但 SoL-Pi 总成本更低；Codex 通过 5 题，能力更高，但总成本也更高。

作者还构建了 20 个 worker 的内核优化 Agent Swarm。在相同两小时预算下：

单 Codex Agent：最终 1,333 cycles，成本 39.20 美元；
Pi Swarm：最终 1,366 cycles，成本 82.12 美元；
SoL-Pi Swarm：最终 1,127 cycles，成本 60.11 美元。

SoL-Pi Swarm 相较 Pi Swarm 成本下降 26.8%，并得到更优结果；但单 Agent 仍是成本最低的方案。也就是说，论文支持的是“高效 Harness 能改善多 Agent 集群的预算利用率”，而不是“多 Agent 天生更省钱”。

图 7：Agent Swarm 架构与两小时搜索结果

五、这篇论文真正新在哪里？

如果只看四个机制，Action Fusion 像批处理，ObservationPack 像外部记忆，Context Compact 像动态压缩，Reducer 像可验证摘要；每一项都不是凭空出现的新概念。

SoL-Pi 的研究增量主要在三个层面。

第一，把 Harness 视为可以“预训练”的系统对象。模型从多样数据中学到可迁移能力，Harness 也可以从大量异构环境和执行轨迹中学习可复用机制。作者把这一长期方向称为 pretraining the harness。

第二，搜索目标从单纯任务分数扩展为受能力约束的效率优化。候选方案不能靠少做验证、提前停止或隐藏证据来省 Token；能力容差和效率指标在实验前固定，并与优化 Agent 隔离。

第三，效率提升可以反过来扩大下一轮自动研究规模。更省 Token 的 Harness 会降低每次研究运行的成本，使固定预算覆盖更多环境、轨迹和候选想法；这些额外研究又可能发现更高效的 Harness。作者称之为 recursive efficient improvement。不过论文明确指出，这还是未来愿景，并未证明成本会持续复利下降。

图 8：Action Fusion 从轨迹观察、接口稳定到 held-out 验证的完整研究分支

六、开源版 Quick Start：先从两项本地机制开始

SoL-Pi 已由 NVIDIA 以 MIT License 开源，但它不是 Pi 官方发行版，而是安装在未修改 Pi 之上的独立扩展。当前 README 指定的运行前提是 Node.js 22.19 或更新版本、npm，以及 @earendil-works/pi-coding-agent 0.85.1。

安装命令如下：

npm install --global @earendil-works/pi-coding-agent@0.85.1
pi install git:github.com/NVlabs/SoL-Pi

如果只想在当前项目中启用：

pi install git:github.com/NVlabs/SoL-Pi --local --approve

官方建议先启用不增加模型调用、也不会中止当前运行的两项本地机制：

{
  "version": 1,
  "actionFusion": true,
  "observationPack": true,
  "evidencePreservingReducer": false,
  "onlineContextCompact": false,
  "cacheWriteReadRatio": 12.5
}

配置文件优先读取受信任项目中的 .pi/sol-pi.json，否则读取 ~/.pi/agent/sol-pi.json；两份配置不会合并。所有机制默认关闭，必须显式选择。

这里尤其要注意 Evidence-Preserving Reducer：它可能把符合条件的诊断日志发送给配置的小模型。对于必须完全留在本地的日志，不应启用远程压缩。ObservationPack 和 Reducer 的归档会保存在会话目录下，也不会在会话结束时自动删除，生产环境需要自行制定敏感信息与清理策略。

七、适合谁，不适合谁？

SoL-Pi 最适合以下场景：

编码 Agent 单次任务持续较久，工具调用和日志占比高；
团队已经使用 Pi，并希望在不改底层模型的前提下降低调用成本；
需要保留原始证据，不能接受不可追溯的粗暴摘要；
正在设计多 Agent 研究或软件工程系统，希望把 Harness 作为可优化对象。

它并不适合被直接理解成通用的“成本减半插件”：

短任务上下文本来很小，四种机制未必有足够触发空间；
Efficiency 模式可能牺牲部分任务分数；
当前自动研究主要基于 GPT-5.6 Sol 轨迹，跨更多模型的稳定性仍待验证；
搜索过程本身昂贵，论文没有给出广度、深度与收益之间的严格 Scaling Law；
开源实现依赖特定 Pi 版本，升级前需要检查兼容性。

八、如果把 SoL-Pi 用到自己的 Agent 系统，我会怎么做？

我不会一上来就复制四个模块，而会先复用它的方法论：

建立任务级账本：同时统计任务成功率、输入、缓存读写、输出、工具调用次数和总成本，避免只盯单轮 Token。
收集长轨迹中的重复劳动：哪些动作总是成对出现？哪些 observation 被重复发送？哪些日志只有少数行真正被引用？
先做可确定验证的机制：例如编辑后测试融合、超长输出外部化，以及对摘要中引用内容做逐字回查。
预先写死能力底线：效率优化不能通过少跑测试、隐藏错误或提前终止来“作弊”。
将开发环境与最终评测隔离：候选一旦接触 held-out 结果，就不能再回到搜索环节修补。
最后才做自动搜索：当指标、环境、回退与验证链路都可靠后，再扩大候选机制和并行研究规模。

对于真实团队而言，这可能比直接追求“让 Agent 自己改自己”更重要：没有可信的验证器和隔离边界，递归自改进很容易退化成递归过拟合。

九、总结

SoL-Pi 把一个经常被忽略的问题摆到了台前：长轨迹 Agent 的效率，不只由模型和推理服务决定，也由 Harness 如何组织动作、上下文、观测与证据决定。

它用大规模自动研究从 152 个候选方向中筛出四种可组合机制，并在 EdgeBench 上将 Token 流量降低 44.7%–49.0%、API 成本降低约三分之一。更值得关注的是，其研究流程把能力约束、效率目标、环境多样性和 held-out 隔离放在同一套系统中，让“Agent 优化 Agent”不再只是一个漂亮概念，而开始接近可审计、可复现的工程研究方法。

当然，这还不是 Harness 的 Scaling Law，也没有证明递归效率会自动产生复利。但它给出了一条很清晰的路线：下一代 Agent 系统的竞争，可能不只是更强的基础模型，还包括一套能够从海量轨迹中持续发现更好工作方式的 Harness。

资料链接

论文：SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness
项目主页：NVIDIA Research — SoL-Pi
开源仓库：NVlabs/SoL-Pi
EdgeBench：edge-bench.org

版本说明：本文核验对象为 arXiv v1（2026-09-17 提交）及 2026-09-20 可见的官方项目与仓库文档。论文中的 API 成本采用作者声明的 2026-08-17 价格快照，未来价格变化会影响绝对金额，但不改变论文记录的 Token 流量。