编码智能体正在从"辅助写代码"走向"无人值守自主探索"。这个转变中有个容易被忽略的问题。围绕大模型的那层脚手架，也就是决定模型看什么、保留什么、调用多少次API的代码，其实本身就可以被优化。
一、先搞清楚Harness是什么
很多人关注大模型本身的性能提升，却忽略了一个事实：模型不是裸跑的。在模型和实际任务之间，存在一层被称为"Harness"（脚手架）的软件层。
简单来说，Harness决定了三件事：
- 模型看到什么：上下文窗口里装哪些信息
- 模型保留什么：哪些历史记录被压缩或丢弃
- 模型调用多少次：每次交互消耗多少token
以编码智能体为例，当你让它修改一个文件并运行测试，Harness负责：读取文件内容→传递给模型→接收修改指令→执行修改→运行测试→把测试结果返回给模型。这个过程中，Harness的策略直接影响效率。
问题在于：大多数Harness是人工设计的，优化空间有限。
二、SoL-Pi想解决什么问题
2026年9月，英伟达实验室联合MIT和南洋理工大学的研究团队发布了SoL-Pi。这篇论文（arXiv:2609.20519）的核心问题很明确：
能否让AI自己来优化这个Harness？
研究团队的出发点基于一个观察：编码智能体的token消耗正在快速增长。Anthropic的数据显示，智能体工作负载消耗的token大约是普通聊天的4倍，在多智能体系统中可达15倍。当智能体需要7×24小时运行时，token效率直接决定了运营成本。
传统的优化思路是改进模型本身。SoL-Pi另辟蹊径：不动模型，只优化模型周围的脚手架。
三、怎么让AI优化自己的脚手架
SoL-Pi采用了一种被称为"递归自改进"（RSI）的方法论。具体流程是：
- 生成环境：从公开软件仓库中构建可执行的测试环境
- 观察行为：让基础Harness在这些环境中运行，记录执行轨迹
- 提出假设：AI观察轨迹后，提出优化方案
- 验证筛选：在环境中测试优化方案，保留通过验证的改进
- 迭代循环：用改进后的Harness继续下一轮优化
这个过程跨越了535个环境，进行了3000多次运行和超过6万次智能体-环境交互。从152个候选方案中，最终筛选出4个通过所有验证标准的机制。
四、四个存活下来的机制
Action Fusion（动作融合）
智能体修改文件后，通常会紧接着运行一个验证命令（比如测试、编译）。在基础Harness中，这是两次独立的工具调用，每次都需要模型参与。Action Fusion把文件修改和后续验证合并为一次工具调用，消除了中间的模型交互轮次。
ObservationPack（观察打包）
当工具输出很长时（比如大文件内容、大量日志），每次模型需要回顾这些内容，都要重新传递一遍。ObservationPack把大的工具输出存档到本地磁盘，只在上下文中保留一个短句柄和摘要。需要完整内容时，通过分页检索按需召回。
Evidence-Preserving Reducer（证据保持缩减器）
诊断日志和构建日志往往有数MB大小。Evidence-Preserving Reducer用小模型对日志进行初筛，压缩成紧凑摘要。关键约束是：保留的每一句引用都必须与原始存档内容完全匹配。如果缩减器验证失败，原始输出保持不变。
Online Context Compact（在线上下文压缩）
当一个子任务完成后，Online Context Compact触发上下文压缩，根据经济性和上下文窗口压力指标决定是否压缩。压缩后，模型在新的上下文中继续任务。
五、效果如何
在EdgeBench（51个长周期软件工程任务）上的测试结果：
| 对比基准 | Token流量减少 | API成本减少 | 性能保持 |
|---|---|---|---|
| vs Codex/Claude Code原生Harness | 35%-64% | 50%-54% | --- |
| vs Pi原生Harness | 44.7%-49.0% | 33.2%-33.5% | 93.7% |
换算成实际成本：
- 相比Codex和Claude Code原生Harness，每小时节省8.75-13.50
- 相比Pi原生Harness，每小时节省4.36-5.71
值得注意的是，SoL-Pi在GPT-5.6 Sol上开发，但未经修改直接应用到Opus 5上时，依然保持了相似的效果。这说明发现的机制具有跨模型的迁移能力。
不过也有代价：在Terminal-Bench 4上，SoL-Pi解决了15个任务，而Codex和Pi都解决了18个。在IMO 2026上，SoL-Pi通过了6个问题中的3个，Codex通过了5个。效率提升的同时，部分场景下性能有所下降。
这里有一个值得思考的取舍：在什么场景下，效率比性能更重要？
对于7×24小时运行的自动化编码系统，成本是硬约束------每小时省10，一年就是87,000。但对于需要一次做对的关键任务，省token可能得不偿失。SoL-Pi的定位很清晰：它不是要让智能体变得更聪明，而是让智能体在保持能力的前提下变得更经济。
六、设计原则
SoL-Pi的架构选择体现了几个值得关注的原则：
Extension而非Fork：SoL-Pi完全通过Pi的公共扩展接口工作，不修改Pi的核心代码。这意味着它可以在Pi更新时无缝跟随。
显式启用：所有四个机制默认关闭，需要在配置文件中显式声明启用。这降低了意外行为的风险。
证据保留：原始命令输出和完整诊断日志被存档在专用目录中。如果缩减器验证失败，原始内容保持不变。
运行时主权：模型选择、认证令牌、API端点、Shell执行等仍由Pi控制，SoL-Pi不越界。
一个反直觉的观察：SoL-Pi的四个机制都不是新发明。减少工具调用轮次、缓存大文件输出、压缩日志、管理上下文------这些实践在软件工程中早已存在。有意思的是，这些优化不是人想出来的，是AI自己发现的。
这说明什么？人类工程师在设计Harness时，可能漏掉了一些"低垂的果实"。不是因为想不到，而是因为没有系统性地去验证。SoL-Pi的价值在于：它提供了一种机制，让AI在大规模环境中系统性地搜索这些被忽略的优化点。
七、这意味着什么
SoL-Pi的意义不在于它省了多少钱------虽然这个数字确实可观。更值得关注的是它验证了一个思路：
递归自改进可以从模型层扩展到Harness层。
过去讨论RSI时，焦点往往集中在模型权重的自我修改。SoL-Pi表明，围绕模型的软件层同样可以成为自我改进的对象。而且由于Harness层不涉及模型权重更新，改进过程更可控、更安全。
研究团队在论文中提到了一个长期愿景：用优化后的Harness运行更大规模、更低成本的自动化研究循环，从而发现更高效的Harness机制。这形成了一个正向循环------更高效的Harness使得每次实验成本更低，固定预算可以覆盖更多环境，可能发现更好的Harness。
当然，这只是愿景，不是已经实现的效果。论文原文也明确指出，这是一个"长期研究愿景，而非当前工作已经展示的复利效应"。
八、对普通开发者的真实影响
一个残酷的现实：SoL-Pi每小时省8.75-13.50，这是按API定价算的。但大多数开发者的使用频率远达不到这个量级。真正受益的是需要大量自动化编码的团队、运行CI/CD的平台、以及用AI做代码审查的服务商。
对于个人开发者，更值得关注的是思路而非工具本身。SoL-Pi证明了一件事：围绕AI的软件层存在大量未被系统性优化的空间。如果你正在构建AI应用，不妨审视一下自己的Harness------那些重复的API调用、冗余的上下文传递、不必要的日志回传，可能都是可以压缩的成本。
SoL-Pi已开源（MIT许可证），项目地址：https://github.com/NVlabs/SoL-Pi
留给读者的三个问题
- 如果AI能优化自己的运行环境，那"调试AI"这件事本身是否也会被自动化？
- 当Harness层的优化变得越来越重要，"AI工程师"的核心技能是否会从写代码变成设计Harness？
- SoL-Pi验证了RSI可以在Harness层工作，那下一个被优化的层会是什么？
本文数据来源：arXiv:2609.20519（SoL-Pi论文）、NVIDIA Labs官方发布、Pi Coding Agent官方文档。