NVIDIA 开源 SoL-Pi：让 Coding Agent 每小时省 13 美元，活照干
这次不是又套一层壳，NVIDIA 把"为什么能省钱"写进了论文里。
先说一个我自己用得上的数字：一个专业研究者对着同一个问题跑 Agent，SoL-Pi 相比原生的 Codex 和 Claude Code，每小时能省 8.75 到 13.50 美元；相比它依附的 Pi，每小时省 4.36 到 5.71 美元。这是 NVIDIA 官方博客给出的口径，按官方 API 等价价格折算，区间上下浮动取决于你用的是哪个模型后端。
听起来像常规的"优化提示词"套路？不是。SoL-Pi 真正有意思的地方在于它怎么来的——NVIDIA 让 Agent 自己去研究"怎么让 Agent 更省钱"，跑了 152 个候选想法，最后只有 4 个活了下来。它开源的不只是一个省钱的工具，还有那套筛选方法本身。
我把仓库 README、论文摘要、配置文档和博客都读了一遍，下面按"它想解决什么 → 4 个机制分别改了什么 → 省钱的坐标系 → 怎么装怎么配 → 什么时候别用"的顺序讲清楚。
项目速览
| 项目 | 信息 |
|---|---|
| 仓库 | NVlabs/SoL-Pi |
| 创建时间 | 2026-09-02 |
| Star / Fork | 3490 / 282 |
| 语言 | TypeScript |
| 许可证 | MIT |
| 出品方 | NVIDIA（NVlabs） |
| 依赖基础 | Pi（earendil-works/pi），官方扩展，非官方发行版 |
| 论文 | arXiv 2609.20519 |
| 主页 | https://nvlabs.github.io/SoL-Pi/ |
| 最新动态 | 2026-10-14 发布 SoL-Pi Skill 示例；2026-10-13 发布 Blender 3D 重建示例 |
本文提纲
- 反常识的起点：在追求 RSI 之前，先让 AI 更省钱
- 152 个想法，为什么只活下来 4 个
- 四个机制拆开看：它们分别改了 harness 的哪一段
- 把省钱的数据放进坐标系
- 上手：装一个、写一个 JSON
- 什么时候别用：失效边界与代价
反常识的起点：在追求 RSI 之前，先让 AI 更省钱
这几年 Agent 的叙事一路向上：从补全几行代码，到跨仓库解决问题、根据反馈自己迭代，再到成千上万个 Agent 连续无人值守跑上一周。但 NVIDIA 在博客里问了一个往下走的问题：
在一次持续数小时甚至数天的无人监督运行里，每一个 token 都在把工作往前推吗？还是说，冗余会随着轨迹变长而不断累积？
这个问题之所以关键，是因为它和递归自我改进（RSI）直接相关。当 AI 能改复杂的软件系统，它就能改"造 AI 的那些系统"。但 RSI 本身就是个吃 token 的无底洞——每一次尝试产生更好的系统都在花钱，成不成都要花。于是在放大 RSI 之前，一个更划算的顺序是：先让 AI 学会让 AI 更高效。
SoL-Pi 就是从这个顺序里长出来的。它给自己的定位很克制——不是又一个通用 Agent 框架，而是挂在 Pi（一个轻量、可扩展的 coding-agent harness）上的一组"效率机关"。它提出的目标是受约束的效率：减少 token 流量、推理开销和 Agent 回合数，但不允许提前收工、跳过验证或藏掉证据。
最后半句是整个项目的底线。省钱不难，难的是省得让人看不出来——这也是它和一堆"自动压缩上下文"工具最根本的区别。
152 个想法，为什么只活下来 4 个
SoL-Pi 的机制不是拍脑袋设计的，而是搜出来的。
流程大致是这样：一批 Agent 从公开数据和公开可用的软件环境里，构造出可执行的环境用来做 harness 的 rollout；另一批 Agent 观察模型在这些轨迹里怎么探索，再把观察变成针对 harness 的 auto-research 循环，优化目标就是效率。想法分批生成，每个被选中的想法丢进一条独立的循环，能通过验证的才被带到下一轮。
flowchart LR
P["152 proposed ideas"] --> B["Batch into independent loops"]
B --> V["Validation: cut cost, preserve capability"]
V --> S["4 surviving mechanisms"]
S --> N["Next research frontier"]
style P fill:#FF6B6B,color:#000000
style B fill:#FFEAA7,color:#000000
style V fill:#45B7D1,color:#000000
style S fill:#4ECDC4,color:#000000
style N fill:#DDA0DD,color:#000000
linkStyle default stroke:#764ba2,stroke-width:2px有意思的是被淘汰的那些。博客里随手列出的候选池就有一百多条，比如"C11 在工具输出第一次进入 prompt 之前就削减它"、"C20 检测并修复 prompt 缓存前缀抖动"、"P25 在事件池为空时删掉无操作回合的守卫"、"M45 在单模型能力调优之前先修复数据可信度"。这些想法单拎出来都挺合理，但它们没能同时满足"跨界可迁移"和"不损伤能力"两条硬标准。
最后活下来的 4 个机制，是通过 Pi 的公开扩展 API 组合进来的，并且共享四条设计规则：
- 不打补丁。 SoL-Pi 只 import Pi 的公开 API，不 vendor Pi 的源码树。这是它能跟着上游升级的前提。
- 显式开启。 配置文件缺失任何一个开关，对应机制就是关的。
- 保留证据。 原始观测始终留在本地；reducer 一旦失败，原结果原封不动返回。
- 用 Pi 的运行时选择。 认证、provider URL、主模型、shell 行为，全部交还给 Pi 管。
这四条规则里，前三条是技术设计，最后一条是政治设计——它明确划清了"我只是个扩展，不抢宿主的地盘"。
四个机制拆开看
四个机制分别在 harness 的不同位置下手，这也是我读下来觉得最精巧的地方：它们不是四个独立的优化，而是拼成了一条能自我循环的链路。
flowchart TB
subgraph Loop["Agent harness loop in Pi"]
T["Tool call"]
O["Observation"]
D["Delegation / subagent"]
C["Context window"]
end
AF["Action Fusion"] --> T
OP["ObservationPack"] --> O
EPR["Evidence-Preserving Reducer"] --> D
OCC["Online Context Compact"] --> C
style AF fill:#FF6B6B,color:#000000
style OP fill:#4ECDC4,color:#000000
style EPR fill:#45B7D1,color:#000000
style OCC fill:#96CEB4,color:#000000
style T fill:#FFEAA7,color:#000000
style O fill:#FFEAA7,color:#000000
style D fill:#FFEAA7,color:#000000
style C fill:#FFEAA7,color:#000000
linkStyle default stroke:#764ba2,stroke-width:2px| 位置 | 机制 | 改了什么 |
|---|---|---|
| Tools | Action Fusion | 一次 edit 或 write 可以在同一个 tool call 里跑完它后续的验证命令 |
| Observations | ObservationPack | 反复出现的大段文本结果变成稳定的句柄，支持精确分页取回 |
| Delegation | Evidence-Preserving Reducer | 长诊断日志变成紧凑回执，前提是每一条保留的引文都能对上归档原件 |
| Context | Online Context Compact | 已完成的计划步骤成为 Pi 原生压缩的候选点，受经济性与窗口压力双重检查 |
Action Fusion 盯的是最常见的一种浪费：改完一个文件，紧接着就敲一条可预测的验证命令（跑测试、跑 lint）。这两步本来就是因果关系确定的，却要占两个回合。把它们合进同一个 tool call，省下的是一个完整的模型往返——包括那次往返里被重新读进去的整个上下文。
ObservationPack 解决的是"大结果被反复重放"。一个几万字的文件内容或命令输出，第一次读的时候有用，之后还在上下文里被一遍遍带着走。SoL-Pi 把这些重复出现的大文本收成句柄，需要哪一段就精确分页取回。注意这里的关键词是"精确"——不是摘要，是能原样取回的引用。
Evidence-Preserving Reducer 是我觉得最"较真"的一个。它处理的是长诊断日志：把日志压成紧凑回执，但设定了一条硬门槛——每一条保留下来的引文，都必须能在归档原件里找到对应。对不上就不压，或者直接把原结果返回。它甚至允许把日志内容发给配置好的 reducer 模型做处理（走 Pi 管的认证），所以官方在 SECURITY.md 里特别提醒：必须留在本地的日志，别开远程 reducer。
Online Context Compact 则接管了"任务做到一半该不该压缩上下文"这个判断。它不是按固定阈值触发，而是把已完成的计划步骤作为候选压缩点，再通过经济性和窗口压力两道检查。压缩成功后，它会发一条隐藏的通用消息并带上 triggerTurn: true，开一个新回合让模型接着把当前计划做完。这里有个细节很有意思：它用一个"结算屏障"保证 print 和 JSON 两种模式下，调用方不需要手动 resume 会话、也不用注入一句 "Continue working"。
四个机制合起来，正好覆盖了长任务里四种不同类型的冗余：重复的调用、重复的观测、臃肿的日志、以及没有边界的上下文。
把省钱的数据放进坐标系
省钱这件事，光看绝对值没意义，得有对照。
博客里给出的口径是：在同一问题上长时间工作的专业研究者，SoL-Pi 相比原生 Codex 和 Claude Code harness 每小时省 8.75–13.50 美元，相比 Pi 每小时省 4.36–5.71 美元。 这个区间之所以浮动，是因为它随模型后端变化，计算方式是按官方 API 等价价格折算。
另一个更具体的样本是 Blender 里的 3D 场景重建。官方 2026-10-13 放出的 SoL-Pi Visual 示例中，同样的任务下每个场景的成本比 Codex 低 37%，模型调用次数少 13%。这条数据比"每小时省多少钱"更值得琢磨：成本降了 37%，但调用次数只降了 13%——说明省下来的钱主要不是靠"少干活"，而是靠"每次干活用的 token 更少"。这恰好对应 SoL-Pi 那句 TL;DR：spend less without making the agent do less useful work。
评估基准方面，NVIDIA 提到了一个叫 EdgeBench 的 51 任务套件，专门测长周期的可执行 Agent 工作，并且明确说它的任务、验证器和反馈都留作最终的 held-out 评测——不参与机制搜索过程。这个安排的意义在于：如果机制是在同一批任务上搜出来又在这批任务上验证，那"省了钱"很可能是过拟合。把评测集封起来，结论才有说服力。
至于"152 进 4"这个留存率，看你怎么理解。当成营销数字，它确实很扎眼；当成研究结论，它传递的信息更重要——在受约束的效率目标下，绝大多数看起来合理的优化都过不了能力保持这一关。 换句话说，真正能省的地方比我们想象的要少，而且更难找。
上手：装一个、写一个 JSON
安装的前置条件很明确：Node.js 22.19 以上、npm，以及被固定测试过的 Pi 版本 @earendil-works/pi-coding-agent 0.85.1。
# 安装经过测试的 Pi 发行版
npm install --global @earendil-works/pi-coding-agent@0.85.1
# 从 GitHub 直接安装 SoL-Pi
pi install git:github.com/NVlabs/SoL-Pi只想给当前项目装，用 project-local scope：
pi install git:github.com/NVlabs/SoL-Pi --local --approve配置只有一个有效文件，Pi 官方发行版按这个顺序找：
- 当前项目下的
.pi/sol-pi.json，前提是这个项目被 Pi 标记为可信，且文件存在； - 否则用
~/.pi/agent/sol-pi.json； - 两个都没有，走内置默认值。
注意两点：项目级配置优先于用户级，而且两者不会合并——项目文件会把全局文件整个替换掉。这是个容易踩的坑，你以为改了一项，结果另一项被悄悄重置成了默认值。
一份保守的配置，只开两个不做额外模型调用、也不会中途停掉任务的本地机制：
{
"version": 1,
"actionFusion": true,
"observationPack": true,
"evidencePreservingReducer": false,
"onlineContextCompact": false,
"cacheWriteReadRatio": 12.5
}字段含义：四个 boolean 是开关，缺省即 false；cacheWriteReadRatio 缺省 12.5，意思是"一次缓存写入相对一次缓存读取的成本倍数"，0 表示写缓存不额外增加成本。这个比率是 Online Context Compact 做经济性判断的唯一依据，而且在整个会话里固定不变——即使中途换了模型也不会重算。
evidencePreservingReducer 开起来还需要指定 reducer 走哪个 provider 和 model，由 Pi 的模型注册表解析，凭证仍然由 Pi 管，不要写进 sol-pi.json：
"evidencePreservingReducerProvider": "provider-id",
"evidencePreservingReducerModel": "model-id"如果你用的是官方的全开安装流程，可以先用脚本做预检，确认四个机制真的都活着：
node scripts/check-sol-pi-config.mjs \
--config /absolute/path/to/effective/sol-pi.json \
--require-all-enabled顺带说一句，这个项目对配置错误的处理很硬：未知字段、不支持的版本号、非法的布尔值、非法的比率，都会直接终止扩展加载并报错，而不是默默用默认值兜住。在"配置即行为开关"的场景里，这种 fail-fast 比宽容解析更安全。
如果你不想改动宿主会话，还有一个玩法：2026-10-14 官方放出了 SoL-Pi Skill 示例，可以在 Claude Code 里用 /sol-pi、在 Codex 里用 $sol-pi 把当前任务连同宿主对话上下文交给 SoL-Pi，它在后台跑，跑完把结果回报到当前 session。
什么时候别用：失效边界与代价
省钱的东西最容易让人忽略它什么时候不划算。几个明确的边界：
它默认什么都不做。 四个机制全部 opt-in，配置文件不存在就是全关。如果你装完发现"没效果"，先检查 sol-pi.json 到底在哪、有没有被项目文件整体替换掉。
远程 reducer 是数据外发的边界。 打开 Evidence-Preserving Reducer 并配置了远程模型后，符合条件的诊断日志内容会被送往那个模型处理。涉及密钥、用户数据、内部日志的场景，要么保持关闭，要么指定一个本地路由。这一条官方写在了 SECURITY.md 里，值得认真读。
归档不会自动清理。 ObservationPack 和 Evidence-Preserving Reducer 会把符合条件的内容归档到 <session-directory>/sol-pi/<session-id>/ 下，这些副本留在本地，不会随 Pi 会话结束自动删除；如果用了 --no-session 或者内存会话，它们会落到系统临时目录里一个私有文件夹，同样不会自动清。长期跑的话，磁盘会被慢慢吃掉，这点得自己兜。
它是扩展，不是 Pi 本体。 SoL-Pi 明确声明自己不是 Pi 的官方发行版，且处于活跃开发中，目标是跟上 pi-v1 和最新模型检查点。用的时候要接受"上游一动，扩展可能要跟着动"的节奏。项目的开发校验也很实在，npm run check 一次性覆盖 TypeScript、完整测试套件和包检查，另外还有 npm audit --audit-level=high 和 node scripts/check-pi-compat.mjs 专门盯 Pi 的兼容性。
它不解决能力问题。 SoL-Pi 的目标是"同样的活花更少钱"，不是"干更多的活"。如果你的任务本身需要更多探索、更多验证、更多工具调用，省下来的空间会被这些需求自然吃掉。这也是它为什么反复强调 constrained efficiency——省略掉的必须是冗余，不能是证据。
一个更本质的观察：SoL-Pi 论文里最有价值的可能不是这 4 个机制，而是"用 auto-research 去搜 harness 改进"这条路径。它证明了一件事——harness 的效率是可以被系统性地搜索出来的，而不是只能靠人拍脑袋调。至于这 4 个机制，今天能用；明天可能被更好的 4 个替代。真正会留下来的，是那套能不断产出下一批机制的方法。
参考文档与链接
- SoL-Pi 仓库（NVlabs/SoL-Pi） — 本文核心依据，含四个机制说明、安装步骤与设计规则
- SoL-Pi 官方博客 — 项目来龙去脉、auto-research 方法与省钱口径的原始出处
- 论文：SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness — 方法细节与研究结论
- 配置文档 docs/configuration.md — 配置查找顺序、schema 与各机制行为
- SECURITY.md — 本地归档、远程 reducer 与敏感行为说明
- agents-install.md — 可复现的全开安装与校验流程
- sol-pi.example.json — 列出全部配置键的模板
- Pi（earendil-works/pi） — SoL-Pi 依附的轻量可扩展 harness
- SoL-Pi Skill 示例 — 在 Claude Code / Codex 中把 SoL-Pi 当 skill 用
- SoL-Pi Visual 示例 — Blender 3D 场景重建的成本与调用次数对比
- NVlabs 组织主页 — NVIDIA 的开源研究项目集合
你更在意 Agent 的绝对能力，还是单位成本？评论区聊聊你现在的 token 账单。觉得有用就点个赞，让更多在跑长任务的人看到。
作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/
关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
