NVIDIA公开的SoL-Pi研究我看了好几遍之后的第一反应不是又一篇Agent论文而是终于有人把Agent Harness自优化这件事当正经课题来做了。过去一年我见过太多团队在Agent链路上折腾调Prompt、换底座模型、加工具结果成功率始终卡在七八成上不去。他们没意识到的是大部分失败并不发生在模型懂不懂的层面而是发生在外面那层Agent Harness——上下文怎么拼、工具怎么选、重试条件怎么定、轨迹怎么回流——这些框架层的问题模型再强也救不回来。这篇文章就用工程视角拆解SoL-Pi所回答的四个核心问题适合正在做Agent平台、智能体框架或者被Prompt调优折磨到怀疑人生的团队。我尽量把论文思路还原成实际能落地的设计不堆术语。1. Harness不是Agent先把自优化的对象搞清楚很多团队连口头上都区分不清楚Agent Harness和Agent更别说在系统设计上把它们当成两个独立层次了。我在不少代码评审里看到的典型结构是一个Agent类里面塞了Prompt模板、上下文组装、工具调用、重试逻辑、记忆读写乱七八糟混成一团。这种代码写出来的时候挺爽但一旦要优化根本不知道改哪里。从概念上理清楚这三层是不一样的底座模型做语义理解和生成是大脑。Agent做任务规划、拆解、决策决定下一步要调用什么是军师。Agent Harness负责把模型的输入输出、工具调用、外部流程这些内容编排起来是操作系统。层级主要职责典型组件出错表现底座模型语言理解与生成LLM/TTS等答非所问、幻觉Agent任务规划与工具决策规划器、工具选择策略路线错误、工具选错Agent Harness执行编排与运行控制Prompt模板、上下文窗口管理、重试、日志、记忆读写上下文截断、重试死循环、工具返回不解析SoL-Pi研究的巧妙之处在于它把Agent Harness当成了可以主动优化的对象而不是一条写死的执行链路。传统做法是模型效果不好就换模型Agent规划不对就改Prompt但很少有人回过头去改那个承载了Agent的外壳——比如上下文修剪策略、工具描述排序、重试开关、甚至整个任务流程的跳转逻辑。为什么先说这个因为四个答案里所有的自优化优化对象都不是模型参数而是Harness层的配置和策略。这件事的本质是模型参数一改需要全量回归、要重新部署、推理成本可能剧增但Harness配置是文本、规则、结构化数据改动成本低、可解释性强、出问题可以秒级回滚。所以自优化的收益和风险边界都被刻意放在了Harness这一层。SoL-Pi的自优化闭环大致是这么一条链路执行并记录轨迹 → 评估成功与失败原因 → 生成Harness的修改建议 → 通过离线回归与影子评估 → 部署到部分流量 → 继续收集数据。这套闭环本身并不新鲜新鲜的是它把修改建议的作用对象从底层模型转移到了Harness。后面四个答案正好对应这条闭环里最关键的四个环节。2. 第一个答案把执行轨迹变成优化信号而不是只拿来排查故障几乎每个做Agent的团队都会记录日志但绝大多数日志只有在线上出了事故才派上用场。SoL-Pi的思路是执行轨迹是harness自优化最重要的训练材料别只当故障排查工具用流量每跑一次都应该让harness变得不那么笨。具体怎么做先把一件容易被混淆的事情分开轨迹成功和任务成功不一定画等号。任务可能最终返回了一个看起来合格的结果但中间绕了五个工具、重复检索三次这种轨迹是结果正确但过程失败。反过来任务虽然失败了中间某几个子步骤的决策可能很清晰不能全盘丢进负面样本。所以在心态上要接受轨迹数据是混合矿石必须经过筛选和提炼。落到工程上我建议按下面这套流程处理轨迹抽取从harness运行时日志里把每轮对话、每个工具调用、每次重试、每次上下文修剪的节点都标准化成轨迹记录。解析把轨迹映射成步骤序列至少包含步骤类型、入参出参、耗时、成本、是否报错、是否重试。过滤用规则加模型双重判断这个轨迹的过程质量。规则负责抓硬问题比如某个工具调用连续失败三次模型负责评价软问题比如是否走了不必要的步骤。聚类将同一类失败的轨迹归组。先看模式再决定怎么改harness而不是拿到一条失败轨迹就急着改。重写与验证从成功轨迹里抽取优质片段作为harness的few-shot示例或工具描述补充从失败轨迹里提炼反模式作为后续评估集的负例。有一个执行轨迹的例子很典型任务是要查询某个政策条款的最新生效时间。成功轨迹用了两步先检索政策库再访问官方公告页确认。失败轨迹却先调用了通用搜索翻页三次然后才去政策库最后还tm因为上下文被搜索页塞爆而发生截断最终输出幻觉。这种案例我评估的时候几乎天天见——问题根本不在模型能力而是harness的流程选择没有引导Agent先走高置信度工具。轨迹要想成为候选优化依据还需要给轨迹打版本标签。我会在每一条日志里记录三个版本号模型版本、Prompt版本、Harness配置版本。没有版本信息的轨迹后面做回归集和策略评估时只能当废数据。不少团队踩过这个坑日志攒了一堆一提数据召回就傻眼因为不知道某条成功轨迹在哪个配置组合下产出的。额外提醒一点别拿失败轨迹直接当负面样本喂给harness做策略调整原因很简单——LLM生成的失败轨迹往往只是最终结果不对但中间一步可能已经把答案推到了正确答案附近。粗暴地给整条轨迹打负分会把正确的局部决策一起惩罚掉。所以我的习惯是先把失败轨迹中的局部动作拆出来再判断哪个环节需要替换。3. 第二个答案让Critic模型负责给Harness写差评并直接生成修改建议自优化的核心难点不是跑而是怎么知道哪里该改。SoL-Pi给出的第二个答案是引入一个Critic模型把人工写Prompt优化建议的工作自动化。LLM-as-a-Judge这个概念大家都不陌生但很多团队的强应用场景只是给最终回答打个分。SoL-Pi的Critic不一样它评的不只是最终答案而是harness执行链路的整体表现。我梳理了一下至少应该从下面五个维度打分信息完整性最终回答是否遗漏了任务要求的关键信息点。工具利用效率是否调用了不必要工具是否本可以用更便宜的工具。流程正确性步骤先后顺序是否合理是否过早结束导致信息不足。最终答案质量格式是否规范、推理是否有断点、是否包含幻觉。成本与延迟总token数、工具调用次数、p95耗时的实际花费。Critic的输出不能是几百字小作文而应该是结构化的judgment。最佳实践是固定JSON Schema至少包含总体评分、各维度分数、问题定位具体到第几步、以及最重要的——harness层面的修改建议。这一步很关键因为如果Critic只会说这个回答不好那它的价值跟一个简单评分器没区别要让它说第二步的工具选择不对应该改为先查询内部知识库上下文窗口在第三步触发了截断建议将前置摘要策略提前这才是harness能执行的优化指令。实际操作中我有三点经验第一Critic要跟优化器解耦。Critic只负责评价和给建议真正动手生成新harness配置的是另外一个优化器模型。如果Critic同时负责修改就会陷入自我确认偏误它已经把链路评坏了还得靠它改好很难跳出自己的局限。分开之后至少可以让不同模型互相制约。第二Critic的评价标准要定期人工校准。自优化系统最怕出现feedback loopCritic发现verbose的回答分高模型就越写越长下一个版本Critic继续给长答案高分最后系统体积膨胀到没人愿意用。我见过一个团队用LLM judge做A/B评估评估集只有五十条新配置比旧配置高0.3个百分点就上了生产结果线上成本翻倍。这种诡异的循环只能靠人工抽检来打断——我一般要求每周抽五十条Critic判定结果让业务方复核不一致率超过10%就停用下一轮的自动更新。第三Critic使用的评估集要有足够的规模和质量。五十条远远不够至少要两三百条覆盖典型场景并且要提前区分Easy/Hard/Normal三档。自优化系统有个隐性惰性它倾向于把普通的case优化得很漂亮但在hard case上原地踏步因为优化hard case太费劲了。如果你不把hard case单独拎出来卡指标系统就会悄悄退化成只会做简单任务的高级计算器。4. 第三个答案把工具路由和流程选择做成动态策略而不是一写定终身Agent Harness里最容易被忽视的自优化对象是任务流程怎么走这件事。绝大多数团队的Harness里都是写死的所有请求进来先做Plan再一步一步调用工具最后汇总输出。这种线性结构在Demo里没问题放到真实业务里就很浪费——简单问题被过度处理复杂问题处理链路又不够深。SoL-Pi的第三个答案是把工具路由和流程选择这个决策本身变成一个可以持续更新的策略。直白点说Harness要能在多个候选流程之间自动选路流程A直接推理。适合问题简单、答案大概率在模型参数内、不需要外部事实核验的场景。流程B单次检索增强。适合事实型问题比如查政策、查价格、查规格检索一次就够。流程C多轮检索加反思。适合多跳推理、需要交叉验证的问题比如对比不同条款、整合多份报告。为什么要动态选而不是干脆都用最长的流程C因为成本和时间不是免费的。所有请求都走流程C成功率可能确实高那么两个点但单次推理成本翻三四倍延迟从两秒变成十秒落到真实业务里非常难看。所以正确的做法是把流程选择当成一个上下文Bandit问题每次请求进来系统根据任务特征问题长度、是否包含数值、涉及领域、用户意图复杂度和历史成功率从多个流程里挑一个执行然后根据执行结果更新策略。实现的时候我不建议一开始就上深度强化学习。先从上下文Bandit或者简单的策略树开始效果足够解释性还强。特征也不要搞太复杂就用任务类型、工具类型、上下文窗口用量、历史成功率几项。等积累的数据足够多了再考虑升级到序列决策模型。这里有一个特别容易踩的坑工具列表和流程列表是动态变化的但策略不能绑定到工具ID上。你今天有五个工具下个月加了第六个如果策略学的是每次必须调用工具A再调工具B新工具加进来之后策略就失灵了。我的做法是给工具做能力画像比如能不能联网能不能查数据库是不是高成本慢工具让策略基于能力类型而不是具体工具ID做选择。这样工具版本升级、新增替换都不会让历史学到的策略白废。另一个实践心得是探索率。上线一个新工具之后如果自优化策略只按历史成功率选路新工具永远没有机会被尝试也就永远不知道它好不好。所以在自优化系统里必须保留一定的探索流量比如5%的请求允许策略去尝试非最优的流程或新工具。没有这5%的探索系统优化到最后一定是个局部最优的死胡同。这个答案对工程架构的直接影响是Harness不能再是if-else堆出来的代码而要变成配置驱动的执行引擎。每个候选流程本身是一个可复用的DAGHarness根据策略选择一个DAG实例来执行。这样策略更新和流程编排才是解耦的策略说这次走流程BHarness就去实例化流程B而不是修改代码重新发版。5. 第四个答案评估门控与自动回滚给自优化装上安全阀自优化系统最大的风险不是优化不动而是越改越差但没人发现。没有门控的自优化就是在生产环境做一个没有测试的持续部署早晚出事故。SoL-Pi第四个答案提到的评估门控与回滚机制是整条链路里我最看重的部分因为能不能在一个真实业务里跑起来取决于这里。我把门控机制拆成四层每一层都有明确职责离线回归集准备一份固定代表真实业务场景的数据集大约三百到五百条覆盖简单、正常、困难三档。任何候选harness配置必须先在这份回归集上跑出不低于当前配置的成绩成功率、成本上限、延迟p95否则直接淘汰。影子运行把新配置部署到影子环境让它跟线上配置同时处理真实流量但影子结果不返回用户。通过比较影子结果和线上结果知道新配置在真实流量上是不是真的更好。这最耗算力但也是最能避免事故的一层。灰度放量先放1%流量观察一小段时间再逐步放到10%、50%、100%每个阶段都对照线上基线看指标变化。自动回滚当指标达到红线的候选配置必须自动回滚本质上不是修改代码而是切换配置版本。关于评估指标我建议使用一个四指标的融合体系避免单一指标绑架系统指标计算方式红线设置建议任务成功率成功任务数/总任务数低于当前基线2个百分点必须回滚工具效率平均每任务工具调用次数高于基线1.5倍需要人工确认单任务成本总token成本API调用成本/任务数高于预算上限直接拦截P95延迟最长5%请求的耗时超过SLA阈值自动降级这套组合核心考虑了成本和成功率之间的权衡。如果只盯成功率系统很容易为了看起来成功多走几步、多调几个工具成本悄然升高。只有把成本、延迟也设为硬约束才不会让自优化变成花钱买成功率。回滚机制有一个细节要在架构上提前考虑Harness配置必须版本化。每次自优化生成的新配置都应该像Git提交一样有一个stamped version包含配置全文、父版本号、上线时间、下线时间、评估报告。我以前见过一个团队配置存在云数据库里谁都能改改完也不留历史结果某天一个prompt更新导致线上大面积报错花了整整半天才人工翻出上一版配置。从那之后我强制要求所有Harness配置的修改走版本控制。回滚只是切换版本不需要重新部署模型或发布服务这就是把优化对象放在Harness层的巨大红利。离线回归集还有一点要小心警惕数据泄漏。如果你的回归集来自历史日志而这些历史日志是旧Harness跑出来的那条旧链路里的坏习惯会被新配置学走。最典型的例子是旧配置遇到复杂问题习惯先问用户澄清回归集里也就充满了先澄清再回答的成功案例新配置也会倾向多轮澄清而不是自主推理。所以回归集要定期人工审核、加入新发现模式不能一个集合用半年。6. 从论文到工程我落地自优化Harness时会按这个顺序做如果把SoL-Pi当成一套可以直接抄下来的方案会摔得很惨。我的判断是它的价值更多是给出了一个自优化Harness的方向和边界条件具体到每个团队还要结合自己的链路情况来设计。但如果让我从零搭建一套类似的系统我会按下面这个顺序来做。阶段一只做可观测性不碰自优化。先把执行轨迹完整地记录下来。这一步没有技术难度但要求日志设计得非常细致每个环节的入参出参、耗时、成本、版本号、重试次数、上下文截断位置。我甚至建议做一个trace viewer让工程师可以可视化地回放任何一条任务的执行链路。这个阶段预计一到两周但它决定了后面所有工作的上限。阶段二离线闭环。从日志里抽轨迹建设离线评估集引入Critic模型让Critic对历史轨迹批量打分并生成harness修改建议。这个阶段不做线上自动更新而是人工审核Critic给出的建议确认能改再手动合入。这样做的好处是你能在低风险环境下快速观察Critic的建议质量。阶段三影子与灰度。离线闭环稳定了再上影子模式影子跑一到两周确认新配置与线上基线相比真的有收益再进入灰度。要不要走到自动更新这一步我建议分团队情况来看如果你的业务对错误容忍度低比如金融、医疗灰度期间人工审核要保留很久如果你的业务本来就允许带病迭代可以逐步放开自动更新。阶段四策略化流程选择。前三步跑通之后再尝试把工具路由和流程选择做成动态策略。这里我强烈建议先做流程级Bandit就是横向上先支持多功能DAG切换不要一上来就做动作级的复杂RL。每一步都保持可解释出问题能说清楚为什么切换到了流程B。落地过程中对团队配置的建议是三人最小小组一个框架工程师负责Harness和日志改造一个算法工程师负责Critic和策略一个业务应用owner负责提需求、审核评估集和最终验收。如果只靠一个全栈工程师硬扛大概率会在影子阶段消耗完热情。还有一个容易被低估的细节初始Critic的Prompt要写得挑剔一点。如果你让Critic从多个维度综合评价它会倾向于给中等偏上的分数导致自优化系统提前收敛到平庸状态。我的习惯是让Critic先假定链路有缺陷先找问题再找亮点打分分布自然拉开。另外数据侧要把合规和脱敏纳入设计。Agent轨迹里经常混着用户对话、业务数据、工具返回内容直接拿去喂给Critic或训练优化器会有数据安全风险。我见过不止一个团队在推进自优化时忽略这件事最后法务一票否决。正确做法是在日志入库阶段做字段级脱敏敏感字段只留存脱敏后的hash值这样后续做离线优化时心里才踏实。个人体验是SoL-Pi这类研究最值得学的不是某个具体模块而是先在框架层找收益的思维方式。很多团队遇到效果问题第一个想到换模型但从投入产出比看先优化Agent Harness的门槛更低、反馈更快、回滚风险更小。你在框架层每优化一步后面换模型、加工具、扩场景时都会跟着受益。这套思路放到任何一个自研Agent系统里都值得先照着阶段一试一试。
