1. 为什么突然开始盯上“自进化智能体”的评测最近大模型圈子里智能体已经从“能调工具”卷到了“能自我改进”但随之而来的一个尴尬问题是你怎么证明一个智能体真的在“进化”而不是单纯地把上下文窗口撑大、把少量样本的提示词写得更好我自己在跑智能体项目时也有同感。第一代智能体只要能用 ReAct 调 API 就算成功第二代开始比多轮规划第三代大家都在谈“这个智能体能不能从失败里学”。可一旦要量化“从失败里学”这件事翻遍公开资料发现评测基准还停留在静态任务集上——给一堆固定题目跑一遍打分完事。静态评测根本测不出“自我进化”这件事因为进化隐含一个时间维度的比较你比昨天的自己强多少你用更少的样本解决了以前解决不了的问题吗最近集中读了五篇围绕自进化智能体的评测基准论文分别是 Harness-Bench、EvoAgentBench、HarnessOpt-Bench、Evo-Bench 和 RSI-Exam。读完最大的感受是这五个基准不是在造新轮子而是在把“自进化”这个模糊概念拆成可测量的维度。它们分别对应了工具链智能、多智能体协同进化、工具链优化、个体持续进化和递归自我改进。一句话总结我的整体印象——2025年的智能体评测重心已经从“你做对了多少题”转向“你比上一轮强了多少、强在哪、还能不能继续强下去”。这篇文章不是论文翻译我会把每个基准的设计思路、评测重点、适合测什么场景、实际使用时容易踩的坑以及它们之间的差异逻辑按我自己的理解拆开讲。对正在做 Agent 应用开发、准备搭评测体系、或者纠结“我的智能体到底进没进化”的朋友应该能省一些读原论文的时间。2. 五种“进化评测”思路到底在测什么2.1 Harness-Bench给智能体换“驾驶舱”而不是考驾照Harness-Bench 的核心出发点很朴素同一个大模型套上不同的 harness工具链/执行框架之后任务完成度会差很多。这里的 harness 你可以理解成智能体的“驾驶舱”或“外骨骼”——它决定了智能体能看到什么信息、能调用什么工具、能如何编排步骤。同一个 LLM装在差的 harness 里可能连多步检索都做不顺装在一个设计良好的 harness 里却能完成复杂工具链。它评测的不是单次任务的最终答案而是围绕“工具链质量”这一维度建立了一套测评框架。我读下来的核心理解是Harness-Bench 把 harness 拆成了三类结构——无结构、半结构、全结构然后观察同一个智能体在不同结构下的表现差异。评测任务涵盖推理类、多步检索类和环境交互类任务难度做了梯度设计。实际观测指标不是只看最终正确率还看重试次数、工具调用次数、信息损失率这些执行过程指标。举个例子一个“半结构”的 ReAct 式 harness和“全结构”的 DAG 式工具编排 harness 相比在处理多依赖任务时过程指标的差异远大于最终答案的差异——这就说明最终分数往往掩盖了工具链层面的效率差距。适合谁来用我个人觉得Harness-Bench 最大的价值是给“正在纠结用哪种 Agent 框架”的团队做客观参照。很多团队在 LangChain、AutoGen、自研框架之间反复横跳靠的是感觉和社区文章而不是可复现的评测数据。Harness-Bench 的思路就是把这层体验用数据固定下来。2.2 EvoAgentBench一群人一起进化才叫真进化EvoAgentBench 关注的是多智能体系统的协同进化能力。单智能体会调工具不算本事多个智能体组成团队在动态环境中共同完成任务、互相反馈、迭代策略这才是多智能体系统里真正的硬骨头。这个基准把评测分成了三层。最底层是单体基础能力评测往上是对手建模与协作能力最顶层才是多智能体协同进化评测。任务分布在博弈、辩论、合作三类经典场景里。它用的环境不是开卷考试式的静态问答而是带对抗性的、信息不完全的动态任务——比如多个智能体要谈判、要辩论、要互相说服任务本身没有一个标准答案只有一个最终状态。说到评测指标EvoAgentBench 的策略是分阶段看进化。策略多样性、适应速度、协作效率这些指标被拆开来观察。不管最终结果赢没赢只看策略库有没有迭代、适应速度有没有变快。这个思路对做多智能体应用的人很有启发——很多时候我们评估多智能体系统只看任务成功率忽略了“这个系统能不能在交互中学会新策略”这层关键能力。我第一次在自研的多智能体协作系统里引入这套分层评估思路时发现了一个之前完全被掩盖的问题系统在固定剧本里表现很好但一旦对方策略变化整体协作质量掉的非常快。EvoAgentBench 的思路相当于给多智能体团队照了个 X 光能看出谁在拖后腿、谁的策略更新机制没生效。2.3 HarnessOpt-Bench从“会用工具”到“会改工具”如果说 Harness-Bench 是给智能体一个固定的工具箱看它会不会用那 HarnessOpt-Bench 就是考智能体能不能自己改进工具箱。这一层设计思路一下就拉高了评测的复杂度。HarnessOpt-Bench 的评测对象除了大模型本身还包括它操作的 harness 配置。任务不再是单纯的“调用 API 完成目标”而是“通过分析过往经验优化 harness 模板或工具选择策略再在下一次任务中验证优化是否有效”。这其实切中了自进化智能体的核心近乎定义级的问题如果一个系统不能改进自己的执行框架那它所谓的进化就只是参数层面的迁移学习而不是框架层面的迭代。HarnessOpt-Bench 构造了一个双层评估循环内层是任务执行循环外层是 harness 优化循环。评测时要看智能体能否生成一个比原有 harness 更优的新配置——比如给 ReAct 模板增加一个记忆检查步骤或者根据任务特征动态选择工具子集。观测点包括优化后任务提升幅度、优化策略的可迁移性、以及优化过程中是否出现策略崩溃。这个基准我最喜欢的一点是它在防“刷分”上做了设计——如果智能体只是把 harness 改得更适配特定任务但换一批新任务就失效这个优化会被判定为过度拟合得分很低。这种评估设计对实际工程非常有参考价值因为真实业务场景里根本没有固定的任务集等着你优化。2.4 Evo-Bench一次任务拆成万步看能不能一直进化Evo-Bench 是五个基准里最“暴力”的一个。它的思路很直接如果你想让一个智能体变强就让它长时间在大量任务里滚动进化看看它到底会不会越滚越强。它设计了一个包含上万步的进化评测流程每轮任务在流程中逐次推进任务难度和复杂度会向越来越深的方向发展。智能体不是被投喂一大堆独立任务而是处在一个连续的任务流里前一轮的结果会影响后一轮的环境状态。评测维度包含了正确率变化趋势、泛化能力变化、以及适应成本这三块。Evo-Bench 最核心的观测点其实是“进化曲线”——不是看终点能力而是看整条曲线的形态。比如存在三类典型的曲线平滑上升型稳定进化、先降后升型经历了阶段性能量损耗后的重组进化、平台期突跳型依靠某个关键经验触发的阶跃。这三类曲线在实际评测中分别对应不同的内部机制这是我读下来觉得最有价值的信息——它把“进化”这种抽象概念具象成了可诊断的曲线形态方便定位系统瓶颈。想做 Agent 持续进化能力的团队Evo-Bench 的长流程设计值得借鉴。它强制评测方思考一件事你的系统跑一万步之后会不会因为经验积累太多而变得过拟合上一步的环境还是能持续抽象出更通用的策略2.5 RSI-Exam让AI给自己出题再自己考自己RSI-Exam 的野心最大。它直接测试**递归自我改进Recursive Self-Improvement**能力场景设置是智能体需要基于当前已有经验自主生成新的训练样本或评测任务然后用这些新样本来提升自己的后续表现。它的评测核心是一个迭代更新循环一个基座模型在某个领域执行任务执行结束后要主动提出“我在这个过程中学到了什么”然后把这个学习成果转化为新的评测样本再在下一轮用这些样本测试改进后的自己。RSI-Exam 通过设计领域多样的考题比如逻辑推理、数学证明、策略规划来考察“领域内样本生成质量”和“跨领域迁移质量”。这个基准里有一个设计让我印象很深它不只测“改进后分数的提升”还测“生成的样本本身的质量”。也就是说如果模型只是简单地把原题换个数字重新生成生成的题目没有新的难度梯度那即使下一轮分数高了也被判定为低质量 RSI。这个设计狠狠嘲弄了那种“自己出题自己考考出来的分自己开心”的套路。RSI-Exam 适合用来判断一个系统有没有潜力跑通“学习—生成—验证—再学习”的完整闭环。目前大多数智能体系统离真正的递归自我改进还差得很远RSI-Exam 算是把这个概念往前推了一大步。3. 五个基准放一起看能看出什么门道3.1 评测对象从“智慧”转向“可改进性”五个基准放一起最明显的趋势是评测对象已经从“静态能力”转向“动态可改进性”。传统基准考的是“你会什么”这五个基准考的是“你学得会什么、学得多快、学完之后能不能自己更新学习方式”。这背后有一个很重要的原因基础模型能力已经进入平台期靠堆参数提升能力的路正在变窄。模型供应商之间真实差距未来不会体现在“初始能力”上而是体现在“谁能在有限样本里迭代得更快”。评测体系跟着转向“动态可改进性”本质上是对产业风向的回应。做应用层的人如果现在还抱着“静态跑分优化提示词”不放很快就会吃大亏。我个人冒一个判断未来半年到一年智能体能力评测会快速从“专业考试”转向“体检报告”——考试只给一个分数体检报告会告诉你身体各系统的状态、变化趋势、潜在风险点。上面五个基准每一家都在往“体检报告”的方向上走。3.2 评测指标从“结果正确率”扩展到“过程特征”我没有逐个列出所有指标但汇总来看五个基准大量出现了传统基准不会用的过程类指标重试次数、工具调用路径复杂度、信息损失率、策略多样性、适应速度、协作稳定性、样本生成质量。单一的正确率只能说明“你做成了没有”而过程指标说明的是“你是怎么做到的、下次换成类似但不完全相同的任务你还有没有可能做到”。这对实际工程影响非常大。举个例子两个智能体在某个任务上都是 80% 成功率但一个靠暴力重试、一个靠清晰的工具调用路径规划后者的生产价值明显高得多。只看结果指标这两个模型在你眼里是完全一样的只有把过程指标接入评测体系才能做出正确选择。3.3 对“刷分”的防御进化不等于适应单一环境另一个共同点是五份工作都多多少少对“过拟合式进化”做了防御性设计。Evo-Bench 通过长流程滑动窗口观测泛化能力HarnessOpt-Bench 会验证优化是否迁移到了新任务集RSI-Exam 会独立评估生成样本的质量。这说明自进化评测的核心难点早就不是“怎么让模型改得更准”而是“怎么区分真正的进化与局部最优的过拟合”。3.4 五个基准之间的逻辑关系我按自己理解画了一条关系链。Harness-Bench 和 HarnessOpt-Bench 是一对前者看“用工具”后者看“改工具”属于工具链维度。EvoAgentBench 和 Evo-Bench 是一对前者看“多智能体协同进化”后者看“单智能体持续进化”属于进化机制维度。RSI-Exam 则站在最高层考察“能不能自主生成数据来帮助自己进化”属于元能力维度。基准评测对象核心指标倾向一句话概括Harness-Bench工具链/执行框架质量工具调用效率、过程损失率同一个大脑换不同驾驶舱表现差多少EvoAgentBench多智能体系统协同进化策略多样性、协作效率、适应速度一群智能体能不能在交互中共同变强HarnessOpt-Benchharness 优化能力优化幅度、迁移性、策略稳定性能不能自己改进自己的执行框架Evo-Bench单智能体长周期进化进化曲线形态、泛化变化大量连续任务里能力是否持续增长RSI-Exam递归自我改进能力样本生成质量、迭代收益能不能自己出题考自己越考越强4. 实际跑评测时最容易踩的四个坑4.1 拿单轮结果代替进化趋势这是最容易犯的错。五个基准几乎都强调“时间维度的变化”但很多人实际评测时还是拿“最终正确率”说事。我在自己项目里跑过一个智能体单轮任务成功率从 61% 提升到 73%乍一看是变强了。但把走势图拉出来看它其实是从第三轮就开始过拟合后面一直在原地波动。只看终点分数会误判系统的进化健康度。建议跑自进化类评测时一定保留曲线数据至少画出成功率随迭代的变化趋势。曲线形态比终点值重要得多。4.2 混淆能力进化和上下文填充很多智能体表面上的“进化”其实是上下文窗口被动态填充后的假象——前面十几轮的失败样本都堆在上下文里模型只是学会了模仿近期样本的模式。这不算进化这只是长上下文带来的非参数记忆。要测真实的进化能力需要隔离掉上下文注入带来的增益否则评估结果会被显著高估。我自己的做法是在评测时设置“冷启动测试”——清空上下文记忆后让智能体面对同分布新任务看能力是否依然保持。如果一清空就打回原形说明进化没有沉淀到可复用的策略层。4.3 进化多轮后出现策略漂移长时间运行进化循环后系统经常出现策略漂移初始阶段表现很好进化几轮后策略库越来越复杂反而把早期有效策略覆盖掉了。EvoAgentBench 和 Evo-Bench 都在不同层面触及了这个问题。在真实项目里我见过一个智能体在进化后反而变笨——它学到了太多新策略决策时不知道选哪个推理时间翻了三倍效果还没以前好。解决办法是在进化循环里加入“策略回滚点”和“策略审查机制”。每次策略更新后做一次回归测试如果回归指标跌破阈值就自动回滚。4.4 生成本评价混淆了模型能力和评测设计这一点专门针对 RSI-Exam 这类带生成环节的评测。在分析结果时要把“生成样本的质量”和“用生成样本训练后的提升”分开看。很多分析会笼统地说“模型在 RSI 上表现好”但表现好可能是模型生成了一堆简单样例然后用这些简单样例刷高了后续分数。RSI-Exam 的设计者显然意识到了这个问题但实际读报告时还是经常看到有人把这两个维度混在一起下结论。4.5 评测集规模不够导致的方差问题最后一个很现实的坑自进化评测通常要跑多轮迭代计算成本高很多人会把每轮评测的样本量缩得很少。但自进化过程天然带高方差——同一个系统跑两遍流程进化曲线可能差异巨大。样本量不足结果会非常不稳定一个随机种子都可能改变结论。我踩过这个坑后现在的工作习惯是先跑一遍完整的进化流程确认曲线稳定之后再做小样本快速验证而不是反过来用少量样本就下结论。5. 评测框架的组件化设计参考你不一定需要整套复现这五个基准但它们的设计可以拆成组件用来搭自己的评测体系任务流组件来自 Evo-Bench把任务做成前后关联的长流程前一轮结果影响后一轮环境终端支持自定义任务难度梯度。进化曲线分析组件来自 Evo-Bench记录每轮关键指标并自动提取曲线形态特征——平滑上升、先降后升、平台期突跳。工具链对比组件来自 Harness-Bench同一个模型套不同工具链跑任务自动对比工具调用效率和过程损失。优化迁移检测组件来自 HarnessOpt-Bench一轮优化完成后用分布外的新任务验证优化效果是否迁移。多智能体协作审计组件来自 EvoAgentBench记录每个智能体的策略更新记录追踪协作策略的演化轨迹。样本质量评估组件来自 RSI-Exam对智能体生成的训练样本做独立难度和质量评估防止“自己出题自己考还自己夸自己”的作弊行为。这六个组件之间是解耦的可以按需组合。轻量级验证用“任务流进化曲线”完整评估再引入其他组件。组件化设计的好处是不用把五个基准全部跑通就能获得方法论层面的增益。6. 从评测结果看自进化智能体的能力天花板6.1 当前自进化更接近“参数记忆”还是“策略迁移”把五个基准的结果汇总后我个人判断目前主流大模型的自进化能力还比较初级多数情况下的能力提升来自“参数记忆”——模型在重复任务上越做越顺但换一个分布就会打回原形。真正达到“策略迁移”级别的自进化——也就是把经验抽象成可复用的解题思路、并能成功迁移到新领域——在公开评测集上还不普遍。这个结论对实际工程有两个指导意义。第一别高估智能体自我进化的可靠性进化后的系统必须配套回归测试否则生产环境可能被一个过拟合的“伪进化”模型坑死。第二也别低估自进化评测的价值。正因为大多数系统做不到评测体系才有区分度才能筛出真正具备持续学习能力的系统。6.2 能力分层的观察初级改进→方法改进→目标改进五个基准放在一起让我看到了一条自进化能力的分层路径。第一层是初级改进执行结果层面的小修小补比如失败后换个工具重试。第二层是方法改进改进解题流程、调整推理策略、优化工具链配置。第三层是目标改进系统能够为自己设定子目标并重新定义任务。RSI-Exam 已经触及了第二层与第三层的边界——生成新样例本质上是重定义“学习什么”。绝大部分现有系统还停留在一到二层之间这既是现实的约束也是未来可以发力的空间。6.3 对应用层开发者的判断参考对应用层开发者来说如果你想判断一个智能体产品是不是“真进化”建议按这个顺序问三个问题第一它的能力提升是否来自历史经验的沉淀还是单纯靠提示词堆叠第二把历史经验清空后在新任务上是否还能保持优势第三它能不能自主生成有价值的训练数据而不是依赖人工标注三个问题都答“是”的系统才是真正值得投入资源的自进化系统。否则你更需要的可能是传统的数据迭代 微调管线。7. 评测只是开始真正的难关在评测之外五个基准的共同特点是“把进化这件事变得可见”但它们也都承认一个前提评测环境与真实环境的分布差异是永远存在的。评测里设计得再好的动态任务流和现实业务中充满长尾和噪声的输入相比都只是简化模型。所以我对自进化智能体的态度是评测分数高不等于生产环境可靠但评测分数低一定意味着系统还有明显短板。评测体系是方向判断工具不是验收工具。它会告诉你“这个方向有没有戏”但不会告诉你“投产后会出什么幺蛾子”。在我自己的实践里真正的自进化系统至少还需要解决三个评测之外的问题一是安全约束自进化系统自主生成新策略时如何保证策略不出边界二是成本控制多轮进化循环的推理成本增长远比想象中快三是可解释性系统进化之后你还能不能解释它为什么这样做。这些问题在五个基准的论文里着墨不多但它们恰恰是工程落地时绕不开的坎。评测负责指出“你的系统能不能进化”工程负责回答“进化后的系统值不值得用”。读这五篇论文的收获如果只能留下一句话我会说别迷信自进化但也别低估它——先用评测看清系统的真实进化能力曲线再做取舍。后面我打算把这五个基准的官方代码跑一遍出一个横向对比的实测数据到时候再整理成文。想持续关注自进化智能体评测进展的话可以留个记号我会在评论区同步后续进展。