看到NVIDIA这个SoL-Pi研究标题时,我第一反应是——这不就是每个做Agent落地的人都迟早要撞上的那堵墙吗Prompt写了几百版,工具链接了一大堆,效果还是忽好忽坏;日志翻了几千行,根本说不清问题出在模型、上下文还是工具调用;好不容易调好一版策略,换个场景又得从头再来。如果你也在搞Agent开发,这四个字你多半绕不开Agent Harness,翻译成大白话就是“Agent外面那层架子”——负责给大模型配上下文、选工具、管执行、做反馈的那一层系统。很多人以为Agent的效果全看模型多聪明,真正上过生产的人会告诉你模型的底座能力固然重要,但上面那层Harness怎么设计,往往才是决定系统能不能稳定跑起来的关键。SoL-Pi这篇研究的核心,用一个通俗的说法来概括,就是“让Harness学会自己给自己做优化”。它没有去讲怎么换更强的大模型,而是把注意力放在了一套可以持续自我改进的框架上。研究中提到的“四个答案”,对应的是Agent系统自优化绕不开的四个维度上下文怎么管理、工具怎么选、报错之后怎么恢复、好坏用什么标准来评估。这篇文章我就把这四个答案掰开揉碎,结合我在真实Agent项目中踩过的坑和验证过的做法,一条一条讲清楚为什么这些问题这么要命、自优化该怎么设计、以及落地的过程中有哪些文档里不会告诉你的细节。1. 先搞清楚问题Agent Harness到底卡在哪1.1 “Harness”不是提示词也不是模型本身很多刚开始做Agent的人都有个误区以为Agent 模型 Prompt。真做了几个项目你就知道,这类系统跑起来之后,真正在背后忙前忙后的其实是那层“调度壳”。它要决定这轮对话该带哪些历史记录进去,要判断用户这次请求应该调哪个工具,要接收工具的返回结果再决定下一步动作,还要处理整个流程里出现的各种异常情况。这层壳,就是行业里说的Harness。Harness这个名字,直译过来是“背带”“安全带”,挺形象。你可以把模型想象成司机,Harness就是那套仪表盘、踏板和辅助驾驶系统——司机技术再好,仪表盘该亮红灯的时候不亮,方向盘该反馈的时候没反馈,车子一样开不稳。模型负责的是“思考和生成”,Harness负责的是“流程怎么走、资源怎么配、异常怎么兜”。Prompt解决的是“你好好干”,Harness解决的是“你想干也干得成”。这也是为什么我越来越觉得,Agent项目的上限由模型决定,下限却由Harness决定。你给一个能力很强的模型喂一锅乱炖的上下文,它也能给你输出一堆错漏百出的内容相反,如果Harness把上下文梳理得清清楚楚,工具调用分工明确,即使模型能力稍微弱一些,整体表现依然可以稳定在可用线之上。SoL-Pi研究的落脚点,恰恰就是这层下限——它不赌模型能变得多聪明,而是赌框架能不能通过自优化让同样的模型发挥出更稳定的战斗力。1.2 四个答案对应的四个痛点研究里讲的“四个答案”,拆开来看其实是四个在生产环境中反复出现、又极难靠人工硬调解决的痛点。第一是上下文管理的失控。Agent跑久了,历史记录越堆越多,相关和不相关的信息搅在一起,模型抓不住重点。你手动去截断吧,又很容易把关键信息一刀切掉。第二是工具选择的迟钝。工具接得越多,模型越容易选错工具说明写得越长,占的上下文就越多,反过来又加剧了第一个问题。第三是错误恢复的机械。程序报错了就重试,重试还不行就报给用户,这套逻辑在简单任务里勉强能用,在复杂的多步任务里就是一场灾难。第四是评估反馈的缺失。改了一版Prompt或调整了一次调度策略,到底变好了还是变差了,很多时候靠肉眼抽查完的几个样本,根本得不出可靠结论。这四个问题盘根错节,单独拎出来每一个都够写一篇论文,而SoL-Pi把它们的解法统一到了一个“自优化”的框架下面。下面我按照实际项目中最常见的切入顺序——先治上下文,再理顺工具,然后解决报错恢复,最后建立评估闭环——把这四个答案逐一说透。2. 答案一上下文管理自优化——让记忆“用进废退”2.1 原始做法为什么不行上下文窗口再大,也架不住Agent在长期任务里不断堆叠信息。早期我做过一个偏文档处理的Agent,每个步骤都要读文件、抽取字段、生成中间结果,跑不到十步,上下文就快被撑爆了。一开始我用的办法非常简单粗暴把最早的对话记录直接丢弃。结果呢前面已经抽取的重要字段后面还要用到,丢掉之后模型只好靠猜,输出的内容一次比一次离谱。后来我又试过“简单摘要”:每过几轮就把前面的对话用模型压缩成一小段。问题是摘要本身要额外消耗token和时间,而且压缩的过程中细节一定会丢,丢失的又往往是后面真正需要的那部分信息。还有一类做法是“固定窗口”,只保留最近N条消息,这在短对话场景下还能凑合,一旦任务牵扯到多个阶段,前面阶段产生的关键结论随着窗口滚动就没了。这些做法的共同病根在于上下文的选择逻辑是手工定的、静态的,它对所有消息一视同仁地“一刀切”。但真实的任务场景里,信息的价值从来不是均匀分布的。某个步骤里的一句话,可能在十步之后仍然是决定成败的关键而另一些看起来很长很详细的中间结果,用完之后就是纯噪音。静态策略做不到这种区分,自然也就无法避免“该丢的没丢,不该丢的丢了”。2.2 自优化思路:动态预算与信息分级SoL-Pi的上下文自优化,核心思路可以概括成一句话让Harness自己学会判断信息的重要性,并据此动态调整上下文的构成。具体拆开,我认为有三个可以落地的层次。第一个层次是“动态预算”。不再固定“保留最近十轮”这种死规则,而是给不同阶段的任务设定上下文预算,Harness在执行过程中根据任务复杂度、已消耗的token、当前所处的阶段来计算还剩下多少空间,再反过来决定哪些内容值得保留、哪些内容需要压缩。比如在任务初期,探索性的中间输出可以适当多留一点,方便模型建立全局认知到了任务后期,那些已经确认过的事实、最终决策依据,就必须占住优先位置。第二个层次是“信息分级”。把记忆信息分成几个层级可直接引用的原始内容、压缩过的摘要、以及可以被按需检索的外部缓存。原始内容是最贵的,只留给当前步骤真正需要的片段摘要负责提供背景和上下文衔接外部缓存则用来存储那些“可能有用但不一定用到”的信息,比如历史文档、过往任务的完整记录,需要的时候再临时调出来。这套思路和“寄存器—内存—磁盘”的存储层级异曲同工,目的就是让最贵的信息只在最需要的时候出现在最该出现的位置上。第三个层次是“让Harness自己决定什么时候压缩”。不是靠预设的轮数触发,而是让它根据信息的重要性变化去做判断。举个例子,当一次工具调用返回了一个很长的结果,Harness可以从中提取关键字段存入上下文,把原始返回内容转存到外部缓存当后续任务需要用到某个早期结论时,Harness先把原始记录调出来核对,再决定是继续引用还是重新推导。这套机制的落地并不复杂,关键是给Harness配备一套“信息管理工具”,让它把上下文当成一个可以动态读写的私有工作区来管理。2.3 实操建议:给Harness加一个“记忆审计”循环具体到代码层面,我建议在Harness里加一个轻量级的“记忆审计”流程,而不是一上来就整向量数据库这样的大件。每一步任务执行完之后,让Harness跑一次这个小循环检查当前上下文里有哪些内容已经使用完毕,对未来不再有价值标记哪些内容虽然目前没用上,但后续有较大概率需要统计这次调用的token消耗量,与预算做对比。然后根据这四项判断决定丢弃、压缩到摘要区、保留原样、还是迁移到外部存储。我在自己的项目里用了一个很简单的抽象,大概是这样在上下文中维护一张结构化的“记忆清单”,每条记忆对象都带有type、content、importance_score、last_access_time、usages这几个字段。Harness在每次工具调用完或者对话轮次结束后,更新这些字段的数值,再套一条规则或让模型做一次轻量判断,决定对哪些记忆做降级处理。这个设计看起来朴素,但效果非常显著。之前那个处理长文档的Agent,在加入记忆审计后,上下文的token消耗降了将近三分之一,而且最明显的变化不是省了多少钱,而是模型的输出稳定性大幅上升因为重要的字段再也不会随着历史窗口滚动被冲掉了。如果你正在做长流程Agent,我强烈建议先从记忆审计入手,它绝对是性价比最高的一个自优化点。顺便说一句,一开始不要设计得太复杂,先让Harness具备“读取、写入、压缩、丢弃”四类基本能力,跑通之后再逐步细化,比一次到位靠谱得多。3. 答案二工具选择自优化——工具多不是好事3.1 工具调用正在被“说明书”拖垮上下文问题治了,第二个坑马上就会接踵而至工具调用。很多Agent项目早期只有两三个工具,模型闭着眼睛都不会选错等工具列表膨胀到十几个、几十个的时候,问题就来了。你给每个工具写一段功能说明,模型选工具时就要把这些说明全部读进去,这不仅消耗token,更关键的是工具之间的边界会越来越模糊——两个工具看起来都能干某件事,模型选哪个全看说明文字的措辞,选错一次,后面的流程全乱。我见过一个很典型的现象工具列表越长,模型越倾向于“反复调用同一个被表述得最泛化的工具”,而不是根据具体情境选择功能最匹配的那个。比如明明有一个专用于“批量导出Excel”的工具,但模型的工具清单里也有一个“通用文件处理”工具,于是它每次都走通用路径,然后被通用工具内部的复杂逻辑折磨得输出一堆格式错误。问题不在模型,而在工具集合的设计——你没有让Harness帮模型做筛选,却把选择负担直接扔给了模型。还有一个隐蔽的问题工具调用失败的反馈没有被结构化地利用起来。一个工具连续失败很多次,说明它的可用性存疑,或者它与其他工具的职责边界定义有问题,但大多数Harness根本不会记录这层信息。模型下次面对同样的任务,还是会傻乎乎地优先尝试那个已经证明不可靠的工具。3.2 自优化思路:路由、合成与废弃工具选择的自优化,本质上要做三件事动态路由、按需合成、自动废弃。动态路由比较好理解。Harness在把任务交给模型之前,先根据对任务意图的初步识别,把候选工具范围从一个全局大列表缩小到一个相关的子集。你可以先做一个便宜的、规则或小模型驱动的预分类,把“查询天气”“发邮件”“读写数据库”这种大类意图分开,然后针对每个大类挂一套更精确的工具列表。这样模型在正式选择时面对的候选列表明显变短,选择准确率自然就上来了。这不是玄学,而是把“在20个工具里选1个”降维成“在3个工具里选1个”,任何模型的准确率都能明显改善。按需合成则更进一步既然手头没有完全匹配的工具,那Harness能不能自己“攒”一个临时工具出来这里不需要太复杂的想象力——几个基础API之间的组合调用、一个流程的模板化封装、一段可复用的Python函数脚本,本质上就是新的工具。SoL-Pi提到自优化时,一个亮点正是这种“工具即插即用”的思路Harness可以在运行过程中,把若干基础操作拼接成一个临时的复合工具,并把它的调用方式记录到自己的“工具库”里,下次遇到同类任务就直接复用。这意味着系统不是等到更新迭代时才能获得新技能,而是在实际任务中自己长出新的技能。自动废弃是很多人容易忽略的一点。我建议给每个工具在日志系统里建一个“调用档案”,记录成功次数、失败次数、平均耗时、错误类型分布。Harness定期分析这份档案,一旦发现某个工具长期低成功率,或者它与另一个工具的功能高度重叠,就会自动降低它的排序权重,甚至提示开发者把它下线或合并。这个机制的意义在于,工具集不再是静态的“藏品”,而是会随着真实使用数据不断“优胜劣汰”的活生态系统。3.3 实操建议:用日志数据驱动工具调优具体操作上,我强烈建议给工具调用加一层统一的“外套”。所有工具调用都走同一个入口,在入口处记录调用了哪个工具、传入什么参数、返回什么结果、耗时多长、是否报错、报什么错。不要小看这层包裹,有了它,你才可能去做上面说的路由分析和废弃判断。我在项目里就是从这层日志开始改造的。跑了大概一周之后,我用一段简单的汇总脚本拉出了工具调用榜单,发现排名很靠前的一个“通用文本处理”工具,成功率只有六成左右,而且它吃掉了一大半的工具调用次数。进一步看明细,发现其中至少两成调用应该走另一个“结构化提取”工具。后来我在Harness里加了一条路由规则凡涉及“从文档中抽字段”的任务,优先展示“结构化提取”工具,那个通用工具被降权处理。改动之后,这类任务的整体成功率从六成涨到了八成以上。整个过程没有任何Prompt技巧,纯粹就是把工具选择权从“模型全权负责”改成了“Harness先用数据做了层层筛选”。这里有一个需要注意的点工具说明的写法会影响路由效果。别在工具说明里堆砌形容词,比如“功能强大”“处理各种文件”,这种话对模型判断没有帮助,只会模糊工具边界。尽量用“当用户需要X时使用本工具输入参数为A、B输出格式为C若遇到D情况请报错”这种结构化的描述。Harness在做动态子集筛选时,也会更依赖这种结构化的说明来命中意图。4. 答案三错误恢复自优化——别只做“重试三次”4.1 Agent执行失败,远不止“网络抖动”Agent系统跑在生产环境,错误是常态而不是例外。API返回超时、第三方服务限流、工具返回的格式和预期不符、模型生成了根本不该作为参数传下去的内容,这些情况每天都在发生。问题不在于怎么避免错误,而在于Harness面对错误时的反应方式。大部分简单实现的Harness,错误处理逻辑只有一句话“重试,重试不行就报错给用户。”这套逻辑在单一接口调用场景下勉强够用,但在多步骤Agent里就是灾难般的体验。一个任务拆成五步,第三步报了错,直接把整个流程终结掉,前面四步的成果全部报废,用户拿到一个失败的最终结果,连问题出在哪都不知道。而且,无脑重试处理不了大多数真实错误——如果是参数传错了,重试一百次也还是错如果是模型自己理解错了任务,重试更不会让它突然开窍。更麻烦的是,错误之间会串联。第三步返回了一个异常结果,Harness没识别出来,照样把它当作正常输出丢给第四步,第四步的模型基于这个脏数据继续推理,产出一个看起来合理、实际上完全跑偏的结论。用户最后看到的是“成功”的结果,但结果的内容从一开始就是错的。这种错误比显式报错更难排查,因为它欺骗了包括Harness在内的所有环节。4.2 自优化思路:错误分类与策略匹配错误恢复的自优化,核心是让Harness不再把“错误”当作一件需要结束的事情,而是当作一条需要处理和反馈的信息。具体实施上,我建议先把错误做分类,不同类别配不同的恢复策略。第一类是“瞬时错误”,比如网络超时、限流、远端服务短暂不可用。这类错误重试是有意义的,但重试策略要跟上。不要固定重试三次,而是用“退避重试”第一次失败等几百毫秒再试,第二次等几秒,第三次等十几秒,同时可以切换备用通道或换个请求方式。第二类是“参数/格式错误”,说明Harness传给工具的东西不对,这时候再怎么重试都无效,应该回退到上一步,修正参数后重新执行,或者把参数构造逻辑交给模型重新推导。第三类是“逻辑错误”,模型理解了任务但路径不对,比如该查数据库的时候去调了文件API。这种情况Harness需要做的是回到任务规划层面,让模型重新评估自己该走的流程。第四类是“需求不明确”,用户输入本身含糊,工具撞了半天墙也执行不下去。正确的恢复策略不是硬闯,而是生成一个澄清问题返回给用户,拿到补充信息后再继续。分类不一定要多复杂,关键是在Harness里维护一张“错误处置策略表”错误码/错误描述、错误类别、建议动作、是否允许重试、重试上限。Harness捕获到异常后,先查表匹配策略,再执行对应的动作。跑的时间长了以后,你还可以把“某类错误在某个场景下的最优处理方式”沉淀到表里,让恢复动作变得越来越精准——这个沉淀的过程,就是我理解的自优化。4.3 实操建议:把错误纳入决策流程这里我特别想强调一个和常见做法相反的点不要把所有异常都归给模型。我见过不少团队一遇到Agent效果不好就改Prompt,改来改去还是在同一个坑边打转。很多时候,问题出在Harness没有把错误信息完整地反馈给决策环节。正确的做法是,Harness捕获异常后,把异常信息和当前任务的状态一并写进上下文,让模型基于这些信息做下一步决策。比如,Harness捕获到“工具A返回了空列表”,它把这条信息连同“空列表可能的三种原因”“前面步骤已经确认的约束条件”一起传给模型,模型就能做出更聪明的判断是重新换参数调用,还是换一个工具,还是直接告知用户数据为空。而不是Harness自己悄悄吞掉异常,或者用一条死规则让系统重试。还有一个工程上的细节给执行流程加一个“循环上限”。Agent一旦陷入“失败—反思—重试—再失败”的循环,不仅消耗token,还会造成用户长时间等待。我习惯在Harness里设置一个显式的迭代上限,并在上下文里写入当前已执行的迭代次数。当逼近上限时,Harness会主动调整策略——比如从自动重试切换到请求用户澄清,再从澄清切换到最终兜底方案。别小看这个小小的计数器,它能让你的Agent系统在面对异常时始终处于可控状态,而不会像个失控的旋涡一样越卷越深。5. 答案四评估反馈自优化——好坏不能靠感觉5.1 没有评估闭环调优就是盲人摸象到了这一步,前面三个自优化机制都搭起来了,你会遇到一个更根本的瓶颈怎么知道改动到底是变好了还是变坏了。很多Agent项目在开发期靠的是人工看案例,找几十个测试样本,跑一遍看输出结果,凭感觉说“效果还行”。但一旦进入持续迭代阶段,这种评估方式就撑不住了你改了一个Prompt的措辞,换了工具选择的顺序,调整了上下文压缩的频率,结果有提升也有下降,模棱两可,你根本说不清该不该保留这次改动。我在这方面栽过跟头。有一阵子我优化了一个Agent的上下文摘要策略,从肉眼抽查的几个案例看,输出的逻辑性确实变强了,我很高兴。结果放到线上跑了一周,发现有一类用户场景的成功率反而掉了十几个点——因为摘要策略把某个高频场景里用户提供的原始细节给压掉了,让模型无法获取准确信息。问题出在哪出在我当初根本没有一套自动化的评估指标,只看了一小撮手工挑出来的样本,误判了全局效果。SoL-Pi把评估反馈列为四个答案之一,很有道理。没有可靠的评估,你所谓的“优化”只是碰运气;有了评估闭环,Harness才能判断哪些策略有效、哪些策略无效,并据此做出持续的自我调整。5.2 自优化思路:轨迹级评估与指标定义什么是好的Agent评估我的经验是,不能只看最终输出对不对,还要看过程走得稳不稳。也就是说,不但要评“结果”,还要评“轨迹”。在你评估一个Agent任务的执行质量时,建议从以下四个维度去打分任务完成率、工具调用正确率、步骤冗余度、上下文利用率。任务完成率很好理解,就是最终目标有没有达成,达成到什么程度。工具调用正确率则要看每一步工具选择和使用是否恰当——调用了一个不该调的工具,即便最终结果歪打正着对了,也要扣分,因为这种选择是不可复现的运气。步骤冗余度主要考察整个流程有没有绕远路,比如明明一步能查到的信息,Agent却来回查了三次才拿到。上下文利用率则反映系统有没有把重要信息抓住,有没有因为上下文管理不当导致遗漏关键输入。这四个维度合起来,其实就在刻画一个Agent系统的“健康度”。如果你在优化某个模块之后,任务完成率提升、工具调用正确率上升、步骤冗余度下降,这个优化就是真实的;反过来,如果只有任务完成率上升但冗余度大幅上升,那这个优化可能只是在某些样本上碰巧更准,整体并没有变得更好。在具体操作上,我建议把评估指标做成“可自动计算”的,而不是每次靠LLM打分。LLM作为评估者有一定辅助价值,但它不稳定、成本高、还可能带有自己的偏好。更可靠的做法是,把大量任务的执行日志做成结构化数据,用脚本或小规则引擎自动计算上述指标。比如一个任务是否完成,可以根据最终状态是否为success、输出是否符合schema来判断;工具调用正确率则可以通过比对“该场景下应选的工具”和“实际调用工具”得到。只有把这些指标自动化之后,才能实现大样本的持续评估。5.3 实操建议:搭一个轻量评估脚本搭建评估闭环并没有想象中那么复杂。我当时做了一个非常轻量的版本每次任务结束,Harness会写一条JSON格式的运行记录,包含任务ID、最终状态、每一步工具调用信息、总耗时、token消耗、上下文压缩日志等。离线每天跑一次分析和汇总,生成一份简单的日报,看几个关键指标的变化。更重要的是,我在项目里维护了一个“失败样本集”。把每天所有评估不达标的案例存下来,每周人工翻一遍,挑典型的失败模式补充到测试集里。然后每次对Harness策略做改动时,先在这个样本集上跑一遍回归测试,看有没有修复老的失败、有没有引入新的失败。这个小而实的工作流,给了我非常大的确定性——我终于可以拍着胸脯说“这次改动确实有效”,而不是“我感觉可能有帮助”。这对Harness自优化的意义在于,当评估反馈以“可计算的指标 失败样本集”的形式沉淀下来时,你就能把这些指标输送给前面三个自优化模块。上下文压缩方案频繁导致低利用率时,Harness就调整压缩策略;工具选择在某个子集上频繁失败时,路由模块就学习新的排序。整个系统就从一个“模型单打独斗”的结构,进化成了“模型 Harness 评估反馈”的闭环系统。6. 落地时会踩的坑与细节6.1 四个答案是一个整体,别拆开做SoL-Pi的“四个答案”看起来是四个独立模块,但在实际工程里它们是咬合在一起的。上下文管理做得好,工具选择时的参考信息才更准确;工具选择做得好,错误恢复时才有更明确的处置路径;错误恢复做得好,评估指标里的任务完成率才不会虚高;评估反馈做得好,前面三个模块才可能持续改进。我建议的切入顺序是先做“上下文管理自优化”,因为它对系统稳定性的改善最明显、改动成本最低;然后做“工具选择自优化”,因为你要在上下文优化带来余量之后,才有空间给模型提供更精准的工具候选集;接着做“错误恢复自优化”,因为只要前面两个环节在动态调整,就一定会引入新的不确定性,必须有健壮的错误处理兜底;最后再上“评估反馈自优化”,用数据把所有改动固化下来,形成可持续迭代的节奏。这个顺序也是我踩坑之后总结出的实践规律。一开始我曾试图同时动所有模块,结果每次线上出问题都分不清是上下文引起的、工具引起的还是恢复策略引起的。后来改成逐个模块改动、每个模块都跑一周观察数据,才真正建立起“改动—验证—再改动”的稳定循环。6.2 工程上最容易被低估的几个细节先说日志。Harness自优化的前提是你能完整看到系统在做什么,所以结构化日志不是可选项,而是必选项。每个步骤至少记清楚输入信息从哪来、模型基于什么决策、选了哪个工具、传了什么参数、返回什么结果、有没有异常、最终结论是什么。日志字段宁可多不可少,因为事后补日志永远比事前多记一个字段贵得多。再说版本化。自优化意味着Harness的策略会持续变化,但你一定要保留历史版本的快照。我在生产环境里遇到过这样的情况新策略在某类场景上效果很好,但在另一类场景上产生了灾难性的回归,而因为我没有对策略做版本化,花了不少时间才找回原来的配置。后来我把所有Harness策略配置都纳入版本管理,每个版本上线前先在离线评估集上跑一遍回归,确认没有引入严重退化,再灰度推进。第三是灰度切换。不要一次性把所有流量都切到新策略上。哪怕你的离线评估做得再完善,真实场景的复杂度永远比测试集里面的大。从5%、20%、50%、100%这样的节奏逐步放量,配合指标监控,一旦发现异常就立刻回滚,这是每一个做自优化系统的人都应该刻在心里的规矩。还有一个容易忽略的地方不要过度设计。研究里讨论的自优化机制很全面,但那是一个框架的完整形态,你不需要一步到位。如果你的系统只有三个工具,那“工具合成”模块完全没必要上;如果你的任务都是短对话,那“上下文分级存储”可以先放一放。我在这个项目里最大的体会是自优化是一个过程,不是一个开关。从最小的闭环开始——记录日志、分析指标、调整策略——然后不断扩展,才是最稳妥的路线。等你把这套循环跑顺了,再回头看SoL-Pi讲的四个答案,你会发现它们不是遥远的研究概念,而是你已经在做的事情的系统化总结。我个人在实际操作中最受益的一条原则是永远不要用人工感觉替代数据。不管是上下文该压缩多少、工具该排到第几位,还是错误该重试几次、评估该采用什么标准,先跑数据,让日志告诉你答案,然后再让Harness把答案内化成自己的策略。Agent这个领域更新换代比谁都快,但“可观测、可评估、可迭代”这三个字,才是任何时代都不过时的底座。