企业官网建设流程全解析

摘要：RSI（Recursive Self-Improvement，递归自我改进）是当下 AI 领域热度最高的概念之一，与自进化（Self-Evolving）、Self-Improving 等表述相近。本文从分类视角系统梳理现有 RSI 工作：回答了 RSI 到底是什么（进化对象、进化结构、更新者、更新时机），并给出验收标准、反馈来源等五个辅助比较维度，帮你建立一套分析 RSI 的坐标系。全文约万字，建议收藏阅读。

前言

RSI（Recursive Self-Improvement）这个概念最近热度很高。与之相近的表述还有自进化、Self-Evolving、Self-Improving 等等概念。

目前，这个领域仍在飞速发展，尚未形成统一的技术范式。不同工作选择的改进对象和实现路径差异很大：有的更新模型参数，有的积累上下文或记忆，有的演化 Skill，还有的直接修改工具、控制流程和 Harness 代码。因此，RSI 很难用某一种具体方法或单一技术路线来概括。

本文参考了 Awesome RSI 仓库（网站），尝试从分类的视角整理现有 RSI 工作。我们将从多个维度出发，分析不同自进化工作之间的联系和区别。

读完本文后，你可以进一步理解 RSI 这个概念，也能建立一套分析 RSI 的坐标系：再遇到新的自进化工作时，可以迅速判断它与已有工作的联系和区别。

全文速览：

1. RSI 到底是什么

本文把 RSI 定义为：Agent 在与环境交互后，利用任务轨迹与反馈，通过更新机制修改自身状态，并让更新后的状态参与后续任务，以提升未来表现。

Aₜ₊₁ = U(Aₜ, τₜ, fₜ)

其中：

• Aₜ 表示第 t 轮使用的 Agent；
• τₜ 是它在任务中产生的轨迹；
• fₜ 是获得的反馈；
• U 是更新机制。

Aₜ 包含Model 与 Harness；更新可以发生在模型参数上，也可以发生在 Harness 的上下文、记忆、Skill、工具或代码上。

更新后的 Aₜ₊₁ 将参与后续任务。U 不一定由 Agent 自己执行，也可以由 Teacher、Meta-Agent 或外部训练程序完成。

2. RSI 在进化什么：参数、上下文、记忆、Skill 与 Harness 代码

现代智能体可以抽象为Agent = Model + Harness。Model 提供基础的理解、推理与生成能力；Harness 则组织模型如何接收信息、积累经验、调用工具并完成任务，具体包括上下文、记忆、Skill、工具和 Harness 代码。

不同的 RSI 方法可能修改其中不同的部分：

• 参数进化修改 Model；
• 上下文、记忆和 Skill 进化修改 Harness 中可持续积累的状态；
• 工具与 Harness 代码进化则改变 Agent 的动作空间和控制流程。

2.1 参数进化 —— SEAL

参数进化把经验写回模型权重。它的优势是知识可以直接内化进模型，不必每次检索外部材料；代价是更新昂贵、难以定位和撤销，而且一次错误训练可能影响大量无关任务。

代表工作：Self-Adapting Language Models

SEAL 的出发点是：语言模型部署后会不断遇到新知识和新任务，但权重通常保持静止。作者希望模型不依赖单独的适配网络，而是自己决定"应该怎样训练自己"。

为此，模型面对新输入时不只生成答案，还生成 self-edit。self-edit 是一份自我更新方案，可以重组原始信息、生成训练样本、指定优化超参数，或者调用工具做数据增强和梯度更新。

系统随后按照 self-edit 的设置执行监督微调。经过 SFT 后，经验从一段临时文本变成持久权重变化。问题是，模型最初并不知道什么样的 self-edit 真正有效，于是 SEAL 又在外面加了一层强化学习：执行某个 self-edit 后，重新测量更新模型的下游表现，并把这个结果作为奖励，训练模型以后生成更有用的 self-edit。

作者在知识吸收和少样本学习任务上测试了 SEAL。模型生成的 self-edit 不仅包含训练数据，还可以指定数据的组织方式和训练配置。系统按照 self-edit 实际更新模型，再根据更新后模型的下游得分筛选更有效的方案。因此，候选 self-edit 的微调和评测仍会带来较高的计算开销。

2.2 上下文进化 —— Prime Agent

上下文可以理解为模型在当前这次推理中直接看到的材料，包括任务要求、历史对话、当前计划、Prompt、规则，以及经过整理的外部信息。上下文进化，就是根据任务执行结果重新组织这些材料，让模型下一次推理时看到更有用的内容。例如，系统可以删除无关信息、压缩过长的历史、补充失败教训，或者重写当前计划。

上下文与记忆的区别在于：记忆是存放在外部、等待检索的信息；记忆被取出并放入模型输入后，才成为当前上下文。

代表工作：Prime Agent: A Self-Improving RLM Harness

长程任务的困难不只在于问题本身复杂，还在于任务持续时间可能远远超过一次模型调用。以大型软件开发为例，Agent 可能需要连续工作数小时，其间反复阅读代码、运行测试、记录结果并修改方案。但模型每次能够直接读取的上下文有限：保留全部历史很快就会超出窗口，丢掉历史又会让模型忘记任务进展。

Prime Agent 的做法是在模型之外提供一个可以长期保留的工作台。它使用持久化的 IPython REPL 保存代码、变量、文件和计算结果，模型可以通过程序处理长文本、调用外部资源或执行测试时计算。Continual Harness 则记录任务历史、记忆、Skill、Prompt 和子 Agent 配置。即使任务暂时中断，后台进程仍会保留这个工作现场；任务恢复时，Agent 可以从上次停止的位置继续，而不必重新阅读全部材料。

对于可以拆分的任务，Prime Agent 还允许主 Agent 创建多个子 Agent。子 Agent 分别处理不同问题，并将结果直接返回给主 Agent，从而支持并行探索和结果汇总。

Prime Agent 不更新模型参数。它把任务历史和中间结果保存在外部，模型再次运行时，Harness 再取出当前需要的内容组成上下文。

2.3 记忆进化 —— ReasoningBank

记忆进化把经验写入独立的长期存储，并在后续任务中按需检索。系统需要从日志中筛选有价值的信息，将具体经历整理成可复用的经验，并根据新证据修订旧记忆；否则，失败经验和错误归因会持续影响后续任务。

代表工作：ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory

ReasoningBank 面向持续任务：Agent 在执行任务时可能产生可复用的经验，但传统系统通常在任务结束后丢弃这些信息，下一次又重复相同错误。直接保存整条轨迹也不理想，因为原始轨迹很长，还包含大量琐碎细节。因此，ReasoningBank 将成功和失败轨迹整理成简短、可复用的经验。

新任务到来时，Agent 从记忆库检索相关策略，用它们指导本轮交互；任务结束后，Agent 先判断任务是否完成，再从轨迹中提炼新的经验并写回记忆库。成功轨迹提供有效的做法，失败轨迹则记录应当避免的决策。

作者还提出 memory-aware test-time scaling（MaTTS）：让 Agent 针对同一任务进行更多次尝试，获得更丰富的成功和失败样本，再从中提炼出质量更高的记忆。这些记忆又会用于指导后续尝试。

在 WebArena 和 SWE-Bench Verified 任务上，ReasoningBank 均优于直接保存原始轨迹或只保存成功流程的方法，前者的总体成功率提高了 3.7—6.2 个百分点，后者的解决率提高了 3.4-4.0 个百分点。

2.4 Skill 进化 —— TRACE

单条记忆记录某次任务中发生了什么，Skill 则总结以后遇到同类问题时应该怎样处理。它可以是一组工具使用规则、行为要求、操作步骤，也可以是一段脚本。Skill 进化就是根据多次任务的成功和失败，持续修改这些可以重复使用的做法。

代表工作：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 代码进化 —— SkillSmith

Harness 代码负责组织模型接收到的上下文，并把模型的决策转化为工具调用和任务流程。Skill 通常告诉 Agent 应该怎样做，而 Harness 代码进化还可以改变上下文的构造方式、增删工具或修改执行逻辑。

代表工作：SkillSmith: Co-Evolving Skills and Tools for Self-Improving Agent Systems

许多 Skill 进化方法默认工具保持不变。如果任务失败是因为工具能力不足，那么反复修改工具的说明文字也无法解决问题。因此，SkillSmith 允许系统同时修改 Skill 和工具。发现能力缺口后，反思模块会生成一组配套修改：一边调整 Skill，一边编辑、组合、拆分或停用相关工具。

单独测试每个 Skill，还可能忽略多个 Skill 一起使用时的配合和冲突。SkillSmith 会根据执行轨迹记录哪些 Skill 经常互相帮助，哪些 Skill 容易产生干扰。作者借用了生态系统中合作与竞争的思路，用这些关系决定以后优先调用、修改或淘汰哪些组件。

系统还会保存过去的失败模式，包括问题表现、失败原因和修复方法。如果新的修改方案又犯了相同错误，系统可以提前将其排除，避免重复试错。

论文在三个 Benchmark 上，使用五个不同规模的 Qwen3.5 模型进行评测。任务越复杂、需要同时使用的 Skill 越多，SkillSmith 相对基线的优势越明显。SkillSmith 会直接改动工具及其调用方式，因此要把更新后的 Skill 和工具放在一起测试，避免修好一个组件却破坏另一个。

3. RSI 的进化结构：链、树与图

前面讨论了 Agent 的哪些部分会被修改，这一章关注修改产生的新版本如何继承历史结果。每次更新后，系统可以只沿一个版本继续向前，也可以保留多个分支，或者让一个新版本同时利用多个历史来源。

不同的组织方式会影响探索范围、评测成本，以及系统从错误更新中恢复的能力。按照新版本与历史版本之间的继承关系，可以将进化结构分为三类：

• 链式进化沿一条路径依次更新；
• 树形进化允许历史版本产生多个分支，但每个新版本仍然只有一个直接父代；
• 图式进化则允许多个任务、版本或谱系的经验在一次更新中汇合。
  

3.1 链 —— SkillFlow

链式进化始终只有一个正在使用的版本。系统在当前版本 Aₜ 上修改，得到 Aₜ₊₁，下一轮再以 Aₜ₊₁ 为基础继续更新：

A₀ → A₁ → A₂ → …

这种方式实现简单，不需要维护和选择多个分支；但前一轮留下的错误也会被下一轮直接继承。

代表工作：SkillFlow: Benchmarking Lifelong Skill Discovery and Evolution for Autonomous Agents

SkillFlow 采用典型的链式更新。每个任务族从一个空的 Skill 库开始。Agent 完成任务后，模型根据执行轨迹和验证反馈生成 Skill patch，用来新增、改写或删除 Skill 和辅助脚本。更新后的 Skill 库直接用于下一项任务，依次形成：

S₀ → S₁ → S₂ → …

整个过程中始终只有一个当前版本，不会同时产生多个候选分支。

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 树 —— Darwin Gödel Machine

树形进化会保留已经产生的多个 Agent 版本。一个版本可以生成多个子版本，后续更新也可以从任意历史版本继续，因此不同的改进方向会逐渐形成分支。暂时表现不好的版本也可以保留下来，其中的某项修改可能成为后续改进的基础。随着分支增多，选择父代和评测新版本所需的时间和计算资源也会增加。

代表工作：Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents

DGM 采用典型的树形进化。系统从一个初始编程 Agent 开始，将此后生成的版本保存在一个集合中。每轮更新时，系统从中选择一个版本作为父代，修改它的提示词、工具或工作流程代码，生成一个子版本。实验中的底层模型保持不变。

被选中的 Agent 会先查看自己的 Benchmark 评测记录，从中提出下一项改进，再把这项改进实现到自己的代码中。例如，它可以增加更细粒度的代码编辑工具，调整长上下文的处理方式，或者加入多次尝试和 peer review 流程。

生成的新版本需要通过基本检查，确保代码能够运行，并且仍然具备编辑代码库的能力；随后，系统使用 SWE-bench 或 Polyglot 评测其编程能力。通过检查的版本会被保留下来，即使它的得分暂时低于父代。父代和其他历史版本也不会被覆盖，之后仍然可以再次被选中。

同一个版本可以产生多个子版本，不同子版本又可以分别继续更新，版本树由此逐步展开。得分较高的版本更容易被选中，但其他版本也有机会继续演化。目前，选择父代和管理版本集合的规则由系统预先设定，不会随 Agent 一起更新。

DGM 的名字来自 Gödel Machine。Gödel Machine 是一种理论上的自修改系统：系统需要先证明某次修改能够提高收益，然后才执行修改。复杂的编程 Agent 很难完成这种形式证明，因此 DGM 直接运行修改后的版本，用 Benchmark 得分检验修改是否有效。

经过持续更新，DGM 的 SWE-bench 得分从 20.0% 提高到 50.0%，Polyglot 得分从 14.2% 提高到 30.7%。论文中，一次完整的 SWE-bench 自进化实验约需两周，Token 消耗也较高。这说明，像 DGM 这样需要持续生成并评测多个分支的树形搜索，通常需要投入更多时间和模型调用预算。

3.3 图 —— Mendel Gödel Machine

树形进化中的新版本沿一个父代产生，修改依据通常也来自这个父代。图式进化允许一次修改同时参考多个来源，例如同一 Agent 在不同任务上的轨迹，或者另一条分支中 Agent 的执行结果。版本之间的父子关系仍然可以用树保存，但用于更新的信息已经能够跨任务和跨分支流动。

代表工作：Mendel Gödel Machine: Recursive Self-Improving Coding Agents via Comparative Evolution

MGM 延续了 DGM 的版本树，但改变了生成新版本时使用信息的方式。DGM 一般根据某个 Agent 在一项任务中的失败轨迹修改代码。单次失败可能同时受到任务内容、工具使用和工作流程等因素影响，只看这一条轨迹，很难确定真正需要修改的部分。因此，MGM 利用版本集合中已经积累的其他轨迹进行比较。

MGM 保留了根据单条失败轨迹进行修改的方式，称为clonal mutation。除此之外，它增加了两种更新方式。

Reaction-norm mutation会比较同一个 Agent 在不同任务中的执行轨迹。如果多项任务反复出现相似问题，系统便可以据此判断问题更可能来自 Agent 自身，而非某一道题的特殊情况。修改后的子版本仍然来自这个 Agent，但修改依据来自多项任务。

Cross-lineage hybridization会比较不同分支的 Agent 在同一任务上的表现。当一个 Agent 失败而另一个 Agent 成功时，成功轨迹可以为失败版本的修改提供参考。如果两个 Agent 都失败，系统也会比较两条轨迹，从中识别互补的失败模式。

进行修改时，系统会把两个 Agent 的执行轨迹及结果作为参考，由待修改的 Agent 从对照中提取可复用的做法，再将其加入到自己的代码中。

这两种更新使用版本集合中已有的评测轨迹。跨任务和跨分支的对照可以提供更具体的故障线索，缩小修改时需要排查的范围。

在相同的评测预算下，MGM 在 SWE-bench Verified 和 Polyglot 上都超过了只使用单条轨迹修改的树式基线。以 Polyglot 为例，Agent 的得分从 50.8% 提高到 93.2%，单轨迹（树形）基线达到 77.9%。不同更新方式的 Token 消耗相近，MGM 演化出的 Harness 在更换编程 Benchmark 或底层模型后也能继续发挥作用。

4. 谁来更新 Agent：自身、教师与联合更新

RSI 系统既要执行任务，也要根据任务轨迹和反馈完成更新。这两项工作可以由同一个 Agent 承担，也可以交给不同的 Agent。为了方便讨论，本章把执行任务的 Agent 称为Student，把分析 Student 的任务轨迹并参与修改的另一个 Agent 称为Teacher。

按照由谁负责完成修改，可以将 RSI 系统分为三类：

• 自身更新：Student 自己总结经验并修改自身；
• 教师更新：Student 负责执行任务，具体的更新则由独立的 Teacher 完成；
• 联合更新：由 Student 和 Teacher 分别承担修改过程中的一部分，例如一方诊断问题、另一方实现修改，或者一方总结经验、另一方整理并写入。具体分工和先后顺序因方法而异。

4.1 自身更新

自身更新中，执行任务和完成修改的是同一个 Student。环境可以提供得分、错误信息或其他反馈，但没有另一个 Agent 负责分析轨迹或编写更新。Student 根据反馈决定保留哪些经验，并修改后续任务会继续使用的记忆、Skill、规则或代码。

它省去了 Agent 之间的信息传递，但 Student 必须自己理解反馈并完成修改。如果 Student 错误理解出错，错误也可能被写入长期产物，并继续影响后面的任务。

4.2 教师更新 —— Recuris

教师更新中，执行任务的 Student 不直接修改后续会使用的持久产物，这一步由 Student 之外的 Teacher 完成。Teacher 可以读取示范、任务轨迹、评测结果或已有经验，并据此生成或整理新的记忆、Skill、工具或 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 用 Working Memory 记录当前目标、已经完成的步骤和下一步计划，用 Experiential Memory 保存可以跨任务复用的经验与 Skill。需要调用 Skill 时，系统根据 Working Memory 中记录的任务进度和未完成目标选择相关 Skill，使 Skill 的选择与当前步骤保持一致。

任务出现问题后，Recuris 根据执行轨迹，将失败与本轮使用的记忆组件关联起来。类似问题在多个任务中反复出现时，Meta-Agent 会分析这些记录，并对相关 Skill 提出局部修改。候选修改通过验证后才会写入 Skill Memory，Agent 在后续任务中使用更新后的 Skill。整个过程中，执行 Agent 产生轨迹并使用 Skill，Meta-Agent 分析问题并完成修改。

Recuris 在四个长程 Benchmark 和十种模型上进行了测试。在 37 个模型与 Benchmark 组合中，35 个取得提升，最长任务的得分最多提高了 32.2 个点。

4.3 联合更新 —— Evo-Harness

联合更新中，Student 和 Teacher 都会参与修改，但两者的分工没有固定形式。Student 可以先从任务中总结候选经验，再由 Teacher 筛选和写入；也可以由 Teacher 诊断问题，再由 Student 实现修改。判断联合更新的依据，是两者是否都影响了最终写回的内容。Student 只负责执行任务，或者 Teacher 只负责评分，都不属于联合更新。

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

在 Evo-Harness 中，Solver 相当于 Student，Evolver 相当于 Teacher。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 还可以按照更新发生的时间分类。即使修改的都是记忆或 Skill，不同方法安排更新的方式也不一样：有的在正式测试前先更新完全，有的在任务流中边执行边更新，还有的先建立一批初始经验，再在实际应用中继续积累。

按照任务执行与经验更新的时间关系，可以将 RSI 分为三种模式：

• 离线 RSI在训练任务中完成更新，进入测试阶段后保持不变；
• 在线 RSI在处理任务的同时持续更新，前面任务产生的经验会影响后续任务；
• 混合模式先在离线阶段建立初始版本，上线后再根据新任务继续调整。
  

5.1 离线 RSI —— GDPevo

离线 RSI 将更新和测试分成两个阶段。系统先在训练任务中积累经验，进入测试阶段后停止更新，再用没有见过的任务检查这些经验能否复用。训练题和测试题不能完全重复，否则 Agent 可能只是记住了答案；两者分布也不能完全不同，否则无法判断学到的经验是否有用。

代表工作：GDPevo: Evaluating Agent Self-Evolution on Real Business Tasks

GDPevo 是一套专门评测离线 RSI 的 Benchmark。现有评测通常没有清楚说明训练题与测试题之间有什么联系，因此分数提高后，很难判断 Agent 是学会了复用经验，还是曾经见过相似题目。GDPevo 从 CRM、ERP、金融、医疗、法律和数据处理等真实业务中选取任务，再把每个业务流程拆成更小的规则。

GDPevo 提出了 Rule Hybridization 方法来构造任务。同一批基础规则先以不同组合出现在五个训练任务中，再经过重新组合，形成五个测试任务。Agent 可以在训练阶段接受反馈，并形成记忆或 Skill；进入测试阶段后不再更新。测试任务虽然没有直接出现过，但其中包含训练阶段接触过的规则，因此可以检查 Agent 能否将已有经验用到新的规则组合上。

GDPevo 包含 12 组任务，每组由五个训练任务和五个测试任务组成，共 120 个任务。它还提供了自动生成流程，可以在两天内生成另外 12 组任务。这样可以定期更换测试题，降低题目被模型提前见过的可能性。

作者使用四种 Agent 和四类反馈进行了实验。表现最好的配置在更新前准确率为 50.63%，更新后达到 67.07%，提高了 16.44 个百分点。如果直接提供测试所需的全部规则，准确率可以达到 91.6%，比当前最佳结果高出 24.53 个百分点。这个差距说明，现有 Agent 还只能从训练任务中学到部分规则。

5.2 在线 RSI —— FinEvo-Bench

在线 RSI 把任务排成连续序列。Agent 完成当前任务后，会从执行结果和反馈中整理经验并保留下来；下一项任务开始时，这些经验已经可以使用。任务执行与经验更新交替进行，没有单独划分训练阶段。评测时需要沿任务序列观察表现，才能看出经验是否在后续任务中发挥作用。

代表工作：FinEvo-Bench: A Longitudinal Benchmark for Self-Evolving Agents in Professional Financial Workflows

FinEvo-Bench 是一个面向在线 RSI 的 Benchmark，它将 120 个金融任务组织成一条连续任务流。Agent 完成当前任务后保留经验，并在后续任务中继续使用。Benchmark 覆盖六个领域和 20 个业务场景；每个场景包含六个任务，这些任务采用同一流程，但数据和具体问题不同。

同一场景的六个任务不会连续出现，而是与其他场景的任务交错排列。论文还将任务顺序随机打乱了三次，避免结果只对某一种排列成立。Agent 必须在处理其他任务后，仍能找回此前学到的流程，并用它解决同类的新任务。

每完成一个任务，Agent 都会收到基于评分标准的反馈，并把反思后的有用内容写入记忆、Skill 或操作手册。当前会话随后关闭，但这些经验会保留下来，并在下一项任务中直接使用。整个评测过程没有独立的训练阶段，Agent 一边完成任务，一边更新自己。

为了单独测出这些经验带来的变化，论文为每次实验设置了一个状态重置的对照组。两组使用相同的模型、Agent 框架、任务顺序和评分方式；实验组保留过去的经验，对照组则在每项任务前清空状态。两组分数之差，就是保留经验带来的提升。

论文使用四种以 Qwen3.7-Max 为底层模型的 Agent 进行实验。保留经验后，平均得分提高了 9.33 至 19.37 分；同一场景中，后三个任务获得的提升比前三个任务高 6.10 至 8.70 分，表明随着相关任务增加，先前积累的经验产生了更明显的作用。

5.3 混合模式 —— Mem²Evolve

混合模式先从示范或训练任务中建立一批初始经验，再在实际使用过程中继续更新。这样，Agent 开始执行任务时已经有可用的经验，遇到新情况后也能继续补充。

代表工作：Mem²Evolve: Towards Self-Evolving Agents via Co-Evolutionary Capability Expansion and Experience Distillation

Mem²Evolve 先用一部分任务积累初始经验，并建立一批可复用的工具和专家 Agent，再处理其余任务。在后续任务中，Agent 一边调用这些已有内容，一边继续补充新的经验和组件。因此，它既有离线初始化，也会在任务过程中持续更新，属于混合模式。

系统使用两类 Memory 保存这些内容：Experience Memory 保存从成功和失败任务中总结出的经验，Asset Memory 保存可以直接调用的工具和专家 Agent。

新任务到来后，系统先将任务拆成多个子任务，再从 Asset Memory 中寻找合适的组件。找到后直接复用；找不到时，系统会检索相关经验，并结合外部信息创建新的工具或专家 Agent。新工具需要先通过自动生成的单元测试，任务结束后，新经验和通过验证的组件会分别写入两类 Memory，供后续任务使用。

论文在六类任务和八个 Benchmark 上进行了测试。完整系统的平均表现比只积累经验的方法高 11.80%，比只创建工具或专家 Agent 的方法高 6.46%。与两类 Memory 均为空的设置相比，经过初始化的系统在所有 Benchmark 上表现都更好。

6. RSI 的其他分类维度

前面几章按照进化对象、版本结构、更新者和更新时机梳理了 RSI。阅读具体论文时，还可以从验收标准、反馈来源、反馈类型、更新频率和经验作用范围五个角度进行比较。这些维度需要分别判断，同一种方法也可能在同一维度中采用多种方式。

6.1 验收标准

系统生成修改后，还要依据一定的证据决定是否保留。常见的验收标准包括：

• 产物验证：通过单元测试、编译、接口检查或其他针对修改对象的直接验证；
• 单题结果：依据当前任务实例是否成功，或是否获得更高 Reward；
• Benchmark 得分：依据一组评测问题上的总体表现；
• 组合指标：同时考虑表现、成本、速度、稳定性、新颖性或其他目标；
• 无独立验证：生成后直接写入，不设置单独的验收环节。

6.2 反馈来源

反馈来源描述驱动改进的证据来自哪里。这里记录的是演化过程中实际使用的证据，不只看最终采用了什么测试方式。

• Benchmark：直接使用待测 Benchmark 的答案、Verifier 或分数；
• 训练／验证集：使用与最终测试分离的进化任务或数据划分；
• 环境：使用状态变化、Observation、原生 Reward 或执行结果；
• 可执行验证器：使用单元测试、编译器、容器或形式检查器；
• LLM 反馈：由 Student、Teacher 或其他模型通过评审、自我批评、自洽性或辩论产生反馈；
• 人工：使用人工标签、偏好、审核或干预。

6.3 反馈类型

反馈类型关注系统获得的是结果分数，还是包含具体信息的非分数反馈。

• 分数：用数值或类别评价任务结果。其中，二值反馈只区分成功、失败、通过或未通过；非二值反馈则提供多于两个取值的 Reward、准确率、效用或其他分数；
• 非分数：提供结果分数之外的具体信息。其中，标准答案包括参考答案、目标状态、预期输出或参考实现；LLM 评审包括语言模型给出的文字判断、解释或批评；其他信息包括 Observation、日志、诊断、责任定位、约束信息或 Agent 生成的批评。

LLM 给出的标量仍属于分数；只有文字判断、解释或批评才归入 LLM 评审。只用于演化 Teacher 的反馈不计入这里。

6.4 更新频率

更新频率表示积累多少 Student 执行过程后，会更新一次持久产物：

• 单步：在轨迹中的一次动作—Observation 之后更新；
• 事件触发：在失败、发现能力缺口、收到提示或完成子目标时更新；
• 完整轨迹：一条完整任务轨迹结束后更新；
• 批次：积累多条轨迹、多组候选，或完成一轮离线数据收集后统一更新。

这里不记录 Teacher 自身的演化周期；按代更新和对 Student 经验的离线集中整理统一归入批次。

6.5 经验作用范围

经验作用范围描述演化得到的产物可以在哪里使用：

• 通用：产物可以跨任务类型或跨领域复用；
• 专用：产物只用于特定实例、任务类型、主题或领域。

如果一个系统同时维护全局产物和任务专用产物，可以同时归入通用和专用。

总结

本文从四个核心维度建立了一套分析 RSI 的坐标系：

1. 进化什么：参数（SEAL）、上下文（Prime Agent）、记忆（ReasoningBank）、Skill（TRACE）、Harness 代码（SkillSmith），五类对象覆盖了 Agent = Model + Harness 的各个组成部分；
2. 怎么继承：链（SkillFlow）、树（DGM）、图（MGM），决定了探索范围、评测成本与错误恢复能力；
3. 谁来更新：自身更新、教师更新（Recuris）、联合更新（Evo-Harness），Student 与 Teacher 的分工方式各有利弊；
4. 何时更新：离线（GDPevo）、在线（FinEvo-Bench）、混合（Mem²Evolve），对应不同的应用形态。

再遇到新的自进化工作时，用这套坐标系快速定位它与已有工作的联系和区别，就能看清它到底在"进化"什么、进化到哪一步。

参考资料

• 原文（含完整版）：Awesome RSI - Understanding RSI
• 论文合集仓库：GitHub - Prism-Shadow/awesome-rsi
• 本文知乎版：万字长文带你读懂 RSI - 知乎
• SEAL: arXiv:2506.10943
• Prime Agent: arXiv:2608.23552
• ReasoningBank: arXiv:2509.25140
• TRACE: arXiv:2608.22793
• SkillSmith: arXiv:2606.01314
• SkillFlow: arXiv:2604.17308
• DGM: arXiv:2505.22954
• MGM: arXiv:2608.07645
• Recuris: arXiv:2608.24876
• Evo-Harness: arXiv:2608.15071
• GDPevo: arXiv:2608.03764
• FinEvo-Bench: arXiv:2608.06144
• Mem²Evolve: arXiv:2604.10923

声明：仅作学习交流之用。如有侵权请联系删除。