自进化智能体评测基准深度解析：从工具优化到递归自改进

1. 五篇基准放在一起读我看到了自进化智能体的两条演进路线最近集中把 Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench、RSI-Exam 这五篇关于自进化智能体评测基准的论文和报告翻了一遍。读完之后最大的感受是这些基准表面上都在做“评测”但它们定义的“进化”根本不是一回事。有的在测智能体能不能把工具用得更好有的在测智能体能不能自己长出新的能力还有的在测智能体能不能在无人干预的情况下自己改自己的代码和推理策略。这几层进化能力难度差了不止一个量级。先说一个我觉得很重要但很容易被忽视的背景自进化智能体和普通智能体最大的区别不是“能跑通多少任务”而是“能不能在跑任务的过程中变得更强”。传统智能体的评测逻辑是静态的——给你一批固定任务分数越高越强自进化智能体的评测逻辑必须是动态的——同一个智能体先跑一批任务然后让它利用这些任务的执行经验做一轮自我改进再去跑一批新任务看它的表现有没有真的提升。这个“跑任务—自我改进—再跑任务”的闭环才是自进化智能体评测的核心骨架。但问题也出在这里。这个闭环一旦跑起来评测的变量就变得非常复杂。改进的是记忆模块还是提示词进化发生在工具调用策略层面还是工具本身的代码层面评测环境本身会不会在智能体改进之后失去可比性这些都是传统 benchmark 从未面对过的问题。所以近一年来国内外多个团队几乎同时开始设计专门的评测基准我这次读的五篇正是这个浪潮里比较有代表性的样本。如果你也在做自进化智能体的研究工作或者准备在自己的工程项目里引入“智能体自我改进”的能力这篇笔记应该能帮你快速建立起对这五个基准的整体认知。我会把它们分成两条路线来讲第一类是 Harness-Bench 和 HarnessOpt-Bench关注的是智能体与外部工具框架的交互能力及其优化能力第二类是 EvoAgentBench 和 Evo-Bench关注的是智能体在持续任务流中的自演化能力。RSI-Exam 则单独放在最后因为它测的是最激进、也最具争议的递归自改进能力。下面逐个拆。2. Harness-Bench 与 HarnessOpt-Bench从“会用工具”到“会改工具”2.1 Harness-Bench把工具调用框架的能力拆成三个可测维度先说 Harness-Bench。从名字就能看出来这个基准关注的是“harness”——也就是智能体和外部工具、API、执行环境打交道的那层框架。做过智能体项目的人应该都有体会真正让智能体“变笨”的往往不是大模型本身的推理能力而是工具调用框架没设计好。函数定义写得不清楚、返回结果解析不出来、工具调用的失败信息没有正确回传……这些工程细节才是决定一个 agent 好不好用的关键。Harness-Bench 的测试思路就是把这层框架能力显性化。据我看到的资料它把评测拆成了三个核心维度工具选择、参数注入、错误恢复。工具选择测的是智能体面对多个候选工具时能不能挑出正确的那一个。对应到真实场景就是一个 agent 的 prompt 里塞了三十多个 function definition它有没有能力从里面选中与当前用户意图最匹配的那个。这听起来简单但实测中会发现模型经常被名字相似的工具误导比如get_weather_by_city和get_weather_by_coordinate在城市名条件下就会纠结。参数注入测的是智能体能不能把对话中提取出的信息正确填入工具参数。这个维度更细它不止考“提取城市名”还考类型转换、默认值处理、必填参数缺失时的补全策略。举个例子用户说“帮我查一下明天上海到北京的航班”工具要求传入departure_date和city_code智能体必须先把“明天”换算成具体日期再把“上海”映射成SHA这样的机场代码任何一步出错都会导致工具调用失败。错误恢复是我认为这个基准最有价值的地方。它专门构造了大量工具返回错误码、超时、返回结构异常的场景看智能体能不能根据错误信息自我纠正。现实中这一块做得好的 agent 和做得差的用户体验差距极大。做得差的工具一报错就直接给用户一句“抱歉我无法完成这个请求”做得好的会先读错误日志发现是参数格式问题自动修复后重试。我在自己项目里复现过类似评测一个很深的体会是错误恢复能力其实和模型的工具调用格式有关系。如果框架要求每次工具调用必须是严格的 JSON 格式那么模型在犯错之后的自我修正率会明显更高因为修正只需要局部替换字段而不是整段重写。如果你的 agent 在错误恢复上表现差先别怀疑模型能力去看看你的 harness 层做没做“错误上下文拼接”。2.2 HarnessOpt-Bench把“优化能力”本身变成被测对象HarnessOpt-Bench 比 Harness-Bench 更进一步。前者测的是“在固定工具框架下能不能用好工具”后者测的是“能不能自己优化这个工具框架”。听起来有点套娃但它确实是自进化智能体评测里很关键的一环。这个基准背后的现实动机是现在的大模型 agent 应用工具集往往是工程师手工维护的。用户提一个新需求工程师去加一个新的 function definition某个工具调用老出错工程师去改描述、改参数。整个过程都是人在驱动。HarnessOpt-Bench 想验证的是能不能让智能体自己完成这些事也就是让 agent 在运行过程中根据任务失败反馈主动去修改自己的工具定义、增减工具、调整工具的描述风格和参数结构。相关任务设计大致分几类第一类是给一个基础工具集和一系列失败任务要求智能体定位“某个工具定义表述模糊”这个根因并改写工具描述第二类是给一个缺失的工具场景要求智能体自己生成新的工具函数并注册到工具库里第三类是工具重构把多个功能重叠的小工具合并成一个更通用的大工具或者反过来把一个大工具拆成粒度更细的多个子工具。这种评测的难度一下子就上来了因为“优化工具库”没有标准答案。同一个工具定义在不同模型看来可能一个清晰一个模糊。所以 HarnessOpt-Bench 这类基准在评分上通常不只看最终任务成功率还会考察工具定义的可读性、接口设计的合理性等软指标。这一点我在后面讲评测指标时会专门展开。我个人的判断是HarnessOpt-Bench 代表的“工具自优化”方向短期内不会成为主流 agent 的标配能力但它会是未来高自主性 agent 的核心技术点。如果你的目标是做一个能长期独立运行的 agent 系统这一层能力早晚要补上。2.3 两个基准的互补关系把两个基准放在一起看它们其实覆盖了自进化智能体在“与外物交互”层面上的两个阶段第一阶段Harness-Bench在固定框架内提升工具调用表现属于“用熟工具”。第二阶段HarnessOpt-Bench让智能体修改框架本身来适应新任务属于“优化工具”。两者不是替代关系而是递进关系。一个连现成工具都调用不准确的 agent让它去改工具定义只会越改越乱。从评测顺序上我也建议如果你的 agent 还在成长期先拿 Harness-Bench 这类基准把工具调用的底子打牢再考虑上 HarnessOpt-Bench。3. EvoAgentBench 与 Evo-Bench一体一面的自进化能力扫描如果说前面两个基准测的是“agent 与工具的关系”那 EvoAgentBench 和 Evo-Bench 测的就是“agent 与自己的关系”——也就是智能体能否在持续的任务执行与反馈循环中完成自我反思、经验沉淀、策略更新。3.1 EvoAgentBench 的持久化记忆与可演化环境EvoAgentBench 这个名字起得很直观Evo 就是 Evolution。根据我在资料里看到的信息它主打的是持久化记忆评测。所谓持久化记忆指的是智能体在完成一个任务之后能不能把有价值的经验以某种形式存下来并且在后续任务中真正用上这些经验。要测这个能力任务环境必须是持续性的。EvoAgentBench 设计了一批相关联的任务序列前一个任务的答案或过程信息很可能对后一个任务有帮助。比如先让 agent 完成一个数据清洗任务学到“这个数据集的时间字段格式不一致”这个经验然后在下一个任务中让 agent 做基于这个数据集的统计分析此时如果它能回忆起之前的经验就能少踩很多坑。说实话这种评测设计在思路上是对的真正的难点在于如何区分“真的调用了记忆”和“碰巧做对了”。我读到的资料显示EvoAgentBench 在任务设计上刻意安排了一些“如果不用上之前经验就会明显表现更差”的关卡通过这种强相关任务来放大记忆调用的收益从而让评测结果更有辨识度。这是很聪明的做法。另外这个基准还强调了“可演化环境”意思是评测环境本身会随着 agent 的表现动态调整难度。做得好的 agent 会遇到更难的任务做得差的 agent 会停留在相对简单的任务上。这其实模拟了真实世界的学习过程——能力强的人会挑战更难的问题而能力弱的人则会被困在低水平重复中。这种自适应难度的设计对评测“进化能力”非常关键因为它能拉开不同进化能力 agent 的长期表现差距。3.2 Evo-Bench 的连续任务与差异化测试集Evo-Bench 和 EvoAgentBench 在核心思想上是一致的但我读下来感觉它的覆盖范围更广一些不只聚焦在记忆上而是把自进化能力拆成了多个子能力来测。一个比较完整的自进化闭环通常包含五个环节执行任务、获取反馈、分析失败、制定改进策略、验证改进效果。Evo-Bench 的评测思路就是把这五个环节分别拆出来测看 agent 在哪一环掉链子。我看到的资料里它特别关注两个容易被忽视的点第一个是“分析失败”的深度。大多数 agent 在任务失败后都能说出“我失败了”但说不清楚“我为什么失败”。Evo-Bench 的评测任务里有很多是过程复杂的长任务失败原因往往不是单一因素而是多个环节的连锁反应。比如一个任务同时涉及信息检索、代码生成、结果验证三个环节最终结果错了agent 能不能把根因定位到“信息检索阶段的关键词选择失当”而不是笼统地说“结果算错了”。这个定位能力直接决定后续改进策略的有效性。第二个是“改进后的稳定性”。Evo-Bench 在测试集设计上做了一个差异化处理一部分测试任务和训练任务同分布另一部分则是分布外任务。这样做能同时检验两方面能力——同分布任务上可以看出 agent 是否真的在旧任务上进步了分布外任务上则可以看出 agent 的进化是否产生了泛化能力还是仅仅过拟合了特定任务。这个设计我非常欣赏因为很多自进化系统跑出来的结果是“老任务越做越好新任务完全没进步”这就是典型的过拟合式自我改进实际应用价值非常有限。3.3 两个基准的分工与取舍对这两个基准我的建议是这样用如果你的 agent 体系里特别重视记忆模块想单独验证“长期记忆到底有没有用”优先用 EvoAgentBench 的任务序列如果你想全面体检 agent 的自进化闭环看看它在哪个环节最薄弱那 Evo-Bench 更合适。要提醒的是这两个基准的成本都不低。因为它们都要求被测 agent 在完整闭环上运行“评测时长”可能是传统 benchmark 的十倍以上。有一次我跑一个自进化 agent 的完整评测光是任务执行加自我反思加策略更新就跑了将近二十个小时token 消耗非常可观。所以做这类评测之前建议先利用小规模子集调试好 agent 的进化逻辑再跑全量评测。4. RSI-Exam把递归自改进做成一场闭卷考试RSI 是 Recursive Self-Improvement 的缩写翻译过来就是递归自改进指的是智能体能够自己改进自身代码或推理策略然后用改进后的自己去进一步改进自己如此循环迭代。这是自进化智能体最激进、也最接近 AGI 想象的研究方向。RSI-Exam 这个基准大概是目前比较少见地把这一方向“考试化”的尝试。4.1 RSI-Exam 的考试形式和判分规则既然叫 Exam它天然就带了一套类考试的评测体系。我看下来它大致是这么设计的不直接给你一堆任务让你跑而是让 agent 面对一组“能力考题”要求 agent 针对每道考题写出自己的解法然后基于这个解法去生成一个“改进版本”再运行改进后的版本回答新的考题多次迭代。这个考试形式里最特殊的地方是“答案即代码”——agent 的每一次“答题”不仅仅是一个文字输出更是一段可以实际运行的程序或一套量化的推理规则。这样的好处是判分有客观依据你的回答能不能跑通、跑出来的结果正不正确都是硬指标。RSI-Exam 的判分规则里我记忆最深的是它对“改进幅度”的验证方式。它不是只看最终版本的成绩而是会记录每一次版本迭代的成绩曲线。一个真正具备递归自改进能力的 agent成绩曲线应该呈阶梯式上升如果成绩原地踏步甚至越改越差那就说明它只是在形式上做了“修改”动作并没有真正吸收反馈并优化自身。这种设计实际上阻止了一个常见的作弊方式agent 假装修改了代码实际上只是换了个表述。因为每一次提交的代码都会被真正执行、真正判分伪装没有意义。4.2 考试模式下递归自改进的边界在哪里RSI-Exam 把递归自改进纳入考试框架我认为是很有价值的尝试但它也暴露了这类评测的一个边界问题无论怎么改agent 的改进对象始终局限在“单次考试环境中”。也就是说agent 会针对当前考题集优化自己的策略但很难证明它能把这种优化能力泛化到考试之外的真实世界任务。举个例子如果考试的题目都是算法题agent 在递归自改进中学会的核心技能可能就是“更快地写出更优的算法代码”但它未必会把改进方向扩展到“学习如何向用户澄清需求”。这就是评测与真实应用的差距。所以我的建议是RSI-Exam 适合作为研究性质的自进化能力验证工具用来观察模型在极端迭代压力下会不会涌现出新的能力但它不适合作为生产级 agent 的能力验收标准。如果你在做一个实际产品不要因为 agent 在 RSI-Exam 上分数不高就否定它的工程价值评测目标和应用目标不一致结论很容易失真。5. 评测指标设计自进化智能体最难的部分基准的任务设计决定了“智能体做什么”但评测指标决定了“怎么判断智能体做得好不好”。对于自进化智能体指标设计是最难也最容易翻车的环节。这五个基准在这个问题上各有取舍我来聊聊我在阅读和实测中的一些观察。5.1 直接指标与间接指标的搭配自进化智能体的评测指标通常分两类直接指标和间接指标。直接指标是任务层面的硬指标比如最终任务成功率、单步操作正确率、代码运行通过率。这类指标好计算、好比较是大多说基准的基础。EvoAgentBench 和 Evo-Bench 的任务序列最终都会落到这些指标上。但直接指标有个致命局限它测的是“结果”而不是“进化”。两个 agent一个第一轮任务就成功了九成然后一直保持另一个第一轮只有五成成功率但每一轮都在稳步提升。到第五轮前者的成绩可能还是九成后者的成绩已经超过前者了。如果用最终成功率来一锤定音就完全看不到进化曲线的意义。所以这五个基准基本都会搭配间接指标来刻画进化过程。比较常见的间接指标包括单轮改进幅度、连续多轮的改进趋势、错误类型的迁移情况、改进策略的多样性。Evo-Bench 特别强调“改进后的稳定性”其实就是一种间接指标——它不关心你改了多少只关心你改了之后是不是仍然能保持稳定发挥。5.2 平缓曲线的陷阱如何判断真的在进化跑自进化评测的时候我遇到过很多次这种情况成绩曲线确实在涨但涨得很缓慢你很难判断它是真的在进化还是环境里的随机波动造成的假象。这里有一个经验值得分享不要只看成功率曲线要把“失败原因分布”也画出来。如果 agent 真的在进化那么它失败的原因分布应该会随时间发生结构性变化。比如最开始 60% 的失败都来自工具选择错误经过几轮改进之后工具选择错误占比降到了 20%此时就算整体成功率没涨多少也说明进化是真实发生的——它在解决旧的短板。反之如果失败原因分布一直没变化只是整体成功率在小幅波动那大概率是随机性在起作用agent 并没有真正学到东西。5.3 基线对照的必要性这五个基准里我觉得对“进化带来的提升”处理得最谨慎的是 RSI-Exam 和 EvoAgentBench它们都强调了与静态基线的对照。所谓静态基线就是同一个 agent 用固定策略跑同一批任务不做任何自我改进。如果自进化版本的最终成绩没有显著超过静态基线那所谓“进化”就值得怀疑。这个对照异常重要。因为自进化系统在评测过程中积累了更多的执行轨迹和反馈信息本身就存在信息优势。如果不能把这种“数据量优势”和“真实能力进化”区分开来评测结果很容易产生误导。我在自己的实验里会额外加一个对照让自进化 agent 只记录反馈但不允许调整策略拿它和完整自进化循环做对比。如果两者的最终成绩几乎一致那就说明真正起作用的不是策略更新而是信息积累这种“进化”在实际应用中一旦遭遇新任务就会立刻失效。6. 跑这些基准时踩过的坑以及给后来者的选型建议最后这部分说说我实际跑这些基准时遇到的一些问题顺带给想入手的同行一些参考。6.1 评测环境的非确定性是最大的敌人自进化评测的核心是要验证“agent 因为改进而变强了”。但如果评测环境本身有大量随机性这个结论就不可靠。举个例子我在跑一个接近 Evo-Bench 设计的评测时第一轮任务成功率为 62%改进后第二轮变成了 68%看似提升了 6 个百分点。但我连续跑了三次静态基线发现同一个未改进 agent 在不同随机种子下波动幅度就有 8 个百分点。一对比就明白了这 6 个百分点的提升在噪声范围之内根本不显著。解决这个问题的方法很朴素每个评测条件至少跑多个随机种子取平均。代价是评测成本成倍上涨但为了结论可信这笔成本省不得。6.2 评测集污染比想象中更隐蔽自进化评测里测试集污染发生在更隐蔽的环节——进化过程本身可能把测试信息“写进”了 agent 的记忆里。比如评测序列里前一个任务的数据在后一个任务里再次出现agent 如果记住了这些数据它就不能被算作“泛化能力提升”而是“背题了”。我在实际操作中发现要规避这个问题最好的办法是像 Evo-Bench 那样把测试集拆成两部分一部分和训练任务同分布另一部分完全分布外。评测时重点看后者分布外的成绩才是真实进化能力的体现。6.3 评测成本需要提前规划这五个基准里成本最低的应该是 Harness-Bench 这类聚焦工具调用的基准因为任务边界清晰、单任务耗时短。成本最高的是 EvoAgentBench 和 Evo-Bench 这类持续任务流评测一轮完整闭环可能要跑几十上百次工具调用和模型推理。RSI-Exam 的成本就更不用说递归改进等于让 model 反复运行改进后的代码token 开销是线性甚至指数级增长的。我的建议是分阶段走先用 Harness-Bench 验证工具调用底子再用 Evo-Bench 或 EvoAgentBench 做自进化闭环测试最后如果确实在做 RSI 方向的研究再上 RSI-Exam。顺序不要倒过来不然大概率钱花了结论还不干净。6.4 如何根据你的目标选择基准最后给一个简单的选型参考表是我根据自己的实践整理出来的评测目标推荐基准理由验证 agent 的工具调用框架是否可靠Harness-Bench覆盖工具选择、参数注入、错误恢复三大核心能力验证 agent 能否自主优化工具库HarnessOpt-Bench把优化工具定义、重构工具集作为被测对象验证 agent 的长期记忆是否有效EvoAgentBench用强相关任务序列放大记忆收益结果易辨认全面体检 agent 的自进化闭环Evo-Bench从执行、反馈、分析、策略、验证五个环节逐个考察研究递归自改进的上限RSI-Exam考试化设计闭环评估答案即代码判分客观如果你不是做研究而是做工程我的看法是Harness-Bench 和 Evo-Bench 是最值得优先落地的两个。前者能帮你快速排查工具调用层的工程质量问题后者能帮你判断 agent 在连续任务中是否真的在变强。其他几个更多是研究导向可以等有明确需求再深入。这五篇基准读下来我的整体感觉是自进化智能体的评测还远远没有定论但思路已经比一两年清晰多了。现在的评测设计已经开始关注“进化的真实性”比如失败原因分布变化、分布外测试、静态基线对照、多随机种子取平均。当评测设计不再被单一成功率牵着走的时候这个领域的结论可信度才算真正上来了。