NVIDIA又搞了一件有意思的事：让AI自己研究，怎样才能让AI Agent更高效？
这两年，AI Agent越来越火。
我们已经不满足于让大模型回答一个问题，而是开始让它自己搜索资料、修改代码、运行程序、检查错误，甚至连续工作几个小时。
但一个非常现实的问题也随之出现了：
Agent越能干，Token消耗也可能越惊人。
一个简单的问题，也许只需要几千个 Token。
但如果让 Agent 独立完成一个复杂的软件开发任务，它可能需要不断读取文件、调用工具、执行命令、查看日志、修改代码，再重新测试。
几个小时下来，真正有价值的操作可能只有其中一部分。
剩下的 Token，很可能都花在了：
重复读取、重复思考、重复传递信息，以及一些根本不需要大模型参与的中间步骤上。
于是 NVIDIA 最近做了一个很有意思的研究项目：
SoL-Pi。
它研究的问题并不是“如何训练一个更大的模型”，甚至也不只是“如何让 Agent 少花一点 Token”。
它真正想探索的是：
能不能让 AI 自己研究 AI Agent 的工作方式，然后自动找到其中的浪费，并把这些优化真正实现出来？
这件事一旦成立，意义就不只是“省钱”这么简单了。
一、先理解一个概念：真正的 Agent，不只是一个大模型
很多人第一次接触 AI Agent，会觉得 Agent 就是：
大模型 + Prompt。
实际上远远没有这么简单。
一个真正能够长期工作的 Coding Agent，背后通常还需要一整套运行机制。
它要知道什么时候调用模型，什么时候调用工具；怎样保存上下文；怎样处理工具返回的大量信息；什么时候压缩历史记录；什么时候把任务交给另一个 Agent；任务完成以后又应该怎样验证。
这套负责“组织大模型工作”的系统，可以理解为：
Agent Harness。
如果把大模型比作发动机，那么 Agent Harness 更像是一辆汽车的整套传动、控制和管理系统。
发动机再强，如果传动系统效率很低，整辆车依然会浪费大量能量。
SoL-Pi 研究的核心，正是这个 Harness。
而它采用的方法非常特别：
让 AI 自己研究 Agent Harness。
二、SoL-Pi到底是怎么工作的？
传统的 Agent 优化，一般是工程师来做。
工程师先观察 Agent 的运行过程。
发现某个地方效率比较低。
然后修改代码。
再跑 Benchmark。
如果结果变好，就保留；如果结果不好，就继续修改。
这个过程本质上仍然是：
人研究 Agent。
而 SoL-Pi 想把其中很大一部分工作交给 AI。
整个过程可以理解为几个连续的研究阶段。
第一阶段：让 Agent 真正去完成任务
首先，让普通 Agent 在各种真实或者可执行的环境里完成任务。
例如修改代码、解决 GitHub Issue、运行测试、分析程序错误等。
这些任务不是简单的问答，而是会产生完整的 Agent 工作轨迹。
第二阶段：收集这些工作轨迹
系统会记录 Agent 在执行任务过程中发生的一切。
包括它调用了什么工具、读取了什么信息、什么时候调用模型、上下文如何变化，以及最后任务有没有完成。
这一步非常重要。
因为如果不知道 Agent 到底是怎么工作的，就很难知道它究竟浪费在哪里。
第三阶段：让 AI 分析这些轨迹
接下来，AI 开始研究这些工作记录。
它要寻找的问题不是：
“这个任务最后完成了吗？”
而是：
“Agent完成这个任务的过程中，有哪些工作其实没有必要？”
例如：
为什么刚刚修改完文件之后，还需要重新让模型思考一次“现在运行测试”？
为什么一份几十万行的日志已经读取过一次，后面还要不断把完整内容重新塞进上下文？
为什么一个简单的日志阅读任务，非得消耗最强、最昂贵的模型？
这些问题，就成为新的研究方向。
第四阶段：提出优化机制
找到问题以后，AI 不只是给出一句建议。
它需要真正提出一个可以实现的机制。
然后由 Agent 自己编写代码，把这个机制加入 Harness。
第五阶段：自动测试和验证
代码写完以后，还不能直接宣布成功。
系统需要重新运行任务。
而且 SoL-Pi 有一个非常重要的原则：
不能为了省 Token 而牺牲任务能力。
如果一个方案只是简单地让 Agent 少做事情，当然也可以节省 Token。
但这种“优化”没有意义。
所以一个候选机制必须同时满足两个条件：
效率提高，同时能力不能明显下降。
第六阶段：淘汰失败方案
于是，大量 AI 提出来的方案会在验证阶段被淘汰。
最终能够留下来的，只是少数真正有效的机制。
这就形成了一套非常有意思的自动研究模式：
AI完成任务，AI观察任务，AI寻找浪费，AI提出改进，AI实现改进，AI验证改进。
这里最重要的变化是：
AI开始研究“AI应该怎样工作”。
三、NVIDIA一口气让AI研究了152个方向
这也是 SoL-Pi 最有意思的地方之一。
NVIDIA 并不是让一个 Agent 慢慢研究一个方案。
它一开始准备了：
152 个候选研究方向。
然后把这些方向分别放入独立的自动研究循环中。
一个研究方向如果表现不好，就被淘汰。
表现好的继续实现、测试和验证。
最后：
152 个候选方向，只有 4 个机制进入最终的 SoL-Pi。
换句话说，大量 AI 提出的想法最终都会失败。
这其实非常接近真正的科研过程。
不是“AI提出一个答案，然后答案就成立”。
而是：
提出假设 → 实验 → 失败 → 修改 → 再实验 → 验证 → 淘汰或者保留。
NVIDIA甚至发现，当单个研究方向持续迭代大约 5～10 轮以后，即使是高推理强度的模型，也可能陷入一个局部搜索空间，不断对同一种设计进行小修小补。
这时候，扩大搜索方向反而更重要。
所以 SoL-Pi 使用了大量并行的研究路线，让不同 Agent 同时探索不同想法。
最终大约只有 1/40 的初始想法能够通过验证。
但正是这种“大量尝试、少数存活”的机制，让一些原本不容易被单一路线发现的优化方案浮现出来。
四、那么AI最后到底发现了什么？
最终留下来的四个机制，并不是什么听起来特别玄乎的新算法。
恰恰相反。
它们解决的都是 Agent 工作过程中非常具体的浪费问题。
分别是：
Action Fusion
Online Context Compact
ObservationPack
Evidence-Preserving Reducer
如果把它们翻译成人话，就是：
能一次完成的事情，不要让模型思考两次。
已经完成的子任务，不要让历史上下文一直拖着。
已经读取过的大量信息，不要反复复制。
简单的信息整理可以交给便宜模型，但最终证据必须能够被验证。
这四个机制，分别对应了 Agent 的工具调用、上下文管理、信息观察以及多 Agent 协作。
下面一个一个来看。
五、Action Fusion：为什么“改完代码再运行测试”还要让AI思考一次？
假设你让 Coding Agent 修改一个 Python 文件。
它完成修改之后，下一步显然是运行测试。
传统 Agent 很可能是这样工作的：
第一轮模型：
我需要修改 main.py。
修改完成。
第二轮模型：
文件修改好了，现在应该运行 pytest。
实际上，中间这个“思考”很多时候并没有创造多少价值。
因为：
修改完成 → 运行测试
本来就是一个高度确定的动作序列。
SoL-Pi 发现，在基础 Agent 的运行轨迹中，这种“修改之后紧接着执行命令”的情况非常常见。
于是它设计了：
Action Fusion。
把原本需要两个模型回合的动作，融合成一次工具调用。
模型只需要表达：
修改文件，然后运行测试。
具体的执行工作由 Harness 在本地完成。
这样就减少了一次模型往返。
NVIDIA 的轨迹分析发现，约 12.3% 的跨轮转移属于这种潜在的“编辑后立即执行命令”场景。
如果记录到的候选全部触发融合，模型回合数理论上可以从 1386 次降到 1237 次，下降约 10.8%；Token 则可以从 3238 万减少到 2864 万，下降约 11.5%。
需要注意的是，这组数字是基于已有轨迹计算出的反事实估算，不是重新运行后的实测结果。
这个思路其实非常简单：
不要让大模型参与那些已经确定的机械步骤。
六、Online Context Compact：不要让Agent背着过去几个小时的历史继续工作
第二个问题，是所有长期 Agent 都绕不开的：
上下文越来越长。
比如一个 Agent 工作了两个小时。
它已经完成了：
代码分析、文件修改、Bug 修复、测试、日志分析……
如果每一轮都继续携带之前的大量上下文，那么 Token 消耗会越来越高。
传统的上下文压缩通常倾向于：
上下文太长了 → 开始压缩。
但 SoL-Pi 发现，这个时机未必合理。
它提出的思路是：
不要只看上下文有多长，而要看一个子任务是不是已经完成。
例如：
一个大型任务可以分成：
代码分析、数据库修改、接口修改、测试……
当“数据库修改”已经完成以后，这部分历史就可能成为一个天然的压缩边界。
于是 Online Context Compact 会重新评估：
现在压缩这一部分历史，未来节省下来的 Token，是否足以抵消压缩本身的成本？
如果值得，就进行压缩。
如果不值得，就继续保留。
也就是说：
上下文压缩不再只是“太长了就压缩”，而变成了一种成本收益决策。
七、ObservationPack：看过一次的日志，为什么还要重复发送？
这个机制非常容易理解。
假设 Agent 执行了一个命令：
运行测试结果返回了几十万行日志。
真正影响下一步决策的，也许只有其中几行。
但传统做法可能是：
第一次看到完整日志。
下一次模型调用，又把这份日志带上。
再下一次，又带上。
于是同样的信息不断占据上下文和缓存。
SoL-Pi 的 ObservationPack 做了一件非常朴素的事情：
把完整内容保存起来，但不要每一次都重新搬进上下文。
上下文里只留下：
一个引用、一个简短摘要，以及必要的片段。
如果 Agent 后面真的需要原始内容，再根据引用把对应页面读取出来。
这样就实现了：
信息没有被删除，但重复传输被减少了。
这其实是 Agent 上下文管理里一个非常重要的思想：
减少上下文，不等于删除信息。
真正好的上下文系统应该做到：
信息随时可以找回来，但没有必要每一轮都重新发送。
NVIDIA 在一个配对的 EdgeBench 实验中，对 ObservationPack 的一个最终配置报告了约 23.58% 的 Provider Bill 降幅和 23.73% 的单响应成本下降，同时归一化得分提高约 22.92%。不过这个实验只包含 11 个任务，因此更适合作为该机制的配对验证，而不是整个 SoL-Pi 的总体效果。
八、Evidence-Preserving Reducer：小模型可以帮你读日志，但不能让它随便总结
第四个机制更有意思。
在软件开发过程中，经常会遇到非常长的日志。
例如一次测试产生了几十万行输出。
真正重要的可能只有：
Error附近的几行。
如果每一次都让最强的大模型阅读完整日志，成本非常高。
于是 SoL-Pi 的思路是：
让更便宜的 Agent 先负责阅读。
但是这里有一个问题：
小模型如果总结错了怎么办？
比如它说：
“测试失败是因为数据库连接错误。”
但真正的问题可能发生在另外一处。
所以 SoL-Pi 没有简单地相信这个摘要。
它要求摘要中的关键证据能够回溯到原始日志。
也就是说：
便宜的 Agent 可以负责阅读，但最终结论必须有原始证据支撑。
这就是：
Evidence-Preserving Reducer。
它把一个很大的日志变成一个更小的“诊断结果”，但同时保留对应的原始证据。
因此主 Agent 接收到的不是：
“另一个 AI 告诉我答案是什么。”
而是：
“另一个 AI 帮我找到了答案，并且我可以验证它为什么这么说。”
这对于未来的大规模 Agent 协作非常重要。
九、这四个机制背后，其实都是同一个思想
把这四个机制放在一起看，就会发现它们解决的并不是四个完全不同的问题。
它们都在做同一件事情：
减少 Agent 工作过程中不产生价值的重复劳动。
Action Fusion：
减少不必要的模型回合。
Online Context Compact：
减少已经完成任务的历史负担。
ObservationPack：
减少大型工具输出的重复传输。
Evidence-Preserving Reducer：
减少昂贵模型对大量原始信息的重复阅读。
最终目标只有一个：
让 Agent 把 Token 花在真正需要智能的地方。
这其实和人类工作非常像。
一个优秀的工程师，不会每做一个动作都重新思考一遍。
也不会把过去三个月所有项目资料全部放在桌子上再开始工作。
更不会自己亲自阅读几十万行日志，只为了找其中的一行错误。
真正高效的工作方式一定会：
自动化机械动作、整理上下文、提取关键信息，并把复杂任务交给合适的人。
SoL-Pi 正在尝试让 Agent 也具备这种能力。
十、SoL-Pi到底有多大提升？
这才是大家最关心的问题。
NVIDIA 使用了 EdgeBench 对 SoL-Pi 进行了长时间 Agent 任务测试。
结果显示：相比 Pi，SoL-Pi 的 Token 使用量减少了大约：45%～49%。
同时模型成本大约降低：三分之一。
而相比模型原生的 Agent Harness：Token 使用量减少约 35%～64%。
API 等价成本降低约：50%～54%。
与此同时，SoL-Pi 在 EdgeBench 上保留了大约 94% 的 Pi 平均得分。
也就是说，它并不是简单地“少干活”。
而是在保持大部分任务能力的前提下，减少了大量运行成本。
在 GPT-5.6 Sol 的测试中，SoL-Pi 的平均表现还超过了该模型原生的 Codex Harness。
不过这里也必须把另一组结果说清楚。
在 Terminal-Bench 4 的 63 个任务上：
Agent |
完成任务数 |
API等价成本 |
Codex |
18 |
$272.35 |
Pi |
18 |
$286.45 |
SoL-Pi |
15 |
$211.12 |
可以看到，SoL-Pi 在这个测试上的完成任务数并不是最高，但成本最低。
所以不能简单地把这项研究理解成：
SoL-Pi全面超过所有其他 Agent。
更准确的理解应该是：
SoL-Pi证明了，通过自动研究 Agent Harness，可以在保持相当任务能力的同时，大幅降低长期 Agent 的 Token 和运行成本。
十一、真正有意思的来了：20个AI Agent一起工作，成本反而可以降下来
如果你觉得前面的内容只是“优化一个 Agent”，那么 SoL-Pi 后面的 Agent Swarm 实验更加有意思。
NVIDIA 测试了一个由多个 Agent 组成的协作系统。
最上面由一个 GPT-5.6 Sol Coordinator 负责协调。
下面安排：
20 个 GPT-5.6 Luna Worker。
20 个 Worker 又分成 5 个小组，每组 4 个 Agent。
每个小组独立探索。
如果某个 Agent 找到了有价值的方案，它可以把结果分享给其他 Agent。
但这里有一个非常重要的设计：
Agent之间不是共享所有思考过程，而是共享经过提炼的证据和结果。
为什么？
因为如果 20 个 Agent 把所有信息全部互相发送：
通信成本本身就可能成为新的浪费。
SoL-Pi 的思路是：独立探索，有限交流，结果验证。
最终只有经过验证的改进，才能进入共享的最佳结果。
在一次两小时的实验中：Sol + 20 个 SoL-Pi Worker
最终达到：1127 cycles，模型成本 $60.11。而：Sol + 20 个 Pi Worker
达到：1366 cycles，模型成本 $82.12。
也就是说，在这次实验中，SoL-Pi Worker 的组合相比 Pi Worker：
Cycles 减少约 17.5%，成本降低约 26.8%。
这说明一个非常重要的问题：
Agent 数量增加以后，真正重要的不只是“多几个 AI”，而是这些 AI 有没有足够高效的工作方式。
十二、这可能是未来Agent发展的一个重要方向
过去几年，我们理解 AI 进步的方式非常简单：
更大的模型。
更多的数据。
更强的 GPU。
但进入 Agent 时代之后，事情开始发生变化。
因为一个 Agent 真正执行复杂任务时，模型只是整个系统的一部分。
最终效果还受到：
上下文管理、工具调用、任务分解、Memory、模型选择、Agent 协作、验证机制、运行成本
等大量因素影响。
所以未来 AI 的竞争可能不只是：
谁的模型更大？
还可能是：
谁能让模型连续工作几个小时甚至几天，而且不把大量 Token 浪费在重复劳动上？
这就是 SoL-Pi 这种研究真正值得关注的原因。
十三、AI开始研究“怎样让AI工作得更好”
其实到这里，SoL-Pi 最有意思的地方已经不再是省了多少 Token。
而是它改变了一个角色关系。
以前：人研究 AI。现在：AI开始帮助人研究 AI 系统。
工程师不需要亲自分析几十万条 Agent 运行轨迹。可以让 Agent 自己去分析。
工程师也不需要亲自尝试几百个优化方案。可以让 AI 自动并行探索。
工程师真正需要做的，是设计研究目标、设置能力下限、提供初始方向，然后检查最终留下来的机制。
SoL-Pi 的作者也明确把目前的系统定义为一种混合式自动研究流程：人类提供早期先验和研究边界；一旦候选进入自动研究循环，后续研究和验证可以在没有人工干预的情况下运行；当候选机制最终存活下来，人类再回来理解和整理它。
所以现在还不能说：
AI已经完全可以自主改进自己。
更加准确的说法是：
人类搭建了一套自动科研机器，让 AI 在规定的范围里研究如何改进 AI 系统。
十四、而NVIDIA真正想探索的，可能是下一步
SoL-Pi 最后提出了一个非常有意思的概念：
Recursive Efficient Improvement。
可以翻译成：
递归式效率改进。
什么意思？
假设第一代 Agent Harness 花 100 美元做一次自动研究。
如果它通过研究变得更加高效，那么下一代 Harness 可能只需要 70 美元就能完成同样规模的研究。
于是原本 100 美元的预算，就可以做更多实验。
更多实验意味着：
可以探索更多环境。
可以测试更多方案。
可以发现更多有效机制。
于是下一代系统可能变得更加高效。
再用更低的成本进行下一轮研究。
这就形成了一个潜在的循环。
但这里一定要注意：
NVIDIA目前并没有证明这种效率会无限递归地增长。
论文把它定义为一个长期研究方向，而不是已经被当前实验验证的“自我加速”。
这个区别非常重要。
十五、未来的AI研发，可能真的会出现“AI研究AI”
想象一下未来一个 AI 研发团队。
人类只需要提出一个目标：
“让 Coding Agent 在长时间任务中更加高效。”
接下来，大量 AI Agent 开始工作。
有的研究上下文。
有的研究工具调用。
有的研究 Memory。
有的研究 Agent 协作。
有的研究模型路由。
有的研究验证机制。
它们分别进行实验。
大量方案失败。
少数方案成功。
成功的方案进入下一轮验证。
最后，人类研究人员看到的可能已经不是一份几百页的实验报告，而是：
“我们发现了三个能够稳定降低 Agent 成本的机制，这是实验数据，这是代码，这是验证结果。”
这时候，AI就不再只是一个“帮人写代码”的工具。
它开始变成：
研究 AI 系统本身的研究工具。
写在最后：SoL-Pi真正值得关注的，不是省了多少Token
我认为 SoL-Pi 最值得关注的地方，其实不是：Token减少45%还是49%。
这些数字当然重要。但真正重要的是背后的方法。
过去我们一直在想：怎样让 AI 更聪明？
而现在开始出现另一个问题：怎样让 AI 把自己的智能用得更加高效？
这两个问题看起来很接近，实际上完全不同。
一个 Agent 如果每次遇到问题都调用最强模型，把所有历史信息全部塞进上下文，然后把每一个机械动作都交给大模型决定，即使模型能力再强，也可能非常昂贵。
而一个真正成熟的 Agent，应该知道：
什么时候需要思考，什么时候不需要思考；
什么信息需要保留，什么信息可以压缩；
什么任务需要最强模型，什么任务可以交给便宜模型；
什么时候应该独立探索，什么时候应该共享证据；
什么优化值得保留，什么优化应该立即淘汰。
SoL-Pi 做的事情，本质上就是：
让 AI 开始研究这些问题。
这可能是 Agent 时代一个非常重要的变化。
因为未来 AI 的竞争，也许不只是：
谁的模型更聪明。
还可能是：
谁能让自己的智能运行得更久、更便宜、更稳定。
而当 AI 开始研究怎样让 AI 自己工作得更高效时，我们看到的可能已经不再只是一个更好的 Agent。
而是一个新的方向：
让 AI 开始参与改进生产 AI 的整个系统。
SoL-Pi，可能只是这个过程的一个早期实验。