英伟达开源了自家的 Harness 项目 SoL-Pi。这个项目以 Pi 为底座，额外加入一层面向效率的增强机制，目标不是先把 AI 做得更聪明，而是先把 AI 在执行任务和自我改进时的成本压下来。
按照项目介绍，SoL-Pi让 AI 在自动化流水线里直接参与对 Agent 系统的观察、修改、测试和筛选。系统会分析 Agent 的执行过程，找出重复消耗 Token 的步骤，提出改进方案、修复 bug，再把方案送入测试流程。整个搜索从 152 个候选方向开始，最后保留下来 4 个核心架构机制。
实测结果中，SoL-Pi 的 Token 消耗最高可减少 64%，API 调用成本下降 50% 至 54%。项目页面给出的数据还显示，在专业研究场景中，每小时可节省 8.75 美元至 13.5 美元。项目代码已经在 GitHub 开源，安装方式也被压到一行命令：pi install git:github.com/NVlabs/SoL-Pi。
Harness 瞄准的是 Agent 执行过程里的重复开销
在这套设计里，模型本身负责推理，而 Harness 负责组织工具、上下文、执行反馈和任务流程，让模型能够读取文件、修改代码、运行测试，并根据结果继续行动。原文指出，同一个模型如果放进不同的 Harness，执行效率可能会拉开明显差距。
问题出现在编程智能体的任务越来越长。任务已经从补几行代码，延伸到跨仓库修复问题，再到持续数小时的自主工作。任务被拉长后，原本不显眼的 Token 浪费会持续叠加。
比如模型改完文件后，下一步明明就是运行测试，系统却还要再多走一轮推理；某个大文件之前已经读过，后续请求里却仍被反复携带；几千行日志里真正影响决策的可能只有几行，但昂贵的大模型还是要把全文重新读一遍。原文认为，这些额外开销在递归自我改进，也就是 RSI 场景下同样存在，因为 AI 每尝试改进一次系统，都要为这轮尝试支付 Token 成本，哪怕方案最后失败也照样计费。
SoL-Pi的目标就是处理这类问题。和底座 Pi 相比，它可少用 45% 至 49% 的 Token，成本降低约三分之一，平均得分保留约 94%。如果拿它与 Codex、Claude Code 的原生 harness 对比，SoL-Pi 可减少 35% 至 64% 的 Token，标价成本下降 50% 至 54%。
四项核心机制从 152 个候选方向中筛出
英伟达最终留下来的 4 项机制，核心都围绕减少重复劳动和无效计费展开。
动作融合：把编辑与验证并进一次调用
第一项机制是 Action Fusion，针对的是两次工具调用之间那段额外的模型决策环节。
在基础 Pi 的执行轨迹里，常见顺序是先修改文件，收到结果，再调用命令去测试或构建。既然后续命令往往已经很明确，那么中间多出来的一轮模型决策就存在压缩空间。SoL-Pi 的做法是，把一次编辑以及它后续的命令放进同一个本地执行序列里，由 Harness 在底层完成修改和运行命令，再把合并后的结果一次性返回给模型。测试照常进行，结果也能正常获取，但中间那次模型请求被省掉了。
在线上下文压缩：按子任务重新核算是否值得压缩
第二项机制是 Online Context Compact，处理的是上下文压缩时机的问题。
原文提到，上下文越长，历史材料越容易变成算力和资金负担；但压缩本身也有代价，因为重写上下文可能打断已有的 KV-cache 复用，系统需要重新支付处理成本。过去的策略通常是尽量延后压缩动作。
SoL-Pi 改了这个判断方式。它把大任务拆成子任务，每完成一步就重新评估一次，只有当未来预期节省的开销能够覆盖本次重写的成本时，系统才执行压缩。也就是说，是否压缩不是静态规则，而是围绕每个子任务动态决策。
输出归档与索引：长内容只留句柄和摘录
第三项机制是 ObservationPack，瞄准的是大段工具输出带来的重复计费。
一个大文件或一段很长的执行结果，首次读取后如果一直保留在上下文里，后续每轮请求都要原样携带，缓存资源也会持续被占用。SoL-Pi 的做法是，把完整内容归档到本地磁盘，在上下文中只保留一个稳定的短句柄和一小段摘录。模型需要查看细节时，再根据索引按页取回。这套设计相当于把长文档存档，手边只保留索引和摘要。
证据保留归约器：先让小模型筛日志，再做原文核验
第四项机制是 Evidence-Preserving Reducer，重点在长日志的初步筛读。
构建和测试日志经常会达到上万字，真正影响后续决策的可能只是几行报错。每次都让前沿大模型通读全文，成本很高；但如果把总结完全交给小模型，又会增加幻觉风险。SoL-Pi 在两者之间增加了一道证据核验流程：辅助模型先读日志，输出一份紧凑的诊断回执，系统再拿这份回执逐条去和归档的原始日志比对。只有和原文严格对上的内容，才会被提交给前沿大模型。
按照原文说法，这意味着主模型接收到的是已经被证实的信息，误差不会在后续步骤里继续传导。
英伟达把目标转向“先省钱”，而不是“先追分”
原文解释了为什么最后是这 4 项机制留下来，也点出了 SoL-Pi 背后的更大目标：RSI，也就是递归自我改进。
按这一思路，既然 AI 可以修改代码，也应该能修改“生产 AI 的系统”。但 RSI 的问题是成本高，每一次试错都需要支付 Token 费用。英伟达因此先换了目标：先不急着追求更高任务分数，而是优先提高 Token 效率。
原文给出的理由是，直接追任务得分更容易出现针对特定题目的过拟合；而减少重复上下文、压缩工具输出、合并不必要决策这些优化，更容易迁移到不同任务和不同模型里。
在这条思路下，团队搭建了一条“Agent 研究 Agent”的流水线。团队先构建 535 个可验证环境，再让 AI 提出 152 个优化方向，并经过 3 轮筛选：
- 先用历史轨迹估算收益，没有潜力的方向直接淘汰；
- 再让 AI 自己修改代码、运行实验，并由 Reviewer Agent 进行审查；
- 最后冻结方案，在完全隔离的 held-out 任务上做验证，要求能力不能下降、效率必须上升。
152 个想法最后只留下 4 个，平均约 40 个方向才能筛出 1 个有效机制。原文据此总结，SoL-Pi 的方法就是让 AI 大量提出假设，再自动实验、淘汰和验证，最后把真正有效的少数机制筛出来。
项目团队把重点放在“AI 研究 AI”的闭环上
原文提到，SoL-Pi 背后是由 MIT 副教授、英伟达研究总监韩松带领的 Efficient AI 团队。对团队来说，SoL-Pi 当前节省了多少 Token，只是阶段性结果，他们更看重的是“AI 研究 AI”这条飞轮还能转到什么规模。
官方项目主页中还列出两个长期方向。其一是“闭环预训练”，也就是 Pretraining the harness。现阶段的 535 个环境仍由人工构建，后续目标是由 Agent 自行在全网收集任务、搭建环境、验证，并持续更新自己的 harness。原文认为，一旦算力和环境多样性被拉高，harness 也可能跑出自己的 Scaling Law。
第二个方向是“效率复利”，即 Efficiency for efficiency。项目想用已经更省的 harness 去运行规模更大、成本更低的自动研究循环，再继续寻找更高效的机制，形成持续压缩成本的复利效应。
按照原文描述，在这条飞轮里，人类主要在初期提供先验方向；一旦系统进入循环，从研究到验证都可以零干预运行；等 AI 把机制跑通后，人再回来分析 AI 实际发现了什么，并把机器生成的粗糙代码重构成符合工业标准的版本。
目前，模型的 Scaling Law 仍在被持续讨论；而在原文的判断中，Harness 的 Scaling Law 已经有人开始提前布局，而跑在这条赛道上的主体，就是 AI 自己。
项目信息与参考链接
GitHub：https://github.com/NVlabs/SoL-Pi
项目主页：https://nvlabs.github.io/SoL-Pi/
X 链接：https://x.com/MaxForAI/status/2098050525279478059
本文来自微信公众号「新智元」，作者为 ASI 启示录，编辑为桃子、摩西。MarsBit 页面收录并发布了上述内容。