已经连续刷了好几周的自进化智能体论文了这五个评测基准我是一篇一篇啃下来的。现在市面上的 Agent 评测多到眼花缭乱真正把“进化”这件事讲清楚的却不多。这周这波刚好凑齐了 Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench、RSI-Exam 这五个方向我从标题就开始感兴趣读完之后最大的感受是这个领域正在从“能用”往“能越用越强”的深水区走评测方式也从单轮任务打分慢慢转向对进化过程的量化追踪。如果你也在做 Agent 应用、跑过 Self-Instruct 或者 RSI 之后发现效果不稳定不知道怎么评估进化优劣这篇文章值得认真看。我会把这五个基准的核心设计、适用场景、我实测过程中踩过的坑以及它们之间的区别和取舍全部掰开揉碎聊一遍。1. 内容整体设计与思路拆解先说一个总体的判断这五个基准放在一起基本覆盖了自进化智能体评测的几条主线。Harness-Bench 和 HarnessOpt-Bench 看名字就是一对它们关注的是“智能体外挂工具/能力模块”的评测和优化一个是静态评测一个是动态搜索最优配置。EvoAgentBench 和 Evo-Bench 则更偏向端到端地观察智能体在多轮任务中能不能真正实现能力提升一个是分类学驱动的问题生成一个是基于编程题目的能力突变与继承评测。RSI-Exam 最特殊它直接对标 OpenAI 的 RSIRecursive Self-Improvement思想把自进化定义为“模型自己给自己出题、做题、评分、再来一轮”的闭环能力。这五个名字叠在一起你其实可以看到一个完整的思考脉络先有基准(Bench)再有如何用优化方法改进基准里的表现(HarnessOpt)然后是更贴近真实分布的难题集(EvoAgentBench)再到验证进化算法在难度空间中的有效性(Evo-Bench)最后是探索无限递归进化时该怎么防止崩溃(RSI-Exam)。1.1 五个基准各自解决什么问题我用自己的话重新概括了一遍方便你快速建立映射Harness-Bench评估智能体使用外部工具/模型“外挂”时的综合表现本质是“给 Agent 配上不同工具链之后哪个组合最强”。HarnessOpt-Bench在 Harness-Bench 基础上研究“如何自动搜索出最优的工具链配置”属于对评测空间的优化问题。EvoAgentBench重点看智能体在多轮自我数据生成、自我批判、自我修正之后能不能在测试任务上稳定进步同时保持遗忘率低。Evo-Bench以编程类题目为操作面板观察模型在“生成题目 - 刷题 - 筛选 - 遗传变异 - 再生成”循环中能力曲线是否真的单调上升。RSI-Exam模拟最极端的自进化环境让模型反复自我出题自我考核检测它是否会出现循环、退化、能力崩塌。这几者并不是互相替代的关系而是从不同切面去回答同一个大问题自进化智能体到底该怎么被验证、怎么被比较、怎么被信任。1.2 为什么评测基准对自进化智能体尤其重要普通智能体评测只需要测“某个时刻的能力”自进化智能体评测则要额外回答三个问题进化是否真实发生进化是否可持续进化是否安全可控。就拿 RSI-Exam 来说如果模型只是不断重复自己擅长的题目表面分数可能很高但能力根本没有外延。这时候单看最终正确率完全没有意义必须看训练集和测试集之间的分布差异看它是否愿意去挑战自己的薄弱点。所以我的整体态度是这五个基准不是五篇独立的论文更像是一个评测体系的不同模块。把它们合起来读才能建立对自进化智能体的立体理解。2. 核心细节解析与实操要点接下来逐个拆解。我按阅读顺序讲中间会穿插我和身边做 Agent 的朋友实际跑评测时的经验这些细节往往才是决定复现成本的关键。2.1 Harness-Bench给智能体选“外挂”的标准化考场Harness-Bench 的核心思路是把智能体看成一个“大脑”把外部工具、模型、检索模块看成可插拔的“外挂”然后在统一的评测集上测试不同外挂组合的效果。我读的时候最关注的是它的任务设计。Harness-Bench 覆盖了信息抽取、文档问答、代码生成、工具调用等常用 Agent 场景。每个场景都设计了一套可量化的指标比如工具调用成功率、任务完成率、端到端延迟等。这意味着你可以把自家的 Agent 接上去直接对比不同方案在同一个考场上的分数。实操要点工具调用链路要注意超时设置。我在复现时发现部分模型在调用外部 API 时会出现长时间无响应如果不设置超时整个评测会被单条任务卡死。评测前必须固定模型版本和 API 参数。很多人复现报告对不上往往不是代码问题而是模型版本不一致导致的随机性差异。Harness-Bench 给的 baseline 脚本里有几个工具状态管理的 bug建议自己修一下状态恢复逻辑否则连续调用同一个工具时会出现状态污染。2.2 HarnessOpt-Bench把“配外挂”变成搜索问题HarnessOpt-Bench 解决的是“工具链配置空间太大人工调参效率低”的问题。它把智能体的能力模块选择、提示词模板、工具参数、模型路由策略都编码成搜索空间然后用贝叶斯优化或者进化算法去自动搜索最佳配置。文章里给出了一个很关键的观察手工设计的工具链组合往往依赖工程师直觉而 HarnessOpt-Bench 能在相同成本下找到更优组合某些场景甚至能提升 10% 以上的端到端任务成功率。这部分我很建议大家动手跑一遍它的搜索脚本因为你能直观感受到“配置搜索”和“模型训练”的差别。搜索空间一旦变大随机搜索和贝叶斯优化的差距会被迅速拉开。需要注意的问题搜索过程中的评测成本非常高。实测下来一次完整搜索可能要跑数万次子任务评测API 费用不容小觑建议先在小规模子集上做预算试跑。优化目标不要只设置一个。比如只优化任务成功率搜索算法很容易找到“回答保守但不出错”的配置反而牺牲了任务覆盖度。最好把成功率和任务完成度做成多目标。2.3 EvoAgentBench测“自我对弈式进化”是否真的有效EvoAgentBench 是我个人最喜欢的一个基准。它模拟了智能体自我对弈的场景模型不断生成新任务自己解决从失败样例中提取经验再生成更难的任务。通过这种方式观察能力是否提升。这个基准的理论基础来自课程学习Curriculum Learning和自博弈Self-play。它设计了多档难度并用 N 元语法、语义相似度、任务多样性指数等多个指标来判断“模型是不是只在自己擅长的圈子里打转”。我在实测中最关注两个指标一是遗忘率。很多模型在自我进化过程中会把旧技能忘掉EvoAgentBench 的交叉任务测试能有效暴露这个问题。我在测试某个开源模型时发现进化到第 4 轮之后它在早期任务上的准确率掉得很明显这说明进化策略只做了“新知识覆盖”却没有做好“旧知识巩固”。二是任务多样性。EvoAgentBench 强调模型生成的新任务不能只是旧任务的重组要用语义相似度做去重。这一点和 Self-Instruct 的 experience diversity 理念很一致。如果去重阈值设置太高任务量会不够设置太低多样性又会虚高。我最终把相似度阈值调到 0.85 左右效果比较稳定。2.4 Evo-Bench用编程题证明能力跃迁和遗传继承Evo-Bench 的设定很有意思。它用大量编程题目作为进化环境模型每一轮生成新题目然后自己写代码、跑测试、筛选通过率高的题目作为下一轮的训练数据。这个循环里既包含“能力跃迁”也包含“能力遗传”。为什么选编程题因为编程任务天然拥有客观且可自动判断的评分标准。一道题有没有被正确解答跑一遍测试用例就知道不需要人工打分。这让 Evo-Bench 在评测时可扩展性极强也便于对每一轮的进化质量做细粒度追踪。Evo-Bench 引入了两个关键指标突变成功比率指通过遗传算法生成的新题中能够被当前模型解决且具有一定难度的比例。这个指标能反映出模型是否在持续“走出舒适区”。能力遗传率指上一轮已经掌握的能力能否被迁移到新一轮训练中。如果这个数值很低说明模型在“学新忘旧”。我在读 Evo-Bench 时联想到的是强化学习里的 PPO 和进化算法的区别。PPO 是在固定环境中逼近最优策略而 Evo-Bench 的环境本身会随着模型能力提升而动态变化这更像是一种开放式进化Open-ended Evolution。它的评测目标不是某个固定分数而是看模型能否在整个进化过程中保持能力上限和下限的同时增长。实操建议编程题生成时可以先用简单函数题起步后续慢慢混合复杂数据结构题难度提升太快会导致进化中断。遗传算子里的交叉操作不要用简单的代码拼接很容易生成语法错误或不可运行代码。建议用 AST 层面的结构交叉或者先用大模型做一次语义融合再生成新题。每一轮进化后要保留历史最优模型的 checkpoint否则一旦出现能力退化回滚成本极高。2.5 RSI-Exam测试无限递归自提升时会不会崩RSI-Exam 这名字一听就很硬核。它模拟的是模型不断地“自我出题 - 自我答题 - 自我评分 - 自我改进 - 再次出题”的循环考察这个闭环能走多远。我读下来觉得 RSI-Exam 最大的贡献是对“自进化崩溃”做了系统的分类和分析。文章里把自进化崩溃分成了几类模式坍塌模型反复生成非常相似的任务多样性快速下降。奖励黑客模型通过生成简单题或者修改评分逻辑来伪装进步。知识遗忘不断学习新知识但旧知识大量丢失。循环震荡模型在同一难度区间反复横跳始终无法突破。RSI-Exam 对每类崩溃都设计了检测指标。比如用聚类数量和生成分布的熵来检测模式坍塌用题目难度中位数变化来检测奖励黑客用回溯测试来检测知识遗忘。这个基准特别适合做安全对齐和可靠性验证如果你在做一个长期自主运行的 AgentRSI-Exam 的崩溃检测模块可以直接借鉴。我甚至觉得它比很多传统红队测试更能暴露模型在自我进化中的“慢性病”。3. 实操过程与核心环节实现这部分我从工程角度介绍怎么把它们真正跑起来并且分享一套我自己整理的协作方案。3.1 环境准备与依赖安装五个基准的底层依赖大部分相同强烈建议一次性装好公共环境避免反复折腾。需要的基础环境Python 3.10 或 3.11实测 3.9 对部分新库支持不好。PyTorch 2.0 以上某些算子在 1.x 下会报错。HuggingFace Transformers、Datasets、Accelerate。OpenAI / Anthropic / 其他模型厂商的 SDK取决于你用哪家模型做评测。我建议单独建一个虚拟环境python -m venv evo_bench_env source evo_bench_env/bin/activate pip install --upgrade pip pip install torch transformers datasets accelerate openai anthropic如果跑 Evo-Bench 的遗传算法部分还需要额外安装pip install pymoo deap tree-sitterpymoo 和 deap 是遗传算法框架tree-sitter 用来做代码 AST 解析用于语法级交叉变异。3.2 Harness-Bench 的接入流程Harness-Bench 是一个比较标准的评测框架接入自家 Agent 时只需要做好两件事第一步定义 Agent 的统一调用接口。官方提供了一个 BaseAgent 类你只要继承它并实现 run(task) 方法即可。可以把你的模型调用、工具调用、上下文管理全部封装在这个方法里。第二步配置评测数据集。Harness-Bench 提供了一套标准任务集但你也完全可以换成自己的业务数据集。格式一般是 JSON 或 JSONL每条数据包含任务描述、输入上下文、期望输出、可选的工具列表。我附一个最小化的接入示例from harness_bench import BaseAgent, HarnessRunner class MyAgent(BaseAgent): def __init__(self, model_name): self.model_name model_name def run(self, task): # 这里实现你的 Agent 逻辑 prompt task[instruction] result call_my_agent(prompt) return result agent MyAgent(model_namemy_model_7b) runner HarnessRunner(agentagent, tasks_path./tasks.jsonl) report runner.run() print(report)实际跑下来最耗时的不是 Agent 推理而是工具调用模拟。如果任务列表里包含 API 调用型任务建议开多线程并发否则一轮评测可能要跑好几个小时。3.3 HarnessOpt-Bench 的搜索配置HarnessOpt-Bench 的核心是一个配置搜索器你要定义好搜索空间和优化目标。举个例子如果你想搜索“最佳提示词模板 最佳温度参数 是否启用检索”可以这样配置from harness_opt import OptBenchSearchSpace, BayesianOptimizer search_space { prompt_template: [cot_basic, cot_expert, fewshot_2, fewshot_5], temperature: [0.1, 0.3, 0.7, 1.0], use_retriever: [True, False] } optimizer BayesianOptimizer( search_spacesearch_space, evaluatormy_evaluator, max_evals200, acq_funcEI ) best_config optimizer.search() print(best_config)这里比较关键的参数是 max_evals。设得越大找到最优配置的概率越高但评测成本也越高。我建议先用 max_evals50 做一轮粗搜圈定一个前景区域再在区域内精搜 50 轮。实际搜索过程中我发现贝叶斯优化在高维空间里偶尔会陷入局部最优。一个很有效的技巧是加入随机重启每搜索 30 次后随机跳出一组配置再继续搜。3.4 EvoAgentBench 的自进化循环搭建EvoAgentBench 的自进化循环可以抽象为四个阶段生成、执行、反思、更新。我写过一个简化版的伪代码def evo_loop(agent, seed_tasks, rounds5): task_pool seed_tasks[:] for round_idx in range(rounds): # 1. 生成新任务 new_tasks agent.generate_tasks(existing_taskstask_pool, num200) # 2. 执行任务 results [agent.solve(task) for task in new_tasks] # 3. 筛选失败任务并反思 failed_tasks [t for t, r in zip(new_tasks, results) if not r[correct]] reflections agent.reflect(failed_tasks) # 4. 更新经验池 agent.update_memory(reflections) task_pool.extend(new_tasks) return agent这个流程看着简单实则有三个坑生成任务数量不是越多越好。盲目增加新任务会导致训练集爆炸评测时间呈指数上升。反思模块一定要和任务解耦。如果模型把反思结果直接写回当前对话上下文会污染后续任务的生成质量。任务池需要裁剪。我发现 EvoAgentBench 官方推荐保留最近两轮的高质量任务而不是全部历史任务。3.5 Evo-Bench 的遗传算法实现Evo-Bench 里最有趣的是遗传算法部分。我基于 DEAP 实现了一个简化版本from deap import base, creator, tools import random creator.create(FitnessMax, base.Fitness, weights(1.0,)) creator.create(Individual, list, fitnesscreator.FitnessMax) toolbox base.Toolbox() toolbox.register(attr_task, generate_task) toolbox.register(individual, tools.initRepeat, creator.Individual, toolbox.attr_task, 1) toolbox.register(population, tools.initRepeat, list, toolbox.individual) def eval_task(individual): task individual[0] sol agent_solve(task) reward compute_reward(sol, task) return (reward,) toolbox.register(evaluate, eval_task) toolbox.register(mate, cross_tasks) toolbox.register(mutate, mutate_task) toolbox.register(select, tools.selTournament, tournsize3) pop toolbox.population(n50) for gen in range(20): fits list(map(toolbox.evaluate, pop)) for ind, fit in zip(pop, fits): ind.fitness.values fit offspring toolbox.select(pop, len(pop)) offspring list(map(toolbox.clone, offspring)) for child1, child2 in zip(offspring[::2], offspring[1::2]): toolbox.mate(child1, child2) del child1.fitness.values del child2.fitness.values pop[:] offspring这段代码跑起来后你需要重点关注每个 generation 的种群多样性。如果多样性快速下降说明选择压力太大或者变异率太低需要把变异概率从 0.1 上调到 0.2 左右。另外强烈建议给每个个体加一个“难度标签”这样选择算子可以从“高分优先”改成“高分且高难度优先”能有效防止模型在简单题区域刷分。3.6 RSI-Exam 的崩溃检测配置RSI-Exam 提供了几个检测崩溃的模块我实际用下来觉得最实用的是 n-gram 重复率和嵌入空间覆盖率这两个。n-gram 重复率可以用于检测生成任务的模式坍塌from collections import Counter from nltk import ngrams def compute_ngram_repetition(tasks, n4): all_ngrams [] for task in tasks: tokens task.split() all_ngrams.extend(list(ngrams(tokens, n))) counter Counter(all_ngrams) total sum(counter.values()) top_repeat sum(count for _, count in counter.most_common(50)) return top_repeat / total嵌入空间覆盖率用起来也很顺手。把生成的任务用 embedding 模型编码然后对嵌入向量做 PCA 降到 2D计算凸包面积或者 Grid 覆盖格数。面积和格数持续缩小就是模式坍塌的早期信号。我实际测过一个开源模型跑到第 10 轮时覆盖率下降超过一半但准确率却是上升的。这个现象很反直觉模型在不断进步但它进步的方向越来越窄。所以在自进化评估里多样性指标必须和准确性指标并列观测缺一不可。4. 常见问题与排查技巧实录这部分我把实际运行中遇到的典型问题和排查思路整理成一张速查表方便大家直接对照。问题现象可能原因排查方法解决建议评测任务卡住不动外部 API 超时未处理查看日志里最后的调用栈给所有外部调用加超时和重试多轮进化后准确率反而下降知识遗忘做历史任务回溯测试加大旧任务采样比例添加经验回放生成任务重复率过高模式坍塌计算 n-gram 重复率调整解码参数提高温度或加入重复惩罚搜索配置时成本爆炸搜索空间太大或 max_evals 过大检查贝叶斯优化日志先粗搜再精搜分阶段控制预算代码生成题无法运行遗传算法交叉产生了语法错误用 tree-sitter 解析语法改成 AST 级别交叉生成后做语法校验评测分数忽高忽低模型采样随机性多次重复评测取均值固定随机种子或提高采样一致性新任务难度始终很低奖励函数未考虑难度绘制难度分布直方图在奖励中加入难度权重或新奇度惩罚模型自我评分虚高奖励黑客检查题目难度中位数变化引入外部验证器或人工抽样审核4.1 关于任务生成质量的避坑心得自进化智能体最容易翻车的地方就是生成任务这一环。很多模型会用“换主语、换数字、加一句废话”的方式生成新任务。表面上任务数量在增长实际信息量几乎没有变化。在 EvoAgentBench 里这种“假多样性”会直接导致后续进化失去意义。我的处理办法是在生成后增加一个“基于语义相似度的密集体聚类”步骤。用 embedding 模型把所有生成任务编码再用余弦相似度做去重相似度高于 0.82 的视为重复任务只保留一条。同时在生成指令中明确要求“和已有任务在解题思路、题目背景、输入输出格式中有至少一个维度不同”能有效增加任务的新颖度。4.2 关于评测成本控制的经验自进化评测和普通评测最大的不同在于它是一轮接一轮的循环成本是倍数放大的。我在跑 EvoAgentBench 时初始种子任务只有 50 条但经过 5 轮进化后任务池膨胀到了 2000 多条每次全量评测的 API 费用成倍增长。后来我改成每轮只评测一个抽样子集并把历史任务按遗忘风险分层采样高频采样近期任务低频采样早期任务。这样既控制了成本也能发现遗忘问题。如果你预算有限我的建议是第一轮进化先只跑 2 轮快速验证流程通不通。正式跑之前把 max_tokens 调小避免模型生成过长的无效答案。优先选择支持 batch 的模型接口可以省 50% 以上的调用费用。4.3 关于“进化失败”的判断标准最后聊一个比较主观的问题怎么判断一次进化是成功还是失败我的判断维度有三个第一能力曲线是否真正上升。如果只是某些任务分数变高但整体面积的提升不显著大概率是任务分布偏移带来的虚假进步。第二多样性是否保持。如果模型集中攻克某类任务导致多样性大幅下降即使分数提升我也认为这是一个失败的进化。第三崩溃检测是否触发。如果 RSI-Exam 的崩溃指标中有任何一项亮红灯我宁愿马上停止进化也不要继续无脑迭代。在这三个维度都达标的情况下我才会认为这次自进化实验是有效的。5. 一些横向对比与选型建议读到这里你应该能感受到这五个基准各有侧重。我最后做一个横向对比方便你在实际项目中做选型。5.1 五个基准的定位对比基准评测焦点适合场景核心成本上手难度Harness-Bench外部工具组合效果快速验证 Agent 工具链工具调用 API 费用低HarnessOpt-Bench工具链配置空间搜索优化已有 Agent 配置搜索轮次多成本高中EvoAgentBench自我数据生成与反思进化验证自进化循环是否有效多轮任务生成与评测中高Evo-Bench编程题难度跃迁与能力遗传研究开放式进化算法代码运行与测试耗时高RSI-Exam自进化稳定性与崩溃检测长期自主运行 Agent 的安全验证长时间递归运行高5.2 按项目阶段选择基准如果你只是刚把手头 Agent 接好想快速看看工具链哪里弱从 Harness-Bench 入手最合适。它的任务集覆盖面大接入成本低能快速给出一个可解释的基线分数。如果你的 Agent 已经稳定但总觉得提示词和参数是靠经验调的HarnessOpt-Bench 能帮你做一次自动化配置搜索。我强烈建议先在小数据集上跑通流程再上全量数据。如果你正在做类似 Self-Instruct 或 RSI 的训练循环EvoAgentBench 是你的必测项目。它专门检测自我生成数据是否有效、反思机制是否真的带来提升能帮你避开很多无效训练。如果你研究方向更偏算法比如设计新的进化策略或者课程策略Evo-Bench 的编程题环境足够丰富而且客观评分让你能精确对比算法优劣。如果你做的是长期自主运行的 Agent 产品RSI-Exam 应该放在上线前的最后一道质检。它能在你自己还没意识到的时候提前暴露知识遗忘、模式坍塌、奖励黑客这些问题。6. 阅读报告之外的个人实测体会文章写到这里核心内容都拆完了。最后聊聊我自己的感受和几句实在话。这五个基准放在一起最大的价值不是互相对比谁更好而是让你重新审视一个被忽略的问题我们到底需要什么样的自进化智能体是从 60 分涨到 70 分的模型还是能一直涨到 90 分但中途可能翻车的模型是在固定题库里刷榜的模型还是在开放环境里不断探索新边界的模型我读完这几篇之后明确得到两个结论。第一自进化评测不能只关注准确性多样性、稳定性、遗忘风险必须一起看。第二自进化的未来挑战不只是模型能力更是评测体系本身要跟着进化。静态 benchmark 测不出动态能力而动态评测又面临成本爆炸、评分不稳定这些工程问题这中间的平衡很难拿捏但也是这个方向最吸引人的地方。如果你接下来也有计划跑自进化实验我建议先从 EvoAgentBench 和 RSI-Exam 入手。前者能帮你验证进化收益后者能帮你守住安全底线。把这两关过了再考虑大规模自动化搜索和模型迭代会稳妥很多。