1. 从标题拆解SoL-Pi到底在解决什么问题1.1 一个被忽视的真相Agent的能力上限不取决于模型本身过去一年我参与过好几个Agent项目的落地从客服工单自动分类到代码仓库的自动化巡检踩过的坑几乎都指向同一个结论决定Agent最终表现的往往不是底层模型有多强而是包裹在模型外面的那层壳设计得够不够聪明。这个壳在NVIDIA这篇SoL-Pi研究里被正式命名为Harness。先把概念对齐一下因为热词里harness和agent区别、skill和agent的区别这类搜索量一直很高。用一句话说清楚Agent是谁来做这件事Harness是用什么工具、按什么流程、在什么约束下做这件事。模型是大脑Harness是手脚加上工作手册。同一个大脑配不同的手脚和工作手册干活效率能差出好几倍。SoL-Pi这个标题里的自优化是关键词。传统做法是工程师手动调Harness——改改提示词、换换工具调用顺序、调调重试策略全靠人肉试错。SoL-Pi的思路是让Harness自己迭代自己通过一套自我评估和搜索机制自动找到更优的配置组合。这背后的动机很实在Agent的任务空间太大了人工调参的边际收益递减得厉害而且每次模型升级之前调好的Harness可能又得推倒重来。1.2 四个答案分别对应哪四类痛点标题说四个答案我理解这是NVIDIA给出的四条自优化路径分别对应Agent Harness优化中最常见的四类瓶颈。虽然原始材料没有展开细节但结合Agent工程的通用实践这四类痛点基本可以锁定为提示与指令层面系统提示词、任务分解模板、输出格式约束的自动搜索与改写工具与动作层面工具集的选择、调用顺序、参数填充策略的自动调整控制流层面重试逻辑、分支判断、终止条件的自动优化评估与反馈层面如何自动判断一次执行好不好并把信号回传给优化器这四层是递进关系。提示层最轻改起来快但天花板低控制流层最重改起来慢但收益大。SoL-Pi的价值在于把这四层纳入一个统一的搜索框架而不是各调各的。提示如果你正在做Agent开发先别急着上自优化。把Harness的这四层手动拆开看看哪一层是当前瓶颈再决定要不要引入自动化。很多项目其实卡在第一层提示词写清楚就能解决大半问题。1.3 谁该关注这个方向三类人值得花时间研究SoL-Pi这类工作。第一类是Agent应用开发者尤其是那些发现换个模型效果就崩的团队说明你的Harness和模型耦合太紧需要更鲁棒的优化方法。第二类是Agent框架的维护者比如做编排引擎、做工具注册中心的自优化能力会成为框架的差异化卖点。第三类是评测与安全方向的同学因为自优化意味着Harness会自己改自己怎么保证改完不出安全问题是个新课题——热词里agent安全和a-memguard的出现不是偶然。2. Harness自优化的核心机制拆解2.1 为什么是搜索而不是训练这里有个容易混淆的点。很多人一听自优化第一反应是微调模型。但SoL-Pi这类工作优化的是Harness不是模型权重。原因很直接模型微调成本高、周期长而且一旦模型版本更新微调成果可能作废。Harness是代码和配置搜索空间虽然大但每次评估成本低迭代快。打个比方模型是一台发动机Harness是传动系统和驾驶策略。你想让车跑得更快调传动比和换挡时机比重新设计发动机划算得多。SoL-Pi的搜索机制本质上是在传动系统和驾驶策略的空间里找最优解。搜索的具体形式常见的有几种离散搜索从候选提示词模板、工具组合里挑、连续优化调温度、调重试阈值这类数值参数、基于反馈的迭代用执行结果作为奖励信号逐步改进。SoL-Pi大概率是混合式的因为Agent Harness的参数既有离散的也有连续的。2.2 自优化的评估信号从哪来这是整个链条里最难的一环。你要优化就得知道什么是好。但Agent任务往往没有标准答案比如帮我调研一下竞品怎么打分常见的评估信号来源有这么几类我按可靠性从高到低排信号类型来源可靠性适用场景硬性结果校验代码是否跑通、API是否返回200高有明确成功标准的任务规则打分关键词覆盖、格式合规、步骤数中结构化输出任务模型评判用另一个模型给结果打分中低开放式生成任务人工反馈标注员打分高但贵冷启动阶段隐式信号用户是否采纳、是否重试低线上真实场景SoL-Pi的自优化要成立必须解决评估信号的自动化问题。我的判断是它采用了多信号融合硬性校验打底模型评判补充再配合一些启发式规则。这样既能覆盖大部分场景又不至于完全依赖不可靠的单一信号。注意模型评判有个隐蔽的坑——评判模型和被优化模型如果是同一个会出现自己觉得自己好的偏差。实操中建议评判模型换个家族或者至少换个版本。2.3 四个答案的层次关系回到标题的四个答案。我倾向于把它们理解为一个从局部到全局的优化阶梯第一层是指令级自优化。自动改写系统提示词、任务模板、few-shot示例。这一层改动最小见效最快但容易过拟合到特定任务。第二层是工具级自优化。自动决定用哪些工具、按什么顺序调、参数怎么填。这一层开始涉及执行逻辑收益明显但搜索空间大。第三层是流程级自优化。自动调整控制流比如什么时候重试、什么时候换策略、什么时候放弃。这一层最接近Agent自己学会怎么干活。第四层是元级自优化。优化优化器本身——用什么评估信号、搜索步长多大、什么时候停止。这一层是SoL-Pi区别于普通AutoML的地方。这四层不是必须全上。小项目做到第一二层就有明显收益大项目才需要往三四层走。关键是别跳级第一层没调好就上第四层纯属浪费算力。2.4 和现有Agent框架怎么结合热词里deepseek harness、harness engineering、阿里 harness creator skill这些词说明Harness这个概念正在被各种框架吸收。SoL-Pi的思路可以嫁接到现有框架上但要注意接口设计。我的建议是把Harness抽象成可序列化的配置对象。提示词、工具列表、控制流参数全部用结构化格式JSON、YAML都行描述。这样自优化器才能读写、才能搜索。如果你的Harness散落在代码各处硬编码在if-else里那自优化无从谈起。这一步是很多团队卡住的地方。他们想上自优化但发现自己的Agent代码根本没法被程序化修改。所以先做Harness的配置化改造再谈自优化顺序不能反。3. 落地实操从零搭一个可自优化的Harness3.1 第一步把Harness配置化假设你有一个简单的调研Agent原本的代码可能是这样写的def run_agent(task): prompt 你是一个调研助手请帮我调研 task result llm.call(prompt) if 失败 in result: result llm.call(prompt 请重试) return result这段代码里提示词、重试逻辑都是硬编码的。要自优化先改成配置驱动harness_config { system_prompt: 你是一个调研助手请帮我调研{task}, tools: [web_search, summarize], max_retries: 2, retry_prompt_suffix: 请重试并注意准确性, stop_condition: result_contains_answer } def run_agent(task, config): prompt config[system_prompt].format(tasktask) for i in range(config[max_retries] 1): result llm.call(prompt, toolsconfig[tools]) if check_stop(result, config[stop_condition]): return result prompt prompt config[retry_prompt_suffix] return result改完之后harness_config就是一个可以被程序修改的对象。自优化器的工作就是搜索这个字典的最优取值。3.2 第二步定义搜索空间和评估函数搜索空间要明确每个参数的可选范围。别一上来就全开先挑影响最大的几个search_space { system_prompt: [ 你是一个调研助手请帮我调研{task}, 你是一个严谨的调研专家请分步骤调研{task}, 请以结构化方式调研以下主题先列大纲再填充{task} ], max_retries: [0, 1, 2, 3], tools: [ [web_search], [web_search, summarize], [web_search, summarize, fact_check] ] }评估函数是核心。我一般用加权组合def evaluate(result, task, referenceNone): score 0 score 0.4 * format_score(result) # 格式合规 score 0.3 * relevance_score(result, task) # 相关性 score 0.2 * completeness_score(result) # 完整性 score - 0.1 * len(result) / 1000 # 惩罚冗长 return score权重怎么定看你的业务最在意什么。客服场景格式权重高调研场景完整性权重高。没有万能权重只有适合当前任务的权重。3.3 第三步跑搜索循环最简单的搜索是网格搜索但组合爆炸很快。实操中我推荐先粗后细import itertools best_config None best_score -float(inf) # 粗搜只搜提示词和重试次数 for prompt, retries in itertools.product( search_space[system_prompt], search_space[max_retries] ): config {system_prompt: prompt, max_retries: retries, tools: [web_search]} score run_and_evaluate(config, eval_tasks) if score best_score: best_score score best_config config # 细搜固定最优提示词搜工具组合 for tools in search_space[tools]: config {**best_config, tools: tools} score run_and_evaluate(config, eval_tasks) if score best_score: best_score score best_config config这个流程跑下来通常能比初始配置提升20%到40%的效果。具体提升幅度取决于初始配置有多烂——初始配置越随意提升空间越大。3.4 第四步加一层安全护栏自优化最大的风险是优化出一个在评测集上高分、在真实场景里闯祸的Harness。比如它可能学会不管问什么都回答已完成因为格式分高。护栏至少要有三层硬性规则拦截输出必须包含某些关键信息否则直接判负分布外检测如果优化后的Harness在训练任务上表现异常好但在留出任务上崩了说明过拟合回滚人工抽检每轮优化后抽10%的结果人工看发现异常立即停止实操心得我一般会保留一个金标准任务集不参与优化只在每轮结束后跑一遍。如果金标准分数下降不管优化集分数多高都回滚。这个习惯帮我避免了好几次优化到沟里的事故。3.5 参数选择的经验值跑过几轮之后我总结了一些经验值供参考参数建议范围说明搜索轮次3-5轮再多边际收益很低每轮评估任务数20-50条太少噪声大太多太慢重试次数上限2-3次超过3次基本是任务本身有问题工具数量上限5个以内工具太多模型会乱选提示词候选数5-10个太多搜索慢太少覆盖不足这些数字不是铁律但作为起点能省不少试错时间。4. 常见问题与排查技巧实录4.1 优化后效果反而变差怎么办这是最高频的问题。原因通常有三个评估函数有漏洞、搜索空间设计不合理、评测集和真实场景分布不一致。排查顺序先看评估函数把优化后的Harness在几个典型任务上手动跑一遍看它的输出是不是钻了评估函数的空子。比如评估函数只看格式它就可能输出格式完美但内容空洞的结果。再看搜索空间是不是某些参数的候选值本身就不好。最后看评测集是不是评测集太简单或太偏。我的经验是80%的优化变差都是评估函数的问题。评估函数写得好优化很难跑偏。4.2 搜索太慢跑不动Agent执行本身就慢搜索又要跑很多轮很容易卡住。加速手段有几个并行评估不同配置之间没有依赖可以并发跑缓存相同配置在相同任务上的结果缓存起来避免重复执行早停某个配置在前几条任务上就很差直接淘汰不用跑完小模型代理用便宜的小模型先粗筛筛出来的配置再用大模型精评我用过最有效的是早停加缓存能把搜索时间压到原来的三分之一左右。4.3 优化结果不稳定每次跑都不一样Agent本身有随机性加上搜索过程也有随机性结果波动很正常。降低波动的方法固定随机种子模型调用能设seed就设多次评估取平均每个配置跑3次取均值而不是跑1次增大评测集评测集越大单次波动影响越小如果波动还是很大说明任务本身方差就大这时候追求最优配置意义不大不如追求稳定不崩的配置。4.4 常见问题速查表现象可能原因排查方向解决思路优化后分数高但人工看很差评估函数被钻空子检查评估维度是否单一增加多维度评估加人工抽检搜索跑了几小时没结果搜索空间太大看组合数先粗后细加早停换模型后优化结果失效Harness和模型耦合看提示词是否模型特定用更通用的提示词重新搜索优化后Agent变慢工具调用变多看工具调用次数给工具数量加惩罚项优化后偶尔报错边界情况没覆盖看错误日志评测集加入边界case4.5 几个容易踩的坑坑一评测集泄露。优化用的任务和最终验收用的任务如果重叠分数会虚高。一定要严格划分。坑二过度优化提示词。提示词优化到极致往往变得又长又怪换个模型就废。保持提示词简洁通用比追求极致分数更重要。坑三忽略成本。自优化本身要花算力如果优化带来的收益抵不上搜索成本就不划算。小项目手动调调就行别硬上自优化。坑四忘了版本管理。每轮优化后的Harness配置要存档出问题能回滚。我见过团队优化了半天结果发现还是第一版最好但第一版配置没存只能重跑。5. 这套思路能扩展到哪些场景5.1 从调研Agent到代码Agent调研Agent的Harness优化思路几乎可以原样搬到代码Agent上。区别在于评估信号更硬——代码能不能跑通、测试过不过这是天然的硬性校验。所以代码Agent的自优化反而更容易做因为评估可靠。我试过给一个代码修复Agent做Harness自优化搜索空间是提示词模板重试策略是否先跑测试。跑了几轮之后最优配置是先跑测试定位失败点再针对性修复失败重试时附上错误日志。这个策略人工也能想到但自优化帮我确认了它确实比直接让模型改好。5.2 多Agent协作场景单Agent的Harness优化清楚了多Agent就是把它乘以N再加上通信协议的优化。复杂度上来了但思路一致把每个Agent的Harness配置化把通信协议也配置化然后搜索。多Agent场景有个额外的好处Agent之间可以互相评估。A的输出给B用B能不能顺利接上本身就是个评估信号。这比单Agent自己评自己可靠。5.3 和记忆系统的结合热词里agent记忆和a-memguard值得单独说。Agent的记忆系统本质上也是Harness的一部分——记什么、怎么记、什么时候取都是可优化的。SoL-Pi的思路可以扩展到记忆策略的搜索上。但记忆系统有个特殊风险记忆污染。如果Agent把错误信息记下来后续会一直受影响。所以记忆相关的自优化安全护栏要更严最好加一层记忆审核再写入。5.4 什么时候不该用自优化不是所有场景都适合。以下几种情况手动调更划算任务种类极少就一两种任务人工调几次就到位了评估信号极不可靠没法自动判断好坏自优化无从谈起算力预算紧张搜索本身要花钱预算不够就别硬上上线时间紧自优化需要迭代周期赶工期就手动调我的判断标准是如果手动调参的时间成本超过自优化搜索成本就上自优化否则手动。这个账要算清楚别为了技术而技术。6. 我个人的几点实操体会折腾Agent Harness优化这段时间最大的体会是自优化不是银弹它放大的是你评估体系的质量。评估体系好自优化如虎添翼评估体系烂自优化就是加速跑偏。所以与其花时间研究多花哨的搜索算法不如先把评估函数打磨好。第二个体会是配置化改造的价值被低估了。很多团队卡在想优化但代码改不动。其实把Harness配置化这一步即使不做自优化对代码可维护性的提升也是巨大的。我现在的习惯是任何Agent项目第一件事就是把Harness抽成配置对象这个习惯让我后面省了无数事。第三个体会关于节奏。自优化适合在项目中期做不适合一开始就做。项目初期任务定义还在变优化出来的配置很快作废。等任务稳定了再上自优化收益才实在。最后分享一个小技巧保留一份人类基线配置。就是你自己手动调出来的、你觉得最合理的配置。自优化的结果如果比人类基线还差说明评估或搜索有问题直接回退到人类基线。这个基线是你的安全网别省这一步。