A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence

论文阅读：A Survey of Self-Evolving Agents——自进化 Agent 的 What、When、How 与 Where

论文标题：A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence
作者：Huan-ang Gao、Jiayi Geng、Wenyue Hua 等
发表位置：Transactions on Machine Learning Research（TMLR）
arXiv：2507.21046
原文链接：https://arxiv.org/abs/2507.21046
项目仓库：https://github.com/CharlesQ9/Self-Evolving-Agents
主题：Self-Evolving Agent、Agent Learning、Memory、Tool Learning、Agent Architecture、Continual Adaptation
核心问题：一个 Agent 怎样根据自己产生的轨迹和反馈，持续修改模型、上下文、工具乃至自身架构，从而把一次次交互经验真正转化为未来能力。

1. 引言：为什么需要 Self-Evolving Agent？

大语言模型已经能够完成推理、代码生成、工具调用等复杂任务，但传统 LLM 本质上仍然是一个相对静态的系统。

模型完成预训练、SFT 或 RL 之后，其主要能力基本被冻结。部署以后，即使它连续遇到新的任务、犯下相似的错误、获得新的环境反馈，也不意味着这些经验会自动转化为下一次任务中的能力。

例如，一个 Agent 今天在网页任务中发现：

某网站的搜索框必须先点击激活，
否则直接输入文本不会生效。

传统 Agent 可能只是这一次任务中通过反思解决了问题。

下一次重新执行任务时，它仍然可能再次犯同样的错误。

Self-Evolving Agent 希望建立的是另一种循环：

执行任务
   ↓
产生 trajectory
   ↓
获得成功 / 失败 / 环境反馈
   ↓
分析自己的能力缺口
   ↓
修改自身某个组成部分
   ↓
下一次任务使用修改后的 Agent

因此，论文认为 Agent 研究正在经历一种转变：

LLM
↓
Foundation Agent
↓
Self-Evolving Agent
↓
更开放的下一代 Agentic Intelligence

这里真正变化的并不是“模型会不会使用工具”，而是：

Agent 是否拥有从交互经验中持续改变自己的能力。

2. 什么才算 Self-Evolving Agent？

这是这篇综述最重要的基础问题之一。

因为如果把“性能经过训练提高了”都称作 self-evolution，那么普通 SFT、RL、Prompt Engineering 甚至人工修改代码都可以被算进去，概念会变得没有意义。

论文因此首先给出了一个形式化的 Agent 表示。

2.1 Agent 系统的组成

一个 Agent 系统可以表示为：

Π = (Γ, {ψ_i}, {C_i}, {W_i})

其中：

符号	含义
`Γ`	Agent 的整体架构或工作流拓扑
`ψ_i`	第 i 个节点使用的 LLM / MLLM
`C_i`	节点上下文，包括 Prompt、Memory 等
`W_i`	Agent 可以使用的工具或 API

换句话说，一个 Agent 并不只有“大模型”这一部分。

它实际上可以拆成：

Agent
├── Model
├── Context
│   ├── Prompt
│   └── Memory
├── Tools
└── Architecture / Workflow

Agent 面对任务后，与环境不断交互，最终形成一条轨迹：

τ = (o_0, a_0, o_1, a_1, ...)

其中：

o 是环境观察；
a 是 Agent 的行动；
最终还会获得反馈 r。

反馈可以是：

任务成功 / 失败
reward
编译器报错
环境状态变化
用户反馈
自然语言 critique
Agent 自己的 confidence
另一个 evaluator 的评价

2.2 Self-Evolution 的核心形式

论文把自进化过程表示为：

f(Π, τ, r) = Π'

也就是：

根据 Agent 自己产生的轨迹 τ 和反馈 r，把当前 Agent Π 修改成新的 Agent Π'。

连续执行多个任务时：

Π_0
 └─任务 T_0 → τ_0, r_0 → Π_1
                           └─任务 T_1 → τ_1, r_1 → Π_2
                                               ...

于是 Agent 不再只是不断解决任务，而是在解决任务的同时不断改变自身。

整个过程的目标是：

maximize Σ U(Π_j, T_j)

即让不断演化后的 Agent 在一系列任务上的累计效用越来越高。

3. Self-Evolving Agent 的三个关键判定条件

论文进一步给出了一个 operational definition。

一个系统要真正具有 Self-Evolving 的性质，至少应当包含三个特征。

3.1 更新必须由自身经验驱动

更新依据应该来自：

自己的 trajectory
自己的 interaction
自己的 environment feedback
自己的 self-generated data
自己的 reflection

而不是工程师提前准备好一个固定数据集，然后按照固定计划训练。

关键区别在于：

Agent 的实际经历决定了它下一步学习什么。

例如：

Agent 发现自己不会处理 Git merge conflict
        ↓
主动收集相关经验
        ↓
生成训练数据 / 创建工具 / 保存经验
        ↓
提升未来处理 merge conflict 的能力

这属于 experience-dependent evolution。

3.2 更新必须产生持久影响

如果模型只是当前上下文中收到一句：

下一次记得先检查文件是否存在。

然后任务结束之后这条信息完全消失，这只是普通 instruction following。

Self-Evolution 要求更新能够持续影响未来行为。

例如：

Memory 被永久更新
Prompt 被修改
Skill 被保存
Tool 被创建
模型参数被更新
Workflow 被修改

也就是说：

Evolution 必须改变未来的 Agent policy，而不能只影响当前一步。

3.3 Agent 应当具有一定的主动学习能力

真正强意义上的 Self-Evolving Agent 不只是“等待别人给训练数据”。

它应该能够主动：

探索环境
发现能力缺口
生成任务
收集经验
反思失败
尝试新的策略
修改自身

论文因此区分：

Passive Learning
    外部决定什么时候学、学什么

Active Evolution
    Agent 根据自身经历主动决定如何改进

不过作者也承认，目前完全不依赖人工干预的强自进化系统还不是主流。

因此论文覆盖的范围可以理解成一个连续谱：

Proto-Evolution
反馈驱动的 Prompt / Memory 更新
        ↓
自生成数据与持续学习
        ↓
工具与 Workflow 自我修改
        ↓
Strong Self-Evolution
Agent 自主诊断、学习与重构自身

4. Self-Evolving Agent 与传统学习范式有什么区别？

Self-Evolving Agent 与 Curriculum Learning、Lifelong Learning、Model Editing 有明显交集，但关注层次不同。

4.1 Curriculum Learning

Curriculum Learning 关注：

应该按照什么顺序给模型安排训练任务？

例如：

简单任务
→ 中等任务
→ 困难任务

它主要改变的是训练数据和任务组织方式。

而 Self-Evolving Agent 更进一步关心：

Agent 能不能根据自己的能力主动生成或调整 Curriculum？

4.2 Lifelong Learning

Lifelong Learning 关注：

不断学习新任务
+
不要忘掉旧任务

因此灾难性遗忘是它的重要问题。

Self-Evolving Agent 与它高度相关，但研究范围更宽。

因为 Agent 可以进化的不只是模型参数，还包括：

Memory
Prompt
Tools
Workflow
Multi-Agent topology

4.3 Model Editing

Model Editing 通常希望对模型进行精确的知识修改，例如：

旧知识 → 新知识

同时尽量不影响其他能力。

它关注的是参数空间中的局部修改。

而 Self-Evolving Agent 把“可修改对象”扩展到了整个系统：

Model
Context
Tool
Architecture

因此作者把 Self-Evolving Agent 看成一种更偏向系统级适应的范式。

5. 论文的核心 Taxonomy

这篇论文最主要的贡献并不是提出一个新的 Self-Evolving Agent 算法，而是试图给这个快速发展的领域建立统一坐标系。

作者围绕四个问题组织现有研究：

What to Evolve?
    ↓
Agent 的什么东西发生变化？

When to Evolve?
    ↓
什么时候发生学习？

How to Evolve?
    ↓
根据什么反馈、采用什么学习机制？

Where to Evolve?
    ↓
这些进化机制被应用在哪里？

在此之外，还专门讨论：

How to Evaluate?

即怎样判断一个 Agent 是否真的在持续进化。

【Figure 3（Self-Evolving Agent 的总体框架：What、When、How、Where 与 Evaluation）】

6. What to Evolve：Agent 到底可以进化什么？

论文首先从 Agent 自身结构出发，将可进化部分划分为四个主要层次：

Model
Context
Tool
Architecture

这也是理解整个领域最直接的一套分类方式。

6.1 Model Evolution：直接改变模型本身

最直接的 Self-Evolution 是修改模型参数。

普通训练过程通常是：

人工准备数据
→ Train
→ Deploy

Self-Evolving Model 则希望形成：

Agent 执行任务
→ 自己获得新的 trajectory
→ 从 trajectory 中生成训练信号
→ 更新模型
→ 再执行任务

论文把其中一个重要方向称为 Policy Evolution。

例如 Self-Challenging Agent：

模型扮演 Challenger
        ↓
自己生成任务
        ↓
模型扮演 Executor
        ↓
解决任务
        ↓
保留高质量成功轨迹
        ↓
用于训练自己

其本质是：

Agent 不再完全依赖人类提供训练集，而是参与“生成自己的训练课程”。

另一类方法则直接把环境交互反馈转化为训练信号。

例如：

execution trajectory
environment feedback
natural-language critique
reward
        ↓
SFT / RL
        ↓
更新 Agent policy

SELF、SCoRe、PAG、RAGEN、DYSTIL 等工作都可以放在这一方向下。

因此 Model Evolution 的核心问题可以概括成：

Agent 能不能把自己执行任务时产生的数据转化成参数层面的长期能力。

6.2 Context Evolution：不改权重，也可以进化

第二类非常重要的进化对象是 Context。

论文将它进一步拆成：

Context
├── Memory Evolution
└── Prompt Optimization

这也是目前大量 Agent Memory 工作所处的位置。

6.2.1 Memory Evolution

Agent 可以不断把过去经历保存为长期记忆：

任务
→ trajectory
→ success / failure
→ extract experience
→ write memory

以后遇到类似任务时：

query
→ retrieve memory
→ inject context
→ improve decision

但高级 Memory Evolution 并不是简单“把所有历史存起来”。

系统还需要决定：

什么应该存？
什么应该忘？
什么应该更新？
什么应该合并？
什么时候检索？
哪些失败值得保留？
怎样从具体轨迹抽象出通用经验？

例如 Mem0 使用类似：

ADD
UPDATE / MERGE
DELETE

的操作管理长期记忆。

一些工作更进一步，让 Memory Manager 通过学习决定这些操作。

Expel 和 ReasoningBank 等方法则不满足于保存原始案例，而是尝试从成功和失败轨迹中提炼更通用的：

rule
insight
reasoning strategy

因此论文对 Memory Evolution 的理解实际上相当宽：

Memory 不只是数据库，而是 Agent 把短期经历转换成长期能力的一条非参数化通道。

6.2.2 Prompt Optimization

Prompt 也是 Agent policy 的一部分。

如果 Agent 根据过去任务结果不断改变自己的 System Prompt：

P_0
→ evaluate
→ critique
→ P_1
→ evaluate
→ P_2

即使模型参数完全冻结，Agent 的未来行为仍然发生了持久变化。

因此这同样可以被视为 Self-Evolution。

代表性工作包括：

APE
ORPO
ProTeGi
PromptAgent
PromptBreeder
DSPy
TextGrad
SPO
LLM-AutoDiff

其中一个非常直观的思想是把自然语言反馈看成一种“文本梯度”。

例如：

当前 Prompt
    ↓
模型输出
    ↓
Evaluator:
"你的回答没有先验证用户给出的假设"
    ↓
Textual Gradient
    ↓
修改 Prompt：
"在执行任务前首先验证关键假设"

这相当于：

数值梯度 → 修改权重

Textual Gradient → 修改 Prompt / Workflow

因此 Prompt 不再是工程师一次性写好的静态字符串，而变成一个可以被优化的变量。

6.3 Tool Evolution：从“使用工具”走向“创造工具”

传统 Tool-Using Agent 的假设是：

工程师提供 Tool Set
        ↓
Agent 从中选择工具

Self-Evolving Agent 则进一步希望实现：

发现能力缺口
        ↓
创建新 Tool
        ↓
测试 Tool
        ↓
根据失败修改 Tool
        ↓
熟练掌握
        ↓
加入长期 Skill Library

论文把 Tool Evolution 大体划分为三个阶段：

阶段	核心问题
Creation	Agent 能否自己创造缺失工具
Mastery	创建以后能否通过实践不断改进
Selection / Management	工具越来越多以后怎样管理和组合

Tool Creation

Voyager 会在 Minecraft 中不断产生新的技能并保存。

Alita、ATLASS 等系统则会在发现能力缺口时动态构建或寻找新的工具。

CREATOR 将：

Tool Creation

与：

Tool Usage

分开，使创建出来的能力更加模块化和可复用。

Tool Mastery

一个刚生成的 Python 函数并不意味着 Agent 已经真正掌握了它。

Agent 还可能遇到：

参数错误
API 返回异常
环境状态不符合预期
代码 bug
文档描述不清

因此 LearnAct、DRAFT 等工作进一步让 Agent 根据实际执行反馈修订工具。

进化循环于是变成：

create
→ execute
→ observe failure
→ diagnose
→ modify
→ execute again

Tool Selection

当 Agent 的 Skill Library 从十几个工具增长到几百、几千个工具时，又会产生新的问题：

工具太多，本身也会成为搜索负担。

因此 ToolGen、TOOLMEM 等工作开始研究工具选择和工具知识管理。

整个发展方向可以概括成：

Tool User
→ Tool Creator
→ Tool Learner
→ Tool Manager

6.4 Architecture Evolution：连 Agent 自己的结构也可以学习

这是 Self-Evolving Agent 中更激进的一类方向。

传统 Agent Workflow 是人工设计的：

Planner
  ↓
Retriever
  ↓
Executor
  ↓
Critic

但为什么一定是这个结构？

有没有可能让 Agent 自己搜索：

需要几个节点？
节点之间怎样连接？
哪个模型负责哪个节点？
什么时候使用 Memory？
是否需要 Critic？
应该单 Agent 还是 Multi-Agent？

于是 Agent Architecture 本身也可以成为优化变量。

6.4.1 Single-Agent Architecture

TextGrad 可以把最终输出的自然语言反馈逐级传播到 Workflow 中的不同节点。

AgentSquare 则把：

Planner
Memory
Tool
Reasoning Module

等组件组成一个设计空间，再自动搜索更合适的 Agent 结构。

更激进的方向是直接让 Agent 修改自己的代码。

例如：

Darwin Gödel Machine
Gödel Agent
AlphaEvolve

这类系统开始触及：

Agent source code
Agent logic
Agent architecture

自身的递归修改。

甚至还有研究进一步讨论：

不只是 Memory 内容可以进化，Memory System 自己的编码、存储和检索架构也可以进化。

6.4.2 Multi-Agent Architecture

多个 Agent 组成系统后，新的优化对象变成：

Agent 数量
Agent 角色
通信拓扑
任务分工
Workflow
协作策略

例如：

ADAS
AFlow
GPTSwarm
ScoreFlow
FlowReasoner
ReMA

AFlow 将 Agent Workflow 看成搜索空间，并使用搜索算法寻找更优结构。

一些后续工作甚至希望根据每一个 Query 动态生成不同的 Multi-Agent Workflow。

因此 Agent Architecture 的发展轨迹可以概括为：

人工固定 Workflow
        ↓
自动优化节点
        ↓
自动搜索 Workflow
        ↓
Query-specific Workflow
        ↓
Agent 修改自身代码与结构

整体来看，早期研究更多集中在自生成数据、Reflection、Prompt 和 Tool Learning；之后研究逐渐向 Workflow Search、Multi-Agent Evolution、Agent Code Self-Modification 和开放式持续进化扩展。

7. When to Evolve：到底什么时候进行学习？

知道“改什么”以后，下一个问题是：

Agent 应该什么时候进行 Evolution？

论文按照“学习发生在任务执行的什么时间位置”划分为两类：

Intra-Test-Time Self-Evolution
Inter-Test-Time Self-Evolution

7.1 Intra-Test-Time：做一道题的过程中现场学习

Intra-test-time 指：

Agent 在当前任务还没有结束时，就发现自己能力不足，并立即进行适应。

例如：

开始任务
  ↓
尝试方案 A
  ↓
失败
  ↓
Reflection
  ↓
产生新策略
  ↓
继续解决同一个任务

这类方式与当前任务高度耦合。

最典型的是 In-Context Learning：

Reflexion
Self-Refine
AdaPlanner

例如 Reflexion：

Attempt
→ Failure
→ Reflect
→ 把反思加入 Context
→ Retry

模型参数没有变化，但 Agent 在任务生命周期内部已经产生了新的策略状态。

论文也讨论了更强的情况：

Intra-test-time SFT
Intra-test-time RL

也就是说 Agent 甚至可以在解决当前任务期间修改参数。

这种方法具有非常强的针对性，但明显更加昂贵。

7.2 Inter-Test-Time：做完一个任务，再为未来学习

Inter-test-time 指：

完成 Task A
        ↓
总结经验 / 收集 trajectory
        ↓
Evolution
        ↓
开始 Task B

此时学习过程发生在两个任务之间。

例如：

STaR
Quiet-STaR
SELF
SiriuS
RAGEN
WebRL
DigiRL

这类方法更接近持续训练：

interaction
→ data accumulation
→ update
→ next interaction

相比 Intra-Test-Time，它允许系统使用更多计算资源进行：

data filtering
SFT
RL
curriculum generation
replay

因此更适合进行较重的参数更新。

7.3 两种 Timing 的区别

可以把它们理解成：

类型	类比	优点	代价
Intra-Test-Time	一边考试一边总结解题方法	针对当前问题快速适应	推理延迟增加
Inter-Test-Time	做完题后复盘，下次再用	可以进行充分训练	无法立即帮助已经结束的任务

现实中的强 Self-Evolving Agent 很可能同时拥有两层学习：

当前任务：
Reflection / Memory / Search

任务之间：
SFT / RL / Tool Update / Architecture Update

即形成“快适应 + 慢学习”的双时间尺度。

8. How to Evolve：究竟靠什么机制进化？

作者把现有方法进一步归纳成三大类：

Reward-Based Evolution
Imitation & Demonstration Learning
Population-Based & Evolutionary Methods

三者的关键区别在于：

Agent 从哪里知道自己下一步应该怎样变得更好。

8.1 Reward-Based Evolution

Reward-Based 方法给 Agent 的核心信息是：

你这次做得好不好？

而不是直接告诉它：

正确动作应该怎么做。

论文进一步按照反馈来源讨论了多种形式。

8.1.1 Textual Feedback

例如：

"你失败的原因是没有检查目标文件是否存在。"

Reflexion、Self-Refine、TextGrad 等系统可以把这类自然语言反馈转化为下一轮改进依据。

优点是信息丰富。

一个简单的：

reward = 0

只告诉 Agent：

错了

而 textual feedback 可以进一步告诉它：

错在哪里
为什么错
下一步应该检查什么

8.1.2 Internal Reward

反馈也可以来自 Agent 自己。

例如：

confidence
self-certainty
self-evaluation
majority consistency

Agent 可以根据自身概率或自评结果判断哪些轨迹更可靠。

这使系统减少对外部人工标注的依赖，但也带来一个明显风险：

如果 Agent 自己的判断本来就不可靠，那么它可能不断强化自己的错误。

8.1.3 External Reward

反馈来自外部环境，例如：

代码是否通过测试
网页任务是否完成
游戏是否获胜
API 是否返回正确结果
规则检查是否通过

这种 reward 通常比较可靠。

尤其是代码、数学、游戏、GUI 等存在明确 verifier 的任务，非常适合形成：

Agent
→ Environment
→ Reward
→ Agent Update

闭环。

8.1.4 Implicit Reward

有些方法不依赖复杂的显式 Reward Model，而直接利用简单标量反馈进行上下文中的策略调整或 reinforcement-style adaptation。

因此 Reward-Based Evolution 的核心优势是：

Agent 可以自由探索，然后根据结果自己寻找改进方向。

问题则在于：

Reward 稀疏
Credit Assignment 困难
Reward Hacking
训练成本高

8.2 Imitation & Demonstration Learning

Imitation Learning 给 Agent 的不是一句：

你得了 0 分。

而是直接给它：

这是一个正确的完整解法。

因此两种方法的区别可以理解为：

Reward：
你自己探索，我告诉你结果好不好

Imitation：
我直接给你一个值得模仿的行为轨迹

论文进一步讨论了三类来源。

Self-Generated Demonstration

Agent 自己生成候选解法，再筛选高质量结果。

例如 STaR：

生成 reasoning
→ 检查答案
→ 保留成功 reasoning
→ 使用成功 reasoning 训练自己

形成一种自举过程。

Cross-Agent Demonstration

一个 Agent 从另一个 Agent 的高质量行为中学习。

例如：

Strong Agent / Expert Agent
        ↓
trajectory
        ↓
Student Agent

这使知识可以在 Agent 之间传播。

Hybrid Demonstration

将：

Imitation
+
Reward
+
Self-generated Data

组合起来。

这种方法通常更加稳定，因为高质量 demonstrations 可以降低随机探索成本。

但它也可能限制探索：

如果 Agent 始终模仿已有答案，就不容易发现超越现有 demonstrations 的新策略。

8.3 Population-Based Evolution

第三条路线直接借鉴生物进化。

不再维护一个 Agent，而是维护一群候选 Agent：

Agent_1
Agent_2
Agent_3
...
Agent_N

然后执行：

Evaluation
↓
Selection
↓
Mutation
↓
Crossover / Modification
↓
下一代 Population

例如：

Darwin Gödel Machine
GENOME
SPIN

等工作都可以放入这类范式。

它最大的价值是：

可以同时探索多个不同方向，而不是让一个 Agent 沿着一条局部路径不断优化。

Multi-Agent Evolution

进一步还可以进化整个 Agent Society：

角色
通信方式
网络拓扑
知识传播方式
协作策略

因此 Evolution 不再只是：

How does one agent become better?

而开始转向：

How does an agent population become better?

这也是作者认为从 individual intelligence 走向 collective intelligence 的一个重要方向。

8.4 三条 Evolution 路线的取舍

整体上可以简化成：

方法	主要监督	优势	主要问题
Reward-Based	Reward、自然语言反馈、环境信号	探索能力强，自主性高	Reward 设计、Credit Assignment、稳定性
Imitation / Demonstration	高质量轨迹与示范	样本效率高、训练稳定	依赖 Demonstration，探索不足
Population-Based	Fitness、竞争与选择	多样性高、适合开放式搜索	计算成本高、样本效率低

它们并不是互斥路线。

实际系统完全可能：

Population Search
        +
Reward Selection
        +
Demonstration Distillation

组合使用。

8.5 三个跨方法维度

论文还指出，只说“用了 RL”或者“用了 Evolutionary Algorithm”仍然不足以描述 Self-Evolving Agent。

还需要观察几个横向维度。

Online vs. Offline

Offline：
提前收集 Experience
→ Filtering
→ Training

Online：
Agent ↔ Environment
      ↓
实时产生数据并持续更新

On-Policy vs. Off-Policy

On-Policy：
用当前 Agent 自己产生的数据学习

Off-Policy：
使用旧 Agent、Replay Buffer、
Human Demo 或其他 Agent 的经验

On-policy 数据与当前 policy 更匹配，但成本较高。

Off-policy 更容易复用已有数据，但存在 distribution shift。

Reward Granularity

Reward 可以发生在：

Process Level
每一步都反馈

Outcome Level
只看最终任务成功与否

Hybrid
过程 + 最终结果

长链 Agent 任务尤其容易遇到 Credit Assignment：

Action 1
Action 2
Action 3
Action 4
Action 5
        ↓
最终失败

但：

到底是哪一步导致失败？

因此如何把最终反馈准确归因给中间行为，是 Self-Evolving Agent 中非常关键的问题。

9. Where to Evolve：Self-Evolution 被用在哪里？

前面的 What / When / How 描述的是方法。

作者接下来从应用场景出发，将现有 Self-Evolving Agent 大体分成：

General Domain Evolution
Specific Domain Evolution

9.1 General Domain Evolution

General Domain 的目标不是把 Agent 训练成某一个领域专家，而是：

让 Agent 的经验能够逐渐转化成更广泛、更通用的能力。

论文总结了几条重要路线。

9.1.1 Memory Mechanism

最轻量、最常见的 Self-Evolution 方式之一就是长期记忆。

Agent 将：

Success
Failure
Reflection
Strategy
User Feedback

写入 Memory，并在未来任务中重新使用。

它的一个显著特点是：

不需要修改底层模型参数，也能够让 Agent 随交互次数增长而改变行为。

这也是 Agent Memory 被频繁放在 Self-Evolving Agent 框架下讨论的原因。

9.1.2 Curriculum-Driven Training

第二种方法是让 Agent 根据自身能力动态安排学习任务。

例如：

当前任务成功率很高
        ↓
提高任务难度

当前任务频繁失败
        ↓
生成更多相似的中间难度任务

WebRL、Voyager 等工作都包含类似思想。

Curriculum 不再完全由人工设计，而成为：

Agent performance
        ↓
Task Generation
        ↓
Agent Learning
        ↓
New Performance

的闭环。

9.1.3 Model-Agent Co-Evolution

更进一步的问题是：

模型和 Agent 环境能不能一起成长？

如果 Agent 始终在固定任务集上训练，很快就会把现有任务“刷完”。

于是一些方法让：

Task / Environment Generator

与：

Agent / Solver

共同升级。

例如：

Solver 变强
↓
Generator 生成更困难的问题
↓
Solver 再变强
↓
Generator 再提高难度

这非常接近一个开放式 Curriculum：

能力提升
↔
环境难度提升

9.2 Specific Domain Evolution

另一类研究不追求完全通用，而是让 Agent 在特定领域持续积累专业能力。

论文列举的主要领域包括：

领域	Self-Evolution 主要价值
Coding	从编译、测试和 issue 反馈中不断学习
GUI / Web	从真实交互失败中改进操作策略
Finance	根据市场、分析与任务反馈积累专业策略
Medical	利用专业知识、模拟和协作持续优化
Education	根据学生反馈和长期行为进行个性化适应
其他	科研、游戏、Diplomacy 等开放式任务

例如 Coding Agent 具有天然优势：

Code
↓
Compiler / Unit Test
↓
可验证反馈
↓
Agent Learning

因此软件工程是 Self-Evolving Agent 非常适合落地的领域。

GUI Agent 同样拥有：

Screenshot
Action
Environment State
Task Success

这样天然的交互闭环。

而医疗、教育、金融等场景则更加复杂，因为反馈并不总是立即、客观、低风险。

因此不同 Where 往往会反过来决定适合采用哪一种 How。

10. 怎样评估一个 Self-Evolving Agent？

论文认为，这是当前领域非常薄弱但又非常关键的一部分。

传统 Agent 通常采用：

固定 Benchmark
→ 跑一次
→ Success Rate

但这无法真正回答：

Agent 有没有随着经验变得越来越好？

例如两个 Agent：

Agent A：
第一次 80%
第 100 次还是 80%

Agent B：
第一次 50%
经过持续学习后达到 90%

如果只测最终一次性能，两者的“进化能力”完全无法被描述。

因此 Self-Evolving Agent 的评估必须从：

single-shot evaluation

转向：

longitudinal evaluation

即观察整个 evolution trajectory。

10.1 Adaptivity：到底有没有越学越好？

Adaptivity 衡量：

Agent 能不能通过经验提升当前领域中的表现。

最直观的方式是观察学习曲线：

Performance
 ^
 |                    ●
 |              ●
 |        ●
 |   ●
 +------------------------> Interaction / Iteration

典型指标包括：

Success Rate by Iteration Steps
Adaptation Speed

也就是说，不只看最终成功率，还要看：

学习多少次才变强？
变强速度多快？

10.2 Retention：学会新的以后，会不会忘掉旧的？

持续学习必然伴随另一个问题：

Task A 学会
↓
Task B 学会
↓
Task C 学会
↓
重新测试 Task A
↓
忘了

因此 Retention 是 Self-Evolution 的核心指标。

典型指标包括：

Forgetting（FGT）
Backward Transfer（BWT）

其中 BWT 衡量：

学习后续任务以后，对以前任务的性能产生了什么影响。

如果 BWT 为正，意味着：

学新知识
↓
反而帮助旧任务

这是比较理想的知识迁移状态。

一个值得注意的问题是，目前很多 Agent Benchmark 会在每个任务之间直接 Reset Agent State。

这样实际上根本无法测试：

知识积累
长期记忆
灾难性遗忘

因此 Retention 是当前 benchmark 覆盖相对不足的维度之一。

10.3 Generalization：学到的是经验，还是只记住了任务？

一个 Agent 在某个环境中不断刷题以后成功率提高，并不一定意味着获得真正的能力。

它可能只是：

记住某些具体页面
记住某些 task template
记住固定操作序列

真正的 Generalization 应该表现为：

Domain A 中学习
        ↓
Domain B / unseen task
        ↓
仍然能够受益

因此需要：

OOD Evaluation
Multi-Domain Evaluation
Held-Out Task Distribution

否则一个 Self-Evolving Agent 很可能只是不断 specialization，而不是获得可迁移能力。

10.4 Efficiency：进化不是免费的

如果一个 Agent：

成功率提高 5%

但为了这 5%：

消耗 100 倍 token
执行大量 rollout
调用大量工具
进行数小时 Architecture Search

那么现实意义可能很有限。

因此 Self-Evolving Agent 的成本需要进一步拆成：

成本	含义
Token Usage	推理、反思、Memory、训练所需 token
Step Count	Agent 与环境交互轮数
Wall-Clock Time	实际运行时间
Tool/API Calls	工具调用量
Memory Growth	长期 Memory 持续增长的成本
Human Oversight	人工标注、审核、纠错成本

还可以考虑类似 Cost-per-Gain 的指标：

CPG =
    Total Evolution Cost
    --------------------
    Performance Gain + ε

CPG 越低，意味着单位性能提升所需成本越低。

这一点非常重要，因为 Self-Evolution 很容易出现：

性能确实越来越高
但是系统也越来越贵

的问题。

10.5 Safety：Agent 会不会“越学越歪”？

普通静态模型的 Safety 测试通常是：

当前模型安全吗？

Self-Evolving Agent 则还需要问：

第 1 天安全吗？
第 100 天安全吗？
在持续修改 Memory / Tool / Model 后还安全吗？

常见评估可以包括：

Safety Score
Harm Score
Completion Under Policy
Risk Ratio
Refusal Rate
Leakage Rate

真正困难的问题是 Safety Drift：

Agent_0 aligned
↓
不断获得新的 reward
↓
Agent_1
↓
Agent_2
↓
...
↓
Agent_n 出现新的危险行为

也就是说：

初始模型安全，不意味着持续进化后的模型仍然安全。

10.6 Self-Directedness：到底有多少学习是真正自主完成的？

还有一个非常值得注意的问题。

假设某论文声称：

Our Agent self-evolves from 20% → 70%.

但实际上背后是：

人工设计 Curriculum
人工标注 Reward
人工筛选数据
人工指定什么时候训练
人工决定更新方式

那么这 50 个百分点究竟有多少应该归功于“Self-Evolution”？

因此评价 Self-Evolving Agent 时，至少应该透明报告：

Task / Curriculum 是人工设计还是 Agent 自主产生；
Feedback 来自人工、规则、环境还是 Agent 自己；
Evolution 过程中需要多少次外部人工干预。

也就是说：

Self-Evolving Agent 不应该只比较“最后有多强”，还应该比较“有多少成长是自己完成的”。

10.7 Evaluation 应该从静态走向长周期

整个 Evaluation Paradigm 可以理解成三个时间尺度：

Static Assessment
        ↓
Short-Horizon Adaptive Assessment
        ↓
Long-Horizon Lifelong Assessment

Static

测试固定能力：

SWE-bench
OSWorld
GAIA
AgentBench
ToolBench
...

适合回答：

Agent 现在有多强？

Short-Horizon

允许 Agent 在任务执行期间进行少量适应，然后比较：

Before Adaptation
vs.
After Adaptation

适合测试 test-time learning。

Long-Horizon

持续提供一系列任务：

T1 → Learn
T2 → Learn
T3 → Learn
...
T100 → Learn

并不断回测：

Adaptivity
Retention
Generalization
Efficiency
Safety

这才真正对应 Self-Evolving Agent。

【Figure 9（Self-Evolving Agent 的长期评估维度与不同时间尺度的 Evaluation Paradigm）】

当前领域一个很明显的评估缺口就是：

很多所谓 Self-Evolving Agent 最终仍然只在静态 Benchmark 上报告一次成功率，没有真正衡量 Evolution Trajectory。

11. 从这篇综述看，Self-Evolving Agent 的完整闭环是什么？

综合 What、When、How 和 Evaluation，可以把论文中的 Self-Evolving Agent 抽象为下面的循环：

                 ┌─────────────────┐
                 │      Task       │
                 └────────┬────────┘
                          ↓
                 ┌─────────────────┐
                 │ Agent Execution │
                 └────────┬────────┘
                          ↓
                    Trajectory τ
                          ↓
                 ┌─────────────────┐
                 │    Feedback r   │
                 └────────┬────────┘
                          ↓
                  Capability Gap
                          ↓
               ┌──────────┴──────────┐
               │                     │
        Intra-Test Evolution   Inter-Test Evolution
               │                     │
               └──────────┬──────────┘
                          ↓
              Choose Evolution Target
                          ↓
          ┌───────────────┼───────────────┐
          ↓               ↓               ↓
        Model          Context          Tools
                          ↓
                     Architecture
                          ↓
                    Updated Agent
                          ↓
                       Π'
                          ↓
                    Future Tasks

而真正开放式的系统还会增加一层：

Agent capability
      ↓
自动生成更适合自己的 Curriculum / Environment
      ↓
产生新的 Experience
      ↓
再次 Evolution

于是形成：

Agent
↔
Data
↔
Environment
↔
Evaluation

共同演化的闭环。

12. Future Directions

论文最后没有简单把未来方向总结成“更大模型、更长上下文”，而是重点讨论了几个更深层的问题。

12.1 Personalized AI Agents

Self-Evolving Agent 很自然地适合做个性化系统。

例如长期助手可以不断学习：

用户偏好
工作习惯
表达方式
任务流程
长期目标

然后随着互动越来越懂用户。

但这里存在明显矛盾：

个性化越强
→ 需要保存更多用户数据

数据保存越多
→ Privacy Risk 越高

未来问题包括：

如何选择性记忆？
用户要求删除以后是否真正忘记？
哪些更新可以在本地设备完成？
如何避免长期 personalization 产生 bias drift？

因此 Personalized Self-Evolving Agent 本质上需要同时解决：

Adaptation
Retention
Forgetting
Privacy
Safety

12.2 Generalization

第二个问题是：

Agent 会不会越来越擅长一个环境，却越来越不会处理别的问题？

持续 Evolution 很容易导致 specialization。

因此未来需要解决：

Cross-Domain Adaptation
Catastrophic Forgetting
Knowledge Transfer
Scalable Architecture

特别是：

Agent A 学到的新知识

怎样可靠地传播给：

Agent B / Agent C

仍然是很值得研究的问题。

这也是 Multi-Agent Knowledge Transfer 的重要研究空间。

12.3 Safe and Controllable Self-Evolution

这是 Self-Evolving Agent 中非常关键的一条未来方向。

Self-Evolution 会引入传统静态模型不存在或不突出的风险。

Model Drift

Agent 根据自己生成的数据继续训练：

Model
→ self-generated data
→ Model'
→ self-generated data
→ Model''

长期下来可能逐渐偏离原有行为约束。

Reward Hacking

Agent 可能发现：

某种不符合设计者原意的行为

反而能获得更高 Reward。

例如系统把：

用户满意度

作为 Reward，Agent 可能学会通过某种投机行为提高指标，而不是学会真正解决用户问题。

Unsafe Tool Evolution

如果 Agent 能：

自己写代码
下载代码
安装工具
调用 API

那么“Tool Creation”本身就变成一个新的安全边界。

生成出来的新工具可能包含：

漏洞
恶意依赖
隐私泄露
危险系统调用

因此 Self-Evolving Agent 需要更加完整的 Safety Lifecycle，例如：

Tool Sandboxing
        +
Automated Verification
        +
Audit Trail
        +
Version Control
        +
Rollback
        +
Continuous Monitoring
        +
Automated Red-Teaming
        +
Human Approval Gate

特别值得注意的是：

Self-Evolving 系统必须能够回滚。

因为一个能修改自身的系统如果只有：

Update

没有：

Undo / Rollback

那么错误的 Evolution 很可能被持续积累。

12.4 Ecosystems of Multi-Agents

未来的 Self-Evolution 可能不只是一个 Agent 单独学习，而是：

Agent A
Agent B
Agent C
...

组成不断变化的生态系统。

此时会出现新的问题。

Individual vs. Collective

单个 Agent 的最佳选择，不一定是整个 Multi-Agent System 的最佳选择。

Dynamic Roles

角色可能需要随着任务和经验改变：

Planner
Critic
Executor
Retriever

不应该永远固定。

Knowledge Evolution

不同 Agent 的知识如何：

传播
验证
冲突解决
更新
遗忘

仍然缺少成熟机制。

Evaluation

现有 Multi-Agent Benchmark 大量采用静态团队和静态任务，因此无法真正衡量：

团队结构是否越来越合理？
角色是否随时间发生变化？
知识是否在 Agent 之间传播？
协作能力是否持续提升？

因此 Multi-Agent Co-Evolution 会是 Self-Evolving Agent 很值得关注的下一阶段。

13. 这篇综述最重要的几个观点

如果把整篇论文进一步压缩，可以还原成下面几层逻辑。

第一层：Self-Evolution 不等于训练

决定一个系统是否属于 Self-Evolving Agent 的，不是：

有没有使用 RL
有没有使用 SFT

而是：

谁决定学什么？
学习是否来自 Agent 自己的 experience？
改变是否能够持续影响未来？
Agent 是否具有主动探索和改进能力？

第二层：Agent Evolution 不等于 Model Evolution

Agent 可以改变：

Model
Memory
Prompt
Tool
Workflow
Multi-Agent Structure

因此未来 Agent Learning 很可能越来越偏向：

整个 Agent System 的联合优化。

而不是只训练 backbone LLM。

第三层：Memory 是最轻量的一种 Self-Evolution

很多 Agent Memory 工作之所以能够被放入 Self-Evolving Agent，是因为：

Experience
→ Memory
→ Persistent Context
→ Future Policy Change

本身就符合一种非参数化 Evolution。

不过它位于较轻量的一端。

更强的 Evolution 还包括：

Memory Content
↓
Prompt
↓
Tool
↓
Model Parameters
↓
Workflow
↓
Agent Source Code

不断扩大的可修改范围。

第四层：Self-Evolution 最终是一个 Feedback Loop 问题

无论采用 Memory、RL、Tool Learning 还是 Evolutionary Search，本质都可以抽象成：

Experience
→ Feedback
→ Credit Assignment
→ Update
→ New Experience

因此这个领域很多核心难题其实集中在：

怎样获得可靠反馈？
反馈应该归因给谁？
哪些经验值得保留？
哪些修改真正提高未来性能？
什么时候应该更新？
什么时候应该停止更新？

第五层：未来 Benchmark 必须评估“成长过程”

Self-Evolving Agent 最关键的不是：

最终 Accuracy = 90%

而应该是：

初始能力是多少？
经历了什么？
进行了多少自主探索？
花了多少成本？
性能如何变化？
旧能力有没有遗忘？
能否迁移到新领域？
Safety 有没有下降？

因此 Evaluation 对象应该从一个静态点：

Π

变成完整轨迹：

Π_0 → Π_1 → Π_2 → ... → Π_n

这也是 Self-Evolving Agent 与普通 Agent Benchmark 最本质的差别之一。

14. 总结

这篇论文并没有提出一个新的 Self-Evolving Agent 方法，而是试图为正在快速形成的研究领域建立统一的分析框架。

作者首先把 Agent 表示为由：

Model
Context
Tools
Architecture

组成的完整系统，并将 Self-Evolution 抽象为：

Π_{t+1} = f(Π_t, trajectory_t, feedback_t)

即 Agent 根据自己的交互轨迹和反馈，持续修改自身，并让这种改变影响未来任务。

围绕这一过程，论文提出四个核心问题：

What to Evolve：修改 Model、Memory、Prompt、Tool 还是 Architecture；
When to Evolve：在当前任务内部进行 Intra-Test-Time 学习，还是在任务之间进行 Inter-Test-Time 学习；
How to Evolve：采用 Reward、Demonstration 还是 Population-Based Evolution；
Where to Evolve：面向通用 Agent，还是 Coding、GUI、Finance、Medical、Education 等特定领域。

进一步地，Self-Evolving Agent 不能继续只使用静态任务成功率评估，而应该沿整个 Evolution Trajectory 衡量：

Adaptivity
Retention
Generalization
Efficiency
Safety

目前真正强意义上的完全自主 Self-Evolution 仍然更多是一项目标。

大量现有工作只覆盖其中一部分，例如：

通过 Memory 积累经验
根据 Reflection 修改 Prompt
使用环境 Reward 训练 Policy
自动生成 Tool
搜索 Agent Workflow
修改 Agent 自身代码

但这些方向正在逐渐形成同一个闭环：

Agent 与环境交互
        ↓
产生经验
        ↓
获得反馈
        ↓
发现能力缺口
        ↓
修改自身
        ↓
继续与新的环境交互

因此，这篇综述最重要的价值并不是给出某一种具体实现，而是明确提出：

下一代 Agent 的核心能力可能不只是“解决任务”，而是“从解决任务的过程本身持续学习如何成为一个更好的 Agent”。

这也是 Self-Evolving Agent 相较于传统静态 LLM Agent 最核心的研究命题。

参考

Huan-ang Gao, Jiayi Geng, Wenyue Hua, et al. A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence. arXiv:2507.21046.
https://arxiv.org/abs/2507.21046
Self-Evolving Agents 项目仓库：
https://github.com/CharlesQ9/Self-Evolving-Agents

posted @ 2026-08-11 17:00 YourF4u1t 阅读(4) 评论(0) 收藏举报

刷新页面返回顶部