
理解RSI:自进化AI综合指南
RSI 尚无单一范式,本文用「改什么·怎么继承·谁来改·何时改」四轴,把自演化 Agent 收进一张可复用分析框架。
RSI(递归自我改进,Recursive Self-Improvement)近来备受关注。与之密切相关的术语包括 self-evolution、Self-Evolving 和 Self-Improving。
该领域仍在快速发展,尚未收敛到单一技术范式。现有工作在改进对象和改进方式上都差异很大:有些方法更新模型参数,有些积累上下文或记忆,有些演化 Skills,还有些直接修改工具、控制流或 Harness 代码。因此,RSI 很难用任何单一方法或技术路径来描述。
本文借鉴 Awesome RSI 仓库(网站),从分类学视角梳理现有的 RSI 工作。我们从多个维度比较自演化系统之间的联系与差异。读完之后,你应当对 RSI 有更清晰的理解,并掌握一个分析框架:当你遇到一个新的自演化系统时,能够迅速判断它与现有工作的关联与区别。


1. RSI 究竟是什么?
本文将 RSI 定义如下:Agent 与环境交互后,利用任务轨迹和反馈,通过更新机制修改自身状态,更新后的状态再参与后续任务,从而提升未来表现。


对于第 t 轮:
• A(t) 是当前的 agent。
• τ(t) 是完成任务过程中产生的轨迹。
• f(t) 是 agent 收到的反馈。
• U 是更新机制。
一个 agent 由模型和 harness 组成。U 可以更新模型的参数,也可以更新 harness 的上下文、记忆、技能、工具或代码。由此得到的 agent A(t+1) 会被用于后续任务。
更新可以由 agent 自身执行,也可以由教师或元 agent 执行,或者由外部训练过程执行。
2. RSI 改变了什么:参数、上下文、记忆、技能与 Harness 代码
现代智能体可以抽象为 Agent = Model + Harness。Model 提供理解、推理和生成的基础能力。Harness 组织模型如何接收信息、积累经验、调用工具和完成任务;它包括上下文、记忆、Skills、工具和 Harness 代码。
不同的 RSI 方法可能修改该系统的不同部分。参数演化改变 Model。上下文、记忆和 Skill 演化修改 Harness 中的持久状态。工具和 Harness 代码演化改变 Agent 的动作空间与控制流。

2.1 参数演化
参数演化将经验写回模型权重。其优势在于,知识可以直接被模型内化,而无需每次检索外部材料。代价是更新成本高,难以定位和逆转,而且一次有问题的训练更新可能影响许多不相关的任务。
代表性工作:自适应性语言模型

SEAL 从一个实际问题出发:语言模型在部署之后会不断遇到新的知识和任务,而它们的权重通常保持不变。作者希望模型能够自行决定“它应当如何训练自己”,而不依赖一个单独的适应网络。为此,模型不仅为每个新输入生成答案,还生成一个自编辑。自编辑是一种自我更新方案,可以重新组织原始信息、生成训练样本、指定优化超参数,或调用工具进行数据增强和梯度更新。
随后,系统根据该自编辑执行监督微调。经过 SFT 之后,经验从临时文本转变为持久的权重更新。模型最初并不知道哪些自编辑真正有用,因此 SEAL 增加了一个外层强化学习循环:在应用某个自编辑之后,重新测量更新后模型的下游性能。该结果成为奖励,用于训练模型在未来生成更有用的自编辑。
作者在知识整合和少样本学习任务上评估了 SEAL。模型的自编辑不仅可以指定训练数据,还可以指定这些数据应如何组织以及训练应如何配置。系统实际上会根据每个自编辑更新模型,然后依据更新后模型的下游得分选择更有效的方案。因此,对候选自编辑进行微调和评估仍会带来可观的计算成本。
2.2 上下文演化
上下文可以理解为当前推理过程中模型直接可见的材料,包括任务要求、对话历史、当前计划、Prompt、规则以及整理好的外部信息。上下文演化则根据任务结果重新组织这些材料,使模型在下一次推理时看到更有用的信息。例如,系统可以删除无关信息、压缩过长的历史、加入失败教训,或重写当前计划。
上下文与记忆的区别在于,记忆是存储在外部、等待被检索的信息。只有当一条记忆被检索并插入模型输入之后,它才成为当前上下文的一部分。
代表性工作:Prime Agent: A Self-Improving RLM Harness

长时程任务之所以困难,不仅因为问题本身复杂,还因为它们可能远远超出一个模型调用的范围。例如在大规模软件开发中,Agent 可能连续工作数小时,反复阅读代码、运行测试、记录结果并修改计划。然而,模型每次调用时能直接读取的上下文是有限的:保留全部历史很快就会超出上下文窗口,而丢弃历史又会让模型忘记自己的进展。
Prime Agent 通过为模型提供一个可长期持久化的外部工作区来解决这一问题。它使用一个持久化的 IPython REPL 来保留代码、变量、文件和计算结果。模型可以利用程序处理长文本、访问外部资源,或执行测试时计算。Continual Harness 记录任务历史、记忆、Skills、Prompts 以及子 Agent 配置。即使任务被暂时中断,后台进程也会保留工作区。当工作恢复时,Agent 可以从中断处继续,而无需重新阅读所有内容。
对于可分解的任务,Prime Agent 还允许主 Agent 创建多个子 Agent。这些子 Agent 处理各自独立的问题,并将结果直接返回给主 Agent,从而支持并行探索与结果聚合。
Prime Agent 不更新模型参数。它将任务历史和中间结果存储在外部。当模型再次运行时,Harness 会检索当前所需的材料并将其组装到上下文中。
2.3 记忆演化
记忆演化将经验写入独立的长期存储,并在后续任务需要时将其检索出来。系统必须从日志中筛选有价值的信息,将具体经验转化为可复用的教训,并根据新证据修正旧记忆。否则,失败的经验和错误的因果归因可能会持续影响未来的任务。
代表性工作:ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory

ReasoningBank 面向持续性的任务。Agent 在完成任务的过程中可能产生可复用的经验,但传统系统通常会在事后丢弃这些信息,然后在下一个任务中重蹈覆辙。保存整条轨迹同样不理想,因为原始轨迹冗长,且包含大量偶然细节。因此,ReasoningBank 将成功与失败的轨迹转化为简洁、可复用的经验。
当新任务到来时,Agent 从记忆库中检索相关策略,以指导当前交互。任务结束后,Agent 首先判断任务是否完成,然后从轨迹中提取新经验并写回记忆库。成功的轨迹提供有效方法,而失败的轨迹则记录应当避免的决策。
作者还提出了记忆感知的测试时扩展(MaTTS):Agent 对同一任务进行更多次尝试,从而产生更丰富的成功与失败样例,并从中提炼出更高质量的记忆。这些记忆随后指导后续的尝试。
在 WebArena 和 SWE-Bench Verified 上,ReasoningBank 优于直接存储原始轨迹或仅保留成功流程的方法。它在前者上将整体成功率提升 3.7–6.2 个百分点,在后者上将解决率提升 3.4–4.0 个百分点。
2.4 技能演化
单条记忆记录的是某个特定任务中发生了什么,而技能总结的是未来出现类似问题时应如何去做。技能可以由工具使用规则、行为要求、操作流程或脚本组成。技能演化会根据多个任务中的成功与失败,持续修订这些可复用的做法。
代表性工作:TRACE: A Self-Evolving Skill Bank for Consistent, Limit-Aware LLM Agents

TRACE 研究的是车载助手能否可靠地完成任务。在 CAR-bench 中,模拟用户提出的请求往往不完整或含糊不清。Agent 必须先通过多轮对话澄清用户意图,然后调用工具完成操作,同时遵守汽车领域的安全规则。许多模型偶尔能完成一项任务,但在反复运行中表现并不稳定。
TRACE 维护一个包含多个 Skill 的 Skill Bank。每个 Skill 对应某一类特定情境,并记录相关的工具使用规则和行为要求。每一轮评估结束后,系统会收集使用同一 Skill 的成功与失败轨迹,并对比它们的行为。Agent 失败的原因可能是没有询问必要信息、过早行动,或承诺了无法完成的事情。系统根据这些问题修订相应的 Skill,而成功的轨迹则提供了更好的情境处理方式。当某一类任务出错时,系统只需修改相关的 Skill,而不必重写整个 Prompt。
处理新任务时,Agent 会根据当前对话选择合适的 Skill。任务结束后,系统会根据本次运行的成功或失败继续更新这些 Skill。在 GPT-5.5 上,TRACE 将连续三次尝试全部成功完成的任务比例从 59.9% 提升至 94.5%。
2.5 Harness-Code Evolution
Harness 代码负责组织模型接收的上下文,并将模型的决策转化为工具调用和任务工作流。Skill 通常告诉 Agent 应当如何行动,而 Harness-code evolution 还能改变上下文的组装方式、增加或移除工具,或修改执行逻辑。
代表性工作:SkillSmith: Co-Evolving Skills and Tools for Self-Improving Agent Systems

许多技能演化方法都假设工具保持不变。如果任务失败是因为某个工具缺乏必要的能力,那么反复修改该工具的指令也无法解决问题。因此,SkillSmith 允许系统同时修改技能和工具。在检测到能力缺口后,其反思模块会生成一组协调一致的变更:在调整技能的同时,对相关工具进行编辑、组合、拆分或淘汰。
孤立地测试每个技能也可能遗漏多个技能一起使用时出现的协调问题和冲突。SkillSmith 根据执行轨迹,记录哪些技能经常相互帮助、哪些倾向于相互干扰。受生态系统中合作与竞争的启发,作者利用这些关系来决定优先调用、修改或淘汰哪些组件。
该系统还存储过去的失败模式,包括观察到的问题、其原因以及修复方式。如果新的修改提案重复了同样的错误,系统可以提前拒绝,避免重复同样的失败实验。
论文在三个基准上评估了五个不同规模的 Qwen3.5 模型。随着任务变得更加复杂、需要更多技能协同使用,SkillSmith 相对于基线的优势变得更加明显。由于 SkillSmith 直接改变工具及其调用方式,更新后的技能和工具必须一起测试,以避免修复了一个组件却破坏了另一个组件。
3. 演化拓扑:链、树与图
上一节讨论了 Agent 的哪些部分可以被修改。本节则关注新创建的版本如何继承先前的结果。每次更新之后,系统可以仅从一个版本继续,也可以保留多个分支,或者让新版本同时借鉴多个历史来源。这些组织方式的选择会影响探索的广度、评估成本,以及系统从有害更新中恢复的能力。根据新版本与历史版本之间的继承关系,RSI 拓扑可分为三类:
- 链式演化沿单一路径逐个更新版本;
- 树式演化允许历史版本产生多个分支,而每个新版本仍然只有一个直接父节点;
- 图式演化允许多个任务、版本或谱系的经验汇聚于一次更新之中。

3.1 链式
链式演化只维护一个活跃版本。系统修改当前版本 AtAt 得到 At+1At+1,然后以 At+1At+1 作为下一次更新的基础:A0→A1→A2→⋯A0→A1→A2→⋯。这种结构实现简单,不需要维护或在多个分支之间进行选择,但某一轮引入的错误会被下一轮直接继承。
代表性工作:SkillFlow: Benchmarking Lifelong Skill Discovery and Evolution for Autonomous Agents

SkillFlow 采用典型的链式更新流程。每个任务族都从一个空的 Skill 库开始。Agent 完成任务后,模型根据执行轨迹和验证反馈生成一个 Skill 补丁。该补丁可以新增、修改或删除 Skill 及辅助脚本。更新后的 Skill 库随即直接用于下一个任务,形成 S0→S1→S2→⋯S0→S1→S2→⋯。整个过程中只有一个当前版本,系统从不同时创建多个候选分支。
SkillFlow 用这一流程来考察 Agent 能否从任务经验中生成 Skill、在失败后修正 Skill,并在连续任务中维护单一的 Skill 库。它包含 20 个任务族、共 166 个可执行任务,覆盖金融、供应链、医疗、治理和数据处理领域。
同一任务族内的任务遵循相似的操作流程,但使用不同的输入和具体要求,难度逐步递增。Agent 可以复用从先前任务中学到的做法,但不能简单照搬它们的答案。
论文使用四种 Agent Harness 评估了 11 个模型。Claude Opus 4.6 的任务成功率从 62.65% 提升到 71.08%,不过部分配置持平甚至下降。作者发现,较强的配置会反复修订少量通用 Skill,而较弱的配置则倾向于不断添加相似的 Skill,使 Skill 库变得碎片化。一旦写入了错误的 Skill,后续任务可能会继续复用同一个错误。
3.2 Tree
树式进化会保留已经创建出的多个 Agent 版本。一个版本可以产生多个子版本,后续更新也可以从任意历史版本继续,从而使不同方向的改进形成彼此独立的分支。暂时表现不佳的版本可以留在树中,因为其中的某项改动日后可能成为进一步改进的基础。然而,随着分支数量增长,选择父版本和评估新版本需要更多时间与算力。
代表性工作:Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents

DGM 采用典型的树形拓扑。系统从一个初始编码 Agent 开始,并将此后生成的每个版本都保留在一个集合中。每一轮中,它选择一个版本作为父版本,并修改其 Prompt、工具或工作流代码以产生一个子版本。在整个实验过程中,底层模型保持固定。
被选中的 Agent 首先检查自身的 Benchmark 评估记录,提出下一步改进,然后在其自身代码中实现该改动。例如,它可能会添加一个更细粒度的代码编辑工具,修改其处理长上下文的方式,或引入重复尝试与同行评审。
新版本必须通过基础检查,以确保其代码能够运行,并保留编辑代码库的能力。随后,系统会在 SWE-bench 或 Polyglot 上评估其编程能力。通过检查的版本会留在集合中,即使其分数暂时低于父版本。它们的父版本及其他历史版本不会被覆盖,之后仍可能被再次选中。一个版本可以产生多个子版本,不同的子版本可能分别继续演化,逐步扩展版本树。得分更高的版本更有可能被选中,但其他版本仍保留演化机会。目前,父版本选择与集合管理的规则由系统预定义,不随 Agent 演化。
DGM 的名称源自 Gödel Machine,这是一种理论上的自修改系统,必须先证明某项改动会提升其效用,然后才能应用该改动。对于复杂的编程 Agent 而言,这种形式化证明很难实现,因此 DGM 改为运行修改后的版本,并用 Benchmark 分数检验其效果。
经过持续演化,DGM 的 SWE-bench 分数从 20.0% 升至 50.0%,Polyglot 分数则从 14.2% 升至 30.7%。在论文中,一次完整的 SWE-bench 自我演化实验大约需要两周,并且还会消耗大量 token。以这种方式持续生成并评估多个分支,需要相当可观的时间与模型调用预算。
3.3 Graph
在树式演化中,一个新版本源自一个父版本,用于修改它的证据通常也来自该父版本。图式演化则允许单次更新利用多个来源,例如同一 Agent 在不同任务中的轨迹,或该 Agent 在另一分支上的执行结果。版本之间的父子关系仍可按树存储,但用于更新的信息可以跨任务、跨分支流动。
代表性工作:Mendel Gödel Machine:通过比较进化实现递归自我改进的编程智能体

MGM 保留了 DGM 的版本树,但改变了用于生成新版本的信息。DGM 通常基于单个智能体在单一任务上的失败轨迹来修改代码。单次失败可能同时受到任务本身、工具使用、工作流以及其他多种因素的影响,因此很难确定真正需要改变的是什么。MGM 因而将该轨迹与版本集合中已积累的其他轨迹进行比较。
MGM 保留了基于单条失败轨迹的更新方法,将其称为克隆突变。它还引入了另外两种更新方法。
反应规范突变比较同一智能体在不同任务上产生的轨迹。当类似问题在多个任务中反复出现时,系统更有理由将问题归因于智能体本身,而非某个任务中的边缘情况。修改后的子代仍然源自该智能体,但变更的证据来自多个任务。
跨谱系杂交比较同一任务上来自不同分支的智能体。当一个智能体失败而另一个成功时,成功的轨迹可以指导对失败版本的修改。如果两个智能体都失败,系统仍可比较两条轨迹,以识别互补的失败模式。在更新过程中,系统将两个智能体的轨迹和结果作为证据提供。被修改的智能体从比较中提取可复用的做法,并将其加入自身代码。
这两种方法都使用版本集合中已存在的评估轨迹。跨任务和跨分支的比较为失败提供了更具体的线索,并缩小了修改过程中需要排查的问题范围。
在相同的评估预算下,MGM 在 SWE-bench Verified 和 Polyglot 上均优于仅使用单条轨迹修改 Agent 的树基线方法。以 Polyglot 为例,Agent 的得分从 50.8% 提升至 93.2%,而单轨迹树基线仅达到 77.9%。不同更新方法的 token 开销相近,且当编程 Benchmark 或底层模型发生变化时,MGM 演化出的 Harness 仍然有效。
4 谁来更新 Agent:自我更新、教师更新与联合更新
RSI 系统既要执行任务,又要根据任务轨迹和反馈更新自身。这两项工作可以由同一个 Agent 承担,也可以分配给不同的 Agent。本节将执行任务的 Agent 称为学生(Student),将分析学生任务轨迹并参与修改的另一个 Agent 称为教师(Teacher)。
根据由谁执行修改,RSI 系统可分为三类:
- 在自我更新中,学生总结经验并修改自身;
- 在教师更新中,学生执行任务,而独立的教师负责实际的更新;
- 在联合更新中,学生和教师各自承担修改过程的一部分。例如,一方诊断问题,另一方实施修改;或一方总结经验,另一方整理并写回。具体分工与顺序因方法而异。
4.1 自我更新
在自我更新中,同一个学生既执行任务,又进行修改。环境可能提供分数、错误或其他反馈,但没有单独的 Agent 分析轨迹或撰写更新。学生决定保留哪些经验,并修改未来任务中将使用的记忆、技能(Skills)、规则或代码。

这避免了 Agent 之间的通信,但 Student 必须自行解读反馈并实施修改。如果 Student 误解了出错的原因,该错误可能被写入持久化工件,并持续影响后续任务。
4.2 Teacher 更新
在 Teacher 更新中,执行任务的 Student 不直接修改后续将要使用的持久化工件。这一步由 Student 之外的 Teacher 来完成。Teacher 可以读取演示、任务轨迹、评估结果或先前经验,然后生成或组织新的记忆、Skills、工具或 Harness 代码。
Teacher 不必是一个专门的 Agent。它也可以是一个反思模块、一个优化器,或一个配备了验证规则的更新流程。取决于具体方法,Teacher 可以总结成功经验并分析失败原因,也可以对现有内容进行合并、筛选和淘汰。一个只提供分数或接受结果的模块不算 Teacher。要算作 Teacher,它必须实际决定写回什么内容以及如何修改。

代表性工作:Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses

在 Recuris 中,Agent 执行长时程任务,而一个固定的 Meta-Agent 汇总来自多个任务的失败记录,并修改 Agent 未来使用的 Skill Memory。用本节的术语来说,Agent 是 Student,Meta-Agent 是 Teacher。
在执行长时程任务时,Agent 既要跟踪当前进度,又要调用过去积累的经验。Recuris 使用工作记忆记录当前目标、已完成步骤和下一步计划,而经验记忆则存储可跨任务复用的经验与技能。当需要某项技能时,系统会根据工作记忆中记录的任务进度和未完成目标来选择相关技能,使技能选择与当前步骤保持一致。
当任务执行过程中出现问题后,Recuris 利用执行轨迹将失败与该轮所使用的记忆组件关联起来。当类似问题在多个任务中反复出现时,Meta-Agent 会分析这些记录,并对相关技能提出局部修改。候选修改只有在通过验证后才会写入技能记忆,Agent 在后续任务中使用更新后的技能。在整个过程中,执行任务的 Agent 产生轨迹并使用技能,而 Meta-Agent 则分析问题并实施修改。
Recuris 在四个长时程基准和十个模型上进行了评估。它在 37 个模型-基准组合中的 35 个上提升了性能,在最长任务上的提升最高达 32.2 分。
4.3 联合更新
在联合更新中,学生和教师都参与修改,尽管它们的角色并不固定。学生可以先从任务中总结候选经验,然后由教师进行筛选并写回;或者,教师可以诊断问题,学生来实施修改。双方都必须对最终写回的内容产生影响。只执行任务的学生,或只分配分数的教师,都不构成联合更新。

代表性工作:Evo-Harness: Context-to-Harness Skill Compilation for Self-Evolving Agents

在 Evo-Harness 中,Solver 对应学生,Evolver 对应教师。Solver 首先总结候选经验,随后 Evolver 对这些经验进行筛选、整理,并将其写入 Harness。Solver 的职责不止于执行任务:它还会从每次执行中总结候选经验。Evolver 随后审查这些经验,并决定如何修改现有的 Skill Harness。最终写回的内容由这两个角色共同产出。
Evo-Harness 在持续的任务流上运行。完成一个任务后,Agent 会从该次执行中总结经验,然后继续处理下一个任务。执行记录中既包含可复用的做法,也包含仅与当前任务相关的路径、文件名和特定条件。
当任务失败或收到负面反馈时,Solver 会从任务指令、执行轨迹、结果和反馈中总结候选经验,并识别这些经验的适用情境及其支撑证据。在每个任务批次结束时,Evolver 会将候选经验与当前 Harness 进行比对,并决定是添加、合并、修订还是丢弃它们。随后,它将保留下来的经验整理为面向某一类任务的跨任务规则或流程。更新后的 Skill Harness 将用于下一个任务批次。
论文在多个 Benchmark 上评估了 Evo-Harness。它在全部五个 Benchmark 上都优于其他经验复用方法。移除 Solver 生成候选经验的步骤后,性能相对于完整方法有所下降,这表明 Solver 的反思与 Evolver 的整理都对更新有正向贡献。
5. RSI 何时更新?离线、在线与混合模式
RSI 也可以按更新发生的时机来分类。即便两种方法都会修改记忆或技能,它们安排更新的方式也可能不同:有的在正式测试前就完成更新,有的在处理任务流的过程中持续更新,还有的会先积累起一批初始经验,再在部署期间继续累积。
根据任务执行与经验更新之间的时间关系,RSI 模式可分为三类:
- 离线 RSI 在训练任务上完成更新,并在测试期间保持固定;
- 在线 RSI 在处理任务的同时持续更新,因此较早任务的经验会影响后续任务;
- 混合模式先离线构建一个初始版本,然后在部署后继续适应新任务。

5.1 离线 RSI
离线 RSI 将更新与测试分离。系统首先在训练任务上积累经验,然后在测试阶段停止更新,并使用未见过的任务来评估这些经验能否被复用。训练任务与测试任务不能完全相同,否则 Agent 可能只是记住了答案。它们的分布也不能完全不同,否则评估就无法判断所学经验是否有用。
代表性工作:GDPevo: Evaluating Agent Self-Evolution on Real Business Tasks

GDPevo 是一个专为评估离线 RSI 而设计的基准。现有评估往往没有清楚说明训练任务与测试任务之间的关系。因此,当分数上升时,很难判断 Agent 是学会了复用经验,还是此前见过类似任务。GDPevo 从 CRM、ERP、金融、医疗、法律和数据处理等真实业务流程中选取任务,然后将每个流程分解为更小的规则。
GDPevo 提出规则杂交(Rule Hybridization)来构建任务。一组基本规则首先以不同组合出现在五个训练任务中,随后被重新组合成五个测试任务。Agent 在训练期间可以接收反馈并形成记忆或技能,但一旦测试开始便停止更新。尽管测试任务此前从未出现过,但它们包含训练期间遇到的规则,从而使该基准能够检验 Agent 能否将先前的经验应用于新的规则组合。
GDPevo 包含 12 个任务组,每组有五个训练任务和五个测试任务,共计 120 个任务。它还提供了一条自动化流水线,可在两天内再生成 12 个任务组。这使得定期刷新测试题成为可能,并降低了模型事先接触过这些题目的可能性。
作者用四种反馈类型评估了四个 Agent。表现最佳的配置从更新前的 50.63% 准确率提升到更新后的 67.07%,提高了 16.44 个百分点。当直接提供测试所需的全部规则时,准确率达到 91.6%,比当前最佳结果高出 24.53 个百分点。因此,现有 Agent 从训练任务中只学到了可用规则的一部分。
5.2 在线 RSI
在线 RSI 将任务排列成一个连续序列。完成当前任务后,Agent 会整理并保留来自执行结果和反馈的经验。当下一任务开始时,这些经验已经可用。任务执行与经验更新交替进行,没有单独的培训阶段。必须沿着任务序列观察表现,以确定积累的经验是否有助于后续任务。
代表性工作:FinEvo-Bench: A Longitudinal Benchmark for Self-Evolving Agents in Professional Financial Workflows

FinEvo-Bench 是一个面向在线 RSI 的基准,它将 120 个金融任务组织成一条连续流。Agent 在完成每个任务后保留经验,并将其用于后续任务。该基准涵盖 6 个领域和 20 个业务场景。每个场景包含 6 个任务,这些任务遵循相同的流程,但使用不同的数据并提出不同的具体问题。
同一场景的 6 个任务不会连续出现,而是与其他场景的任务交错排列。论文还将任务顺序随机化了 3 次,以确保结果不依赖于某一种特定排序。在中间处理过其他任务之后,Agent 仍必须检索先前学到的流程,并将其应用于同类型的新任务。
每个任务完成后,Agent 会收到基于评分标准的反馈,并将有用的反思写入记忆、Skills 或操作手册。当前会话随后关闭,但这些经验会保留下来,并直接用于下一个任务。评估期间没有单独的训练阶段:Agent 在完成任务的同时更新自身。
为隔离保留经验的效果,论文为每个实验都设置了状态重置对照组。两组使用相同的模型、Agent 框架、任务顺序和评分流程。实验组保留先前经验,而对照组在每个任务前清空其状态。二者得分之差衡量了保留经验带来的增益。
论文评估了 4 个基于 Qwen3.7-Max 构建的 Agent。保留经验使平均得分提高了 9.33 至 19.37 分。在同一场景内,后 3 个任务的增益比前 3 个任务高出 6.10 至 8.70 分,这表明随着相关任务数量的增加,早期经验变得更有用。
5.3 混合模式
混合模式先从演示或训练任务中积累一批初始经验,再在真实使用过程中持续更新。这样,Agent 在开始执行任务时就已经拥有可用的经验,同时还能在后续纳入新的情况。

Mem2Evolve 先利用部分任务集积累初始经验,并构建一组可复用的工具和专家 Agent,然后处理剩余任务。在后续任务中,Agent 使用这些已有资源,同时继续添加新的经验和组件。将离线初始化与任务流中的持续更新相结合,使其成为一种混合方法。
系统将这些资源存储于两类 Memory 中:Experience Memory 保存从成功和失败任务中总结出的经验教训,而 Asset Memory 保存可直接调用的工具和专家 Agent。
当新任务到来时,系统首先将其分解为子任务,并在 Asset Memory 中搜索合适的组件。若有可用组件,则直接复用。若没有可用组件,系统会检索相关经验,并结合外部信息来创建新的工具或专家 Agent。新工具必须首先通过自动生成的单元测试。任务完成后,新的经验和经过验证的组件会被写入这两个 Memory,以供将来使用。
论文在六个任务类别和八个 Benchmark 上评估了该系统。完整系统平均比仅积累经验的方法高出 11.80%,比仅创建工具或专家 Agent 的方法高出 6.46%。与两个 Memory 均为空的设置相比,经过初始化的系统在每一个 Benchmark 上都表现更好。
6. 其他分类维度
前几节按 RSI 的产物、版本结构、更新器和更新时机对其进行了组织。在阅读单篇论文时,还有五个额外维度可用于比较:接受标准、反馈来源、反馈类型、更新频率和经验范围。这些维度必须分别评估,而一种方法在同一维度内可能使用多个类别。
6.1 接受标准
在产生一个修改之后,系统仍然需要证据来决定是否保留它。常见的接受标准包括:
- 产物验证: 单元测试、编译、接口检查,或对修改后产物的其他直接验证。
- 实例结果: 当前任务实例是否成功,或是否获得更高的 Reward。
- 基准分数: 在一组评估问题上的整体表现。
- 组合指标: 性能、成本、速度、稳定性、新颖性或其他目标的组合。
- 无独立验证: 修改在生成后立即写回,没有单独的接受步骤。
6.2 反馈来源
反馈来源描述驱动改进的证据来自何处。它记录的是演化过程中实际使用的证据,而不仅仅是最终评估所用的测试方法。
- 基准: 直接取自所评估 Benchmark 的答案、Verifier 或分数。
- 训练/开发集: 与最终测试集分开保留的演化任务或数据划分。
- 环境: 状态变化、Observation、原生 Reward 或执行结果。
- 可执行验证器: 单元测试、编译器、容器或形式化检查器。
- LLM 反馈: 由 Student、Teacher 或另一个模型产生的评审、自我批评、自洽性或辩论。
- 人类: 人类标签、偏好、评审或干预。
6.3 反馈类型
反馈类型将结果得分与包含具体信息的非得分反馈区分开来。
- 得分: 评估任务结果的数值或类别。二元反馈仅区分成功与失败或通过与否。非二元反馈提供奖励、准确率、效用或其他具有两个以上可能取值的得分。
- 非得分: 结果得分之外的具体信息。真实标注包括参考答案、目标状态、期望输出或参考实现。LLM 评审包括由语言模型生成的文本判断、解释或批评。其他信息包括由 Agent 产生的观察、日志、诊断、因果归因、约束或批评。
由 LLM 生成的标量仍算作得分。只有文本判断、解释或批评才算作 LLM 评审。仅用于进化 Teacher 的反馈在此不计入。
6.4 更新频率
更新频率表示在持久化产物更新之前累积了多少 Student 执行量:
- 步骤: 在一条轨迹内的一对动作–观察之后。
- 事件触发: 在失败、发现能力缺口、收到提示或完成子目标时。
- 轨迹: 在一条完整任务轨迹之后。
- 批次: 在累积多条轨迹或候选集之后,或完成一轮离线数据收集之后。
6.5 经验范围
经验范围描述进化后的产物可以在何处使用:
- 通用: 该产物可跨任务类型或领域复用。
- 专用: 该产物仅限于特定实例、任务类型、主题或领域。
如果系统同时维护全局产物和任务特定产物,则可同时归类为通用和专用。
参考文献
Prism-Shadow:Awesome RSI
Zweiger 等:Self-Adapting Language Models (2025-06-12)
Karten 等:Prime Agent: A Self-Improving RLM Harness (2026-08-24)
Ouyang 等:ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory (2025-09-29)
Wu 等:TRACE: A Self-Evolving Skill Bank for Consistent, Limit-Aware LLM Agents (2026-08-24)
Wei 等:SkillSmith: Co-Evolving Skills and Tools for Self-Improving Agent Systems (2026-05-31)
Zhang 等:SkillFlow: Benchmarking Lifelong Skill Discovery and Evolution for Autonomous Agents (2026-04-19)
Zhang 等:Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents (2025-05-29)
Liu 等:Mendel Gödel Machine: Recursive Self-Improving Coding Agents via Comparative Evolution (2026-08-07)
Yu 等:Recursive Experiential-Working Memory Evolution for Long-Horizon Agent Harnesses (2026-08-25)
Wei 等:Evo-Harness: Context-to-Harness Skill Compilation for Self-Evolving Agents (2026-08-15)
Zhou 等:GDPevo: Evaluating Agent Self-Evolution on Real Business Tasks (2026-08-04)
Deng 等:FinEvo-Bench: A Longitudinal Benchmark for Self-Evolving Agents in Professional Financial Workflows (2026-08-06)
Cheng 等:Mem2Evolve: Towards Self-Evolving Agents via Co-Evolutionary Capability Expansion and Experience Distillation (2026-04-13)