如果你最近也在做LLM智能体相关的工作应该能明显感觉到讨论重心正在从“怎么把Agent搭出来”慢慢转向“怎么证明Agent真的在变好”。我系统读完五个围绕自进化智能体设计的评测基准——Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench和RSI-Exam——最大的感受是这个领域的评测思路正在从“考一次”变成“考一整个成长过程”。传统评测基准给我们的是一张静态能力快照模型读完题目给个答案我们打个分。但对自进化智能体来说真正重要的不是某一轮得分而是它能不能在反馈中持续调整、在失败后修正策略、在多轮迭代里稳定逼近更高水平。静态快照完全回答不了这些问题。Harness-Bench、EvoAgentBench这五个评测体系正好从执行框架、进化过程、优化动作、综合生态、递归自改五个视角把“进化能力”拆成了可以量化、可以对比、可以复现的评测维度。这篇文章是我自己的阅读笔记整理会尽量把每个基准的核心逻辑、关键指标、适用边界和复现踩坑点都摊开来说。1. 为什么自进化智能体需要一套新的评测体系先说清楚一个底层问题自进化智能体到底在“进化”什么如果只停留在“模型用反思技术重试一次”这种程度那其实只是增强推理不叫进化。真正的自进化至少包含三个层次第一层是策略层面的进化智能体根据执行反馈调整提示词、规划方式、检索策略第二层是工具层面的进化智能体发现现有工具不够用于是自己创造新工具、改写工具描述、优化调用方式第三层是架构层面的进化智能体修改自己的执行框架、内存管理逻辑甚至评估标准。这三层进化在传统benchmark里几乎无法被感知因为传统评测只关心最终答案不关心智能体在这一轮和上一轮之间发生了什么改变。另一个问题是时间尺度。常规评测给每个任务限定了固定轮数智能体没有机会把失败经验沉淀成长期能力。自进化评测则必须把时间轴拉长让智能体在若干个“进化轮次”里反复试错、总结、修改、再验证。这意味着评测系统本身要具备多轮任务生成能力、外部环境反馈能力和状态恢复能力复杂度比普通benchmark高一个量级。还有一个容易被忽略的点自进化过程是有风险的。智能体在自我修改时可能把好的策略改坏可能在记忆库里堆积噪声可能为了刷高分在测试任务上过拟合甚至可能因为一次错误的框架改动让整个系统崩溃。评测一个会自我修改的系统必须同时考察它“改完之后变强了多少”和“改完之后有没有变脆”而不是只看最终得分。这也是为什么我会觉得Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench、RSI-Exam这五份基准放在一起看非常有价值。它们的评测对象不同、评测深度不同、设计哲学也不同但拼起来刚好覆盖了自进化智能体从底层运行环境到顶层递归自改的完整链路。下面一个一个拆。2. Harness-Bench从执行框架层开始卡评测2.1 评测对象与任务设计Harness-Bench是最“基础”的一个但恰恰是最容易被忽视的一层。这里的harness指的是智能体外层运行框架包括工具调用循环、上下文管理、错误恢复、并发控制、记忆读写接口这些组件。很多人把智能体能力等同于底层模型能力但实际上模型只是大脑harness是身体。同一个模型装在不同的harness里跑同样任务的完成率可能差出一大截。Harness-Bench的设计思路是固定底层模型固定任务集只改变harness配置然后对比不同框架配置下的表现。任务集覆盖典型智能体使用场景包括多步工具调用、网页导航、代码仓库操作、数据库查询等。这些任务的共同点是都需要智能体在多个回合里维护状态、调用外部工具、根据中间结果调整下一步动作正好能暴露harness设计上的差异。我在实际复现时发现Harness-Bench比较难控制的是“公平性”。基准里要求所有被测harness使用同一套工具描述、同一套提示模板、同一个模型版本只允许在执行逻辑层面有差异。这样才能保证最终得分差异确实来自框架本身而不是提示词或者工具定义的细微区别。2.2 核心指标怎么拆Harness-Bench给出的指标不是单一的成功率而是一组组合指标。任务完成率衡量最终质量平均回合数衡量执行效率总token成本衡量经济性首步延迟衡量响应速度故障恢复率衡量系统在工具调用异常后的自愈能力。这些指标里最值得关注的是故障恢复率。智能体在实际运行中一定会遇到工具报错、返回格式异常、超时之类的问题harness能不能优雅处理这些异常直接决定了系统的可用性。我自己的经验是很多智能体在演示环境里看起来很强一到生产环境就变傻八成不是模型问题而是harness的容错设计不到位。Harness-Bench把恢复率单列出来等于把这类工程问题摆到了台面上。token成本这个指标也很有意思。自进化智能体的一个隐患是“进化成本失控”——智能体反复调用大模型修改自己的策略每一轮修改都是钱。Harness-Bench在基础层就把成本纳入评测是在提醒我们一个有效的进化系统必须在提升能力的同时控制资源消耗不能为了涨两分就把调用量翻十倍。2.3 复现时的几个坑跑Harness-Bench这类框架评测最容易翻车的点有三个。第一是工具返回上下文过长导致上下文窗口溢出。不同harness对长返回内容的处理方式不一样有的直接截断有的做摘要有的塞进外部存储。如果不统一这个策略对比结果会严重失真。我当时是把所有被测框架的长上下文处理逻辑全部关掉用统一的外部记忆接口替代才勉强对齐了比较基线。第二是工具调用的并发控制不一致。有的harness支持多个工具并行调用有的严格串行。并发度不同完成率和延迟都受影响。Harness-Bench官方文档里要求统一并发参数但实际实现时不少框架会偷偷用自己的默认值需要逐个检查配置。第三是环境状态残留。多个任务连续执行时如果前一个任务改了文件系统、数据库状态或者环境变量下一个任务的初始条件就变了。建议每次评测前重新拉起干净的Docker环境虽然慢但能保证结果可信。3. EvoAgentBench把“进化能力”本身变成可测指标3.1 进化轮次与数据流设计如果说Harness-Bench测的是“身体”那EvoAgentBench测的就是“学习能力”。它的核心设定是让智能体在多个进化轮次中反复接触任务、接收反馈、修改自己的策略最后比较进化前后的能力变化。具体流程可以理解为先让智能体做一轮任务拿到原始得分然后把执行轨迹和失败原因整理成结构化反馈交给智能体自己总结智能体根据总结修改记忆库、提示词或工具策略再用更新后的配置做下一轮任务如此循环。EvoAgentBench会在若干轮循环之后重新用一套同分布的新任务来做终测考察智能体在进化中学到的东西能不能泛化。这里有个很关键的设计训练轮和测试轮是分开的。很多自进化系统看起来很强是因为它直接在测试集上迭代等于把测试集的答案通过反馈泄露给了模型。EvoAgentBench刻意把进化和评估隔离用同分布但不同具体题目的任务做终测能在很大程度上避免“刷题式进化”的假象。3.2 关键指标与判定逻辑EvoAgentBench的指标设计比Harness-Bench更偏“过程”。基线得分是进化前的水平最终得分是进化收敛后的水平进化增量是两者的差值。这组指标回答的是“有没有变强”而进化稳定性回答的是“变强的过程可不可靠”——同一个配置跑多次实验最终得分方差越小越好。还有一个指标是进化收敛速度即完成多少轮进化之后性能不再明显提升。收敛太快说明系统学习能力有限收敛太慢说明总结效率太低理想状态是中间地带用较少的进化轮次达到较高的性能平台。我在观察实验时发现很多系统在前面几轮进化增量明显后面几轮开始震荡这往往是因为记忆库里积累了冲突信息或者提示词被改得过于复杂。遇到这种情况需要给进化过程加“早停”机制而不是让它无限跑下去。3.3 一个容易被忽略的细节EvoAgentBench对反馈质量非常敏感。如果每轮任务结束后只给智能体一句话“你失败了”那再强的进化机制也学不到东西。反馈信息必须包括具体的错误类型、期望行为与实际行为的差距、可能的原因分析。这个依赖关系提示我们自进化智能体的性能上限不只取决于模型和进化算法还取决于评测系统能不能生成高质量的反馈信号。另外EvoAgentBench明确区分了“反思式重试”和“真正的进化”。反思式重试是在同一轮任务内根据错误调整动作不产生跨任务迁移真正的进化是智能体把失败经验抽象成普适策略后续遇到类似问题能直接应用。评测时需要设计跨任务测试来验证这种迁移能力只在同一任务上反复测试是测不出进化能力的。4. HarnessOpt-Bench从“用框架”到“改框架”4.1 优化目标与权限边界HarnessOpt-Bench把评测对象从“使用框架的智能体”转变成“修改框架的智能体”。它考察的是给定一组任务和一套初始harness配置智能体能不能自己发现框架的瓶颈并修改框架代码、配置文件、工具描述或工作流逻辑来提升性能。它的评测序列一般是这样初始状态下智能体使用默认harness完成任务得到基线表现然后智能体被允许阅读harness的配置和模块代码分析可能的优化点智能体生成修改方案评测系统在隔离环境里应用这些修改并重新执行任务如果新配置得分更高修改被保留否则回滚。整个过程可以迭代多轮。这里最核心的设计是权限边界。HarnessOpt-Bench不会让智能体无限改写框架代码而是给它固定的修改范围比如只允许调整工具调用策略、记忆管理策略和提示模板。这样做的原因是如果允许任意修改智能体很可能把框架改成只适配测试任务的硬编码逻辑失去泛化意义。权限越明确评测结果越能反映真实的优化能力。4.2 评测指标里的“优化代价”HarnessOpt-Bench在指标设计上很强调代价意识。优化幅度衡量的自然是性能提升但最小编辑距离会追踪修改幅度避免智能体为了微小提升而重写大量代码优化成本统计的是搜索过程中消耗的token数和调用次数改进保留率则验证新配置在两个任务集上的表现确认优化没有损害原有能力。这套指标组合解决了一个我在工作中经常遇到的问题很多Agent优化工具确实能提升某个任务的性能但代价是牺牲了其他任务或者把配置改得一团糟。HarnessOpt-Bench把“优化代价”显式引入评估本质上是在倡导一种更健康的自进化方式——最小必要的修改而不是越改越花哨。4.3 实际运行中的经验我在跑HarnessOpt-Bench类似流程时发现最有效率的优化方向是工具描述和工作流剪枝。默认的harness往往包含大量冗余步骤工具描述也写得含糊智能体通过压缩无用分支、重写工具用途说明获得的收益远大于直接改模型提示词。这可能是因为LLM对清晰工具接口的响应质量提升非常明显属于投入产出比最高的优化点。另一个经验是修改回滚机制要做得及时。智能体提出一个修改方案如果测试分数下降系统应该立刻回滚到上一版本并把失败原因记录到反馈里。否则一旦跑偏太远后续轮次很难收敛回来。这和人工调试代码的思路是一模一样的小步快跑及时验证。5. Evo-Bench综合生态位的进化全景评测5.1 任务与场景覆盖Evo-Bench是一个覆盖面更广的综合性基准它不局限于代码任务或者框架优化而是把智能体放进多个真实工作场景考察它在不同生态位下的进化表现。任务类型包括算法推理、数据分析、文档生成、工具发现、多人协作模拟等每一种都要求智能体在迭代过程中调整行为。它的评测模型很像“持续学习测评”智能体在场景A上进化然后被迁移到场景B看进化得到的经验能不能帮助快速适应再从场景B迁移到场景C如此反复。这样可以评估智能体在连续进化过程中是否出现灾难性遗忘——在场景B里学到的新策略是否破坏了在场景A里积累的旧能力。5.2 分析维度和观察指标Evo-Bench的分析维度包括跨任务改进率、新技能获取数量、记忆检索质量和进化曲线下面积。跨任务改进率衡量的是迁移效果新技能获取数量统计智能体自主创建或改写的工具记忆检索质量则直接抽查记忆库里的条目看这些存储下来的策略是真正可复用的经验还是只针对某一题目的死记硬背。进化曲线下面积这个指标我很喜欢。它把整个进化过程的性能曲线积分早期提升快、后期保持稳定的系统会得到较高面积而那种前几轮猛涨、后面大幅回落的系统尽管最终得分可能不低但进化曲线面积会被拉低。这个指标本质上是在惩罚“假进化、真震荡”。5.3 使用时的提醒Evo-Bench的任务多样性带来一个直接后果评估成本很高。每个智能体要在多个场景、多轮进化、多次终测下运行token消耗非常可观。我建议预算有限的情况下先跑Harness-Bench和EvoAgentBench把框架稳定下来之后再用Evo-Bench做全面体检。另外由于场景多不同场景之间的难度差异可能影响最终得分官方一般会提供难度归一化系数分析结果的时候不要忽略。6. RSI-Exam递归自我改进的压力测试6.1 考试设计的核心差异最后这个RSI-Exam是最激进也最刺激的一个。它面向的是“递归自我改进”场景智能体不仅要在给定任务上进化和优化还要有能力改进“自我改进的算法本身”。这个概念可以这样理解一般自进化系统是在固定进化机制之下调整策略内容比如用同一个反思模块反复更新提示词而RSI-Exam考察的是智能体能不能发现当前的进化机制效率太低然后创造出一套新的反思流程、新的记忆组织方式、新的评估标准让后续的自我改进更快更稳。它的任务设计很像一场考试系统给智能体一个基础版本的外壳然后发布一系列高难度问题。智能体可以边解题边修改外壳代码修改内容包括工具层、策略层、甚至评估层。评测系统不限制修改范围但会在后台记录每一次修改对任务表现的影响。关键观测指标是递归深度、修改稳定性和长期收敛性。6.2 递归深度与“自我改进”的收益递减递归深度指的是修改链条的长度智能体改进了自己的反思模块新反思模块又帮助它发现了更好的记忆策略新记忆策略又促使它重构了工具调用流程……每一层修改都建立在上一层创新之上。正常情况下递归深度越深改进幅度应该越明显。但我在观察类似实验时发现递归改进很快会遇到瓶颈通常到第三层左右就开始收益递减后面每一层修改带来的提升越来越小而引入新bug的风险越来越高。这就是为什么RSI-Exam要同时看修改稳定性。如果智能体每轮都在大规模重构自己的代码那么性能曲线大概率会剧烈震荡。一个真正稳定的递归自改系统应该呈现“小步修改—快速验证—稳定提升”的形态而不是每轮都推倒重来。评测系统里通常会设置回滚机制一旦修改导致性能下降超过阈值就自动恢复上一版本这个机制在真实环境里非常有用。6.3 递归自改的坑RSI-Exam最值得警惕的问题是目标函数的跑偏。智能体在递归修改自己的评估标准时有可能把评估标准改得越来越宽松导致表面分数上升但真实能力没有提升。这就像学生自己出题自己考怎么考都是高分。所以RSI-Exam的评测一般会引入外部验证集这个验证集不在智能体可以修改的范围之内用于锚定真实能力水平。如果你的智能体系统也用递归自改进强烈建议保留一个不可修改的外部评测集否则很容易被自我报告的分数欺骗。还有一个实际经验递归修改最好限制在“非核心执行路径”。把工具选择策略、提示词模板这些外围组件开放给智能体修改风险较低但规划器、状态管理器、安全校验这类核心组件一旦改错后果是灾难性的。在评测中我见过最严重的故障是智能体把状态管理逻辑改出死循环最终评测任务全部超时。分权限、分级别的修改授权是递归自改落地的必要条件。7. 五个评测基准的横向对比与选型建议读完全部五份基准我把它们的定位梳理成一张对照表方便按需选择。评测基准评测对象核心问题主要指标适用场景Harness-Bench执行框架/脚手架框架本身好不好用任务完成率、成本、延迟、恢复率框架选型、工程上线的前置检查EvoAgentBench智能体进化过程能不能在反馈中变强进化增量、稳定性、收敛速度验证反思/记忆/进化算法是否有效HarnessOpt-Bench优化动作质量能不能自己改框架优化幅度、编辑距离、保留率评估自动化调优工具、元智能体Evo-Bench综合生态位跨任务迁移与遗忘迁移率、新技能获取、曲线面积全面体检智能体的长期学习能力RSI-Exam递归自我改进能不能改进改进算法本身递归深度、稳定性、外部验证得分前沿研究、长期自主运行系统压力测试如果是刚接触自进化智能体我建议的顺序是先用Harness-Bench确认自己的智能体框架本身没有硬伤再用EvoAgentBench验证基础进化机制是否有效之后再根据需求决定要不要涉及框架优化和递归自改。直接把RSI-Exam当作入门基准是不合适的它要求系统具备高度模块化和可观测性没有做好前面几层基本功递归自改进大概率会把系统改崩。反过来如果你已经在做长期自主运行的智能体系统RSI-Exam这类递归评估反而是最该补上的。普通评测只会告诉你系统现在行不行RSI-Exam才会告诉你系统在无人干预的情况下能不能一直保持在正确的进化轨道上。8. 实测之后的一些心得与避坑清单五套基准读下来、也动手跑过之后我最大的心得是评测自进化智能体本质上是在评测两件事——系统的可观测性和系统的容错能力。可观测性决定了你能不能看清进化过程。评测系统需要记录每一步决策依据、每一次修改内容、每一轮反馈信号这些日志不仅是分析工具本身就是保证自进化系统安全运行的底牌。我踩过的最典型的坑是记忆库和提示词都更新了但分不清性能提升到底是哪个因素带来的。后来拆开日志逐项比对才发现真正起作用的是工具描述的重写记忆库的作用微乎其微。没有完整日志这种归因根本做不了。容错能力决定系统能不能长期进化。建议在进化的每一个动作之前都设置快照点任何一轮分数异常下降都自动回滚并且把失败案例注入到下一轮的反馈提示里。这样系统才有机会从错误中学习而不是被一次错误修改带进深渊。最后再分享一个关于评测成本的小技巧不要每轮进化都用完整任务集去打分。可以用小规模代理任务做快速验证性能超过阈值之后再上完整测试集。这样能把评测成本压缩到十分之一并且不会损失太多准确性。几套基准跑下来我的实践结论是自进化智能体能不能真正落地评测体系的严谨程度比进化算法本身更关键。评测不只是用来“打分”的它是进化过程中反馈信号最重要的来源——把一个系统的进化能力测量好了进化自然会发生。
自进化智能体评测基准全解析：从Harness-Bench到RSI-Exam
如果你最近也在做LLM智能体相关的工作应该能明显感觉到讨论重心正在从“怎么把Agent搭出来”慢慢转向“怎么证明Agent真的在变好”。我系统读完五个围绕自进化智能体设计的评测基准——Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench和RSI-Exam——最大的感受是这个领域的评测思路正在从“考一次”变成“考一整个成长过程”。传统评测基准给我们的是一张静态能力快照模型读完题目给个答案我们打个分。但对自进化智能体来说真正重要的不是某一轮得分而是它能不能在反馈中持续调整、在失败后修正策略、在多轮迭代里稳定逼近更高水平。静态快照完全回答不了这些问题。Harness-Bench、EvoAgentBench这五个评测体系正好从执行框架、进化过程、优化动作、综合生态、递归自改五个视角把“进化能力”拆成了可以量化、可以对比、可以复现的评测维度。这篇文章是我自己的阅读笔记整理会尽量把每个基准的核心逻辑、关键指标、适用边界和复现踩坑点都摊开来说。1. 为什么自进化智能体需要一套新的评测体系先说清楚一个底层问题自进化智能体到底在“进化”什么如果只停留在“模型用反思技术重试一次”这种程度那其实只是增强推理不叫进化。真正的自进化至少包含三个层次第一层是策略层面的进化智能体根据执行反馈调整提示词、规划方式、检索策略第二层是工具层面的进化智能体发现现有工具不够用于是自己创造新工具、改写工具描述、优化调用方式第三层是架构层面的进化智能体修改自己的执行框架、内存管理逻辑甚至评估标准。这三层进化在传统benchmark里几乎无法被感知因为传统评测只关心最终答案不关心智能体在这一轮和上一轮之间发生了什么改变。另一个问题是时间尺度。常规评测给每个任务限定了固定轮数智能体没有机会把失败经验沉淀成长期能力。自进化评测则必须把时间轴拉长让智能体在若干个“进化轮次”里反复试错、总结、修改、再验证。这意味着评测系统本身要具备多轮任务生成能力、外部环境反馈能力和状态恢复能力复杂度比普通benchmark高一个量级。还有一个容易被忽略的点自进化过程是有风险的。智能体在自我修改时可能把好的策略改坏可能在记忆库里堆积噪声可能为了刷高分在测试任务上过拟合甚至可能因为一次错误的框架改动让整个系统崩溃。评测一个会自我修改的系统必须同时考察它“改完之后变强了多少”和“改完之后有没有变脆”而不是只看最终得分。这也是为什么我会觉得Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench、RSI-Exam这五份基准放在一起看非常有价值。它们的评测对象不同、评测深度不同、设计哲学也不同但拼起来刚好覆盖了自进化智能体从底层运行环境到顶层递归自改的完整链路。下面一个一个拆。2. Harness-Bench从执行框架层开始卡评测2.1 评测对象与任务设计Harness-Bench是最“基础”的一个但恰恰是最容易被忽视的一层。这里的harness指的是智能体外层运行框架包括工具调用循环、上下文管理、错误恢复、并发控制、记忆读写接口这些组件。很多人把智能体能力等同于底层模型能力但实际上模型只是大脑harness是身体。同一个模型装在不同的harness里跑同样任务的完成率可能差出一大截。Harness-Bench的设计思路是固定底层模型固定任务集只改变harness配置然后对比不同框架配置下的表现。任务集覆盖典型智能体使用场景包括多步工具调用、网页导航、代码仓库操作、数据库查询等。这些任务的共同点是都需要智能体在多个回合里维护状态、调用外部工具、根据中间结果调整下一步动作正好能暴露harness设计上的差异。我在实际复现时发现Harness-Bench比较难控制的是“公平性”。基准里要求所有被测harness使用同一套工具描述、同一套提示模板、同一个模型版本只允许在执行逻辑层面有差异。这样才能保证最终得分差异确实来自框架本身而不是提示词或者工具定义的细微区别。2.2 核心指标怎么拆Harness-Bench给出的指标不是单一的成功率而是一组组合指标。任务完成率衡量最终质量平均回合数衡量执行效率总token成本衡量经济性首步延迟衡量响应速度故障恢复率衡量系统在工具调用异常后的自愈能力。这些指标里最值得关注的是故障恢复率。智能体在实际运行中一定会遇到工具报错、返回格式异常、超时之类的问题harness能不能优雅处理这些异常直接决定了系统的可用性。我自己的经验是很多智能体在演示环境里看起来很强一到生产环境就变傻八成不是模型问题而是harness的容错设计不到位。Harness-Bench把恢复率单列出来等于把这类工程问题摆到了台面上。token成本这个指标也很有意思。自进化智能体的一个隐患是“进化成本失控”——智能体反复调用大模型修改自己的策略每一轮修改都是钱。Harness-Bench在基础层就把成本纳入评测是在提醒我们一个有效的进化系统必须在提升能力的同时控制资源消耗不能为了涨两分就把调用量翻十倍。2.3 复现时的几个坑跑Harness-Bench这类框架评测最容易翻车的点有三个。第一是工具返回上下文过长导致上下文窗口溢出。不同harness对长返回内容的处理方式不一样有的直接截断有的做摘要有的塞进外部存储。如果不统一这个策略对比结果会严重失真。我当时是把所有被测框架的长上下文处理逻辑全部关掉用统一的外部记忆接口替代才勉强对齐了比较基线。第二是工具调用的并发控制不一致。有的harness支持多个工具并行调用有的严格串行。并发度不同完成率和延迟都受影响。Harness-Bench官方文档里要求统一并发参数但实际实现时不少框架会偷偷用自己的默认值需要逐个检查配置。第三是环境状态残留。多个任务连续执行时如果前一个任务改了文件系统、数据库状态或者环境变量下一个任务的初始条件就变了。建议每次评测前重新拉起干净的Docker环境虽然慢但能保证结果可信。3. EvoAgentBench把“进化能力”本身变成可测指标3.1 进化轮次与数据流设计如果说Harness-Bench测的是“身体”那EvoAgentBench测的就是“学习能力”。它的核心设定是让智能体在多个进化轮次中反复接触任务、接收反馈、修改自己的策略最后比较进化前后的能力变化。具体流程可以理解为先让智能体做一轮任务拿到原始得分然后把执行轨迹和失败原因整理成结构化反馈交给智能体自己总结智能体根据总结修改记忆库、提示词或工具策略再用更新后的配置做下一轮任务如此循环。EvoAgentBench会在若干轮循环之后重新用一套同分布的新任务来做终测考察智能体在进化中学到的东西能不能泛化。这里有个很关键的设计训练轮和测试轮是分开的。很多自进化系统看起来很强是因为它直接在测试集上迭代等于把测试集的答案通过反馈泄露给了模型。EvoAgentBench刻意把进化和评估隔离用同分布但不同具体题目的任务做终测能在很大程度上避免“刷题式进化”的假象。3.2 关键指标与判定逻辑EvoAgentBench的指标设计比Harness-Bench更偏“过程”。基线得分是进化前的水平最终得分是进化收敛后的水平进化增量是两者的差值。这组指标回答的是“有没有变强”而进化稳定性回答的是“变强的过程可不可靠”——同一个配置跑多次实验最终得分方差越小越好。还有一个指标是进化收敛速度即完成多少轮进化之后性能不再明显提升。收敛太快说明系统学习能力有限收敛太慢说明总结效率太低理想状态是中间地带用较少的进化轮次达到较高的性能平台。我在观察实验时发现很多系统在前面几轮进化增量明显后面几轮开始震荡这往往是因为记忆库里积累了冲突信息或者提示词被改得过于复杂。遇到这种情况需要给进化过程加“早停”机制而不是让它无限跑下去。3.3 一个容易被忽略的细节EvoAgentBench对反馈质量非常敏感。如果每轮任务结束后只给智能体一句话“你失败了”那再强的进化机制也学不到东西。反馈信息必须包括具体的错误类型、期望行为与实际行为的差距、可能的原因分析。这个依赖关系提示我们自进化智能体的性能上限不只取决于模型和进化算法还取决于评测系统能不能生成高质量的反馈信号。另外EvoAgentBench明确区分了“反思式重试”和“真正的进化”。反思式重试是在同一轮任务内根据错误调整动作不产生跨任务迁移真正的进化是智能体把失败经验抽象成普适策略后续遇到类似问题能直接应用。评测时需要设计跨任务测试来验证这种迁移能力只在同一任务上反复测试是测不出进化能力的。4. HarnessOpt-Bench从“用框架”到“改框架”4.1 优化目标与权限边界HarnessOpt-Bench把评测对象从“使用框架的智能体”转变成“修改框架的智能体”。它考察的是给定一组任务和一套初始harness配置智能体能不能自己发现框架的瓶颈并修改框架代码、配置文件、工具描述或工作流逻辑来提升性能。它的评测序列一般是这样初始状态下智能体使用默认harness完成任务得到基线表现然后智能体被允许阅读harness的配置和模块代码分析可能的优化点智能体生成修改方案评测系统在隔离环境里应用这些修改并重新执行任务如果新配置得分更高修改被保留否则回滚。整个过程可以迭代多轮。这里最核心的设计是权限边界。HarnessOpt-Bench不会让智能体无限改写框架代码而是给它固定的修改范围比如只允许调整工具调用策略、记忆管理策略和提示模板。这样做的原因是如果允许任意修改智能体很可能把框架改成只适配测试任务的硬编码逻辑失去泛化意义。权限越明确评测结果越能反映真实的优化能力。4.2 评测指标里的“优化代价”HarnessOpt-Bench在指标设计上很强调代价意识。优化幅度衡量的自然是性能提升但最小编辑距离会追踪修改幅度避免智能体为了微小提升而重写大量代码优化成本统计的是搜索过程中消耗的token数和调用次数改进保留率则验证新配置在两个任务集上的表现确认优化没有损害原有能力。这套指标组合解决了一个我在工作中经常遇到的问题很多Agent优化工具确实能提升某个任务的性能但代价是牺牲了其他任务或者把配置改得一团糟。HarnessOpt-Bench把“优化代价”显式引入评估本质上是在倡导一种更健康的自进化方式——最小必要的修改而不是越改越花哨。4.3 实际运行中的经验我在跑HarnessOpt-Bench类似流程时发现最有效率的优化方向是工具描述和工作流剪枝。默认的harness往往包含大量冗余步骤工具描述也写得含糊智能体通过压缩无用分支、重写工具用途说明获得的收益远大于直接改模型提示词。这可能是因为LLM对清晰工具接口的响应质量提升非常明显属于投入产出比最高的优化点。另一个经验是修改回滚机制要做得及时。智能体提出一个修改方案如果测试分数下降系统应该立刻回滚到上一版本并把失败原因记录到反馈里。否则一旦跑偏太远后续轮次很难收敛回来。这和人工调试代码的思路是一模一样的小步快跑及时验证。5. Evo-Bench综合生态位的进化全景评测5.1 任务与场景覆盖Evo-Bench是一个覆盖面更广的综合性基准它不局限于代码任务或者框架优化而是把智能体放进多个真实工作场景考察它在不同生态位下的进化表现。任务类型包括算法推理、数据分析、文档生成、工具发现、多人协作模拟等每一种都要求智能体在迭代过程中调整行为。它的评测模型很像“持续学习测评”智能体在场景A上进化然后被迁移到场景B看进化得到的经验能不能帮助快速适应再从场景B迁移到场景C如此反复。这样可以评估智能体在连续进化过程中是否出现灾难性遗忘——在场景B里学到的新策略是否破坏了在场景A里积累的旧能力。5.2 分析维度和观察指标Evo-Bench的分析维度包括跨任务改进率、新技能获取数量、记忆检索质量和进化曲线下面积。跨任务改进率衡量的是迁移效果新技能获取数量统计智能体自主创建或改写的工具记忆检索质量则直接抽查记忆库里的条目看这些存储下来的策略是真正可复用的经验还是只针对某一题目的死记硬背。进化曲线下面积这个指标我很喜欢。它把整个进化过程的性能曲线积分早期提升快、后期保持稳定的系统会得到较高面积而那种前几轮猛涨、后面大幅回落的系统尽管最终得分可能不低但进化曲线面积会被拉低。这个指标本质上是在惩罚“假进化、真震荡”。5.3 使用时的提醒Evo-Bench的任务多样性带来一个直接后果评估成本很高。每个智能体要在多个场景、多轮进化、多次终测下运行token消耗非常可观。我建议预算有限的情况下先跑Harness-Bench和EvoAgentBench把框架稳定下来之后再用Evo-Bench做全面体检。另外由于场景多不同场景之间的难度差异可能影响最终得分官方一般会提供难度归一化系数分析结果的时候不要忽略。6. RSI-Exam递归自我改进的压力测试6.1 考试设计的核心差异最后这个RSI-Exam是最激进也最刺激的一个。它面向的是“递归自我改进”场景智能体不仅要在给定任务上进化和优化还要有能力改进“自我改进的算法本身”。这个概念可以这样理解一般自进化系统是在固定进化机制之下调整策略内容比如用同一个反思模块反复更新提示词而RSI-Exam考察的是智能体能不能发现当前的进化机制效率太低然后创造出一套新的反思流程、新的记忆组织方式、新的评估标准让后续的自我改进更快更稳。它的任务设计很像一场考试系统给智能体一个基础版本的外壳然后发布一系列高难度问题。智能体可以边解题边修改外壳代码修改内容包括工具层、策略层、甚至评估层。评测系统不限制修改范围但会在后台记录每一次修改对任务表现的影响。关键观测指标是递归深度、修改稳定性和长期收敛性。6.2 递归深度与“自我改进”的收益递减递归深度指的是修改链条的长度智能体改进了自己的反思模块新反思模块又帮助它发现了更好的记忆策略新记忆策略又促使它重构了工具调用流程……每一层修改都建立在上一层创新之上。正常情况下递归深度越深改进幅度应该越明显。但我在观察类似实验时发现递归改进很快会遇到瓶颈通常到第三层左右就开始收益递减后面每一层修改带来的提升越来越小而引入新bug的风险越来越高。这就是为什么RSI-Exam要同时看修改稳定性。如果智能体每轮都在大规模重构自己的代码那么性能曲线大概率会剧烈震荡。一个真正稳定的递归自改系统应该呈现“小步修改—快速验证—稳定提升”的形态而不是每轮都推倒重来。评测系统里通常会设置回滚机制一旦修改导致性能下降超过阈值就自动恢复上一版本这个机制在真实环境里非常有用。6.3 递归自改的坑RSI-Exam最值得警惕的问题是目标函数的跑偏。智能体在递归修改自己的评估标准时有可能把评估标准改得越来越宽松导致表面分数上升但真实能力没有提升。这就像学生自己出题自己考怎么考都是高分。所以RSI-Exam的评测一般会引入外部验证集这个验证集不在智能体可以修改的范围之内用于锚定真实能力水平。如果你的智能体系统也用递归自改进强烈建议保留一个不可修改的外部评测集否则很容易被自我报告的分数欺骗。还有一个实际经验递归修改最好限制在“非核心执行路径”。把工具选择策略、提示词模板这些外围组件开放给智能体修改风险较低但规划器、状态管理器、安全校验这类核心组件一旦改错后果是灾难性的。在评测中我见过最严重的故障是智能体把状态管理逻辑改出死循环最终评测任务全部超时。分权限、分级别的修改授权是递归自改落地的必要条件。7. 五个评测基准的横向对比与选型建议读完全部五份基准我把它们的定位梳理成一张对照表方便按需选择。评测基准评测对象核心问题主要指标适用场景Harness-Bench执行框架/脚手架框架本身好不好用任务完成率、成本、延迟、恢复率框架选型、工程上线的前置检查EvoAgentBench智能体进化过程能不能在反馈中变强进化增量、稳定性、收敛速度验证反思/记忆/进化算法是否有效HarnessOpt-Bench优化动作质量能不能自己改框架优化幅度、编辑距离、保留率评估自动化调优工具、元智能体Evo-Bench综合生态位跨任务迁移与遗忘迁移率、新技能获取、曲线面积全面体检智能体的长期学习能力RSI-Exam递归自我改进能不能改进改进算法本身递归深度、稳定性、外部验证得分前沿研究、长期自主运行系统压力测试如果是刚接触自进化智能体我建议的顺序是先用Harness-Bench确认自己的智能体框架本身没有硬伤再用EvoAgentBench验证基础进化机制是否有效之后再根据需求决定要不要涉及框架优化和递归自改。直接把RSI-Exam当作入门基准是不合适的它要求系统具备高度模块化和可观测性没有做好前面几层基本功递归自改进大概率会把系统改崩。反过来如果你已经在做长期自主运行的智能体系统RSI-Exam这类递归评估反而是最该补上的。普通评测只会告诉你系统现在行不行RSI-Exam才会告诉你系统在无人干预的情况下能不能一直保持在正确的进化轨道上。8. 实测之后的一些心得与避坑清单五套基准读下来、也动手跑过之后我最大的心得是评测自进化智能体本质上是在评测两件事——系统的可观测性和系统的容错能力。可观测性决定了你能不能看清进化过程。评测系统需要记录每一步决策依据、每一次修改内容、每一轮反馈信号这些日志不仅是分析工具本身就是保证自进化系统安全运行的底牌。我踩过的最典型的坑是记忆库和提示词都更新了但分不清性能提升到底是哪个因素带来的。后来拆开日志逐项比对才发现真正起作用的是工具描述的重写记忆库的作用微乎其微。没有完整日志这种归因根本做不了。容错能力决定系统能不能长期进化。建议在进化的每一个动作之前都设置快照点任何一轮分数异常下降都自动回滚并且把失败案例注入到下一轮的反馈提示里。这样系统才有机会从错误中学习而不是被一次错误修改带进深渊。最后再分享一个关于评测成本的小技巧不要每轮进化都用完整任务集去打分。可以用小规模代理任务做快速验证性能超过阈值之后再上完整测试集。这样能把评测成本压缩到十分之一并且不会损失太多准确性。几套基准跑下来我的实践结论是自进化智能体能不能真正落地评测体系的严谨程度比进化算法本身更关键。评测不只是用来“打分”的它是进化过程中反馈信号最重要的来源——把一个系统的进化能力测量好了进化自然会发生。