MetaSkill-Evolve: Recursive Self-Improvement of LLM Agents via Two-Timescale Meta-Skill Evolution

论文阅读：MetaSkill-Evolve——让 Agent 不仅进化 Skill，还进化“如何进化 Skill”

论文标题：MetaSkill-Evolve: Recursive Self-Improvement of LLM Agents via Two-Timescale Meta-Skill Evolution
作者：Zefeng Wang, Minxi Yan, Jinhe Bi, Sikuan Yan, Volker Tresp, Yunpu Ma
作者机构：LMU Munich、The Chinese University of Hong Kong、Munich Center for Machine Learning（MCML）、MemAgents Lab
发表状态：arXiv preprint
arXiv 编号：2607.05297
首次提交：2026 年 7 月 6 日
原文链接：https://arxiv.org/abs/2607.05297
主题：LLM Agent、Skill Evolution、Self-Improvement、Recursive Self-Improvement、Meta-Skill
核心问题：现有 Agent Self-Improvement 通常只优化“Agent 应该怎么完成任务”，而用于改进 Skill 的那套流程本身仍然是人工固定的。能否进一步让 Agent 连“自己应该如何改进自己”也一起学习和进化？

1. 论文要解决什么问题？

这篇论文从一个很自然的问题出发。

现在很多 LLM Agent 会使用 Skill。

这里的 Skill 可以简单理解成一份可复用的“任务经验说明书”。例如，一个 Agent 经常需要处理 Excel 表格，那么它的 Skill 中可能记录：

  • 遇到表格时先检查列名；
  • 数值列需要注意单位；
  • 做比例计算前先判断百分数格式；
  • 最终回答之前重新核对关键数字。

论文中的 Skill 并不是模型参数，而主要是一类可以被 Agent 读取和修改的 Markdown 文件，例如 SKILL.md。

相比每次都从零开始解决问题，把过去总结出的程序性知识保存成 Skill，显然能够提升 Agent 的任务能力。

进一步地，近来的 Self-Improving Agent 不再满足于人工写好一份 Skill，而是形成：

执行任务 → 发现失败 → 分析失败 → 修改 Skill → 再次执行

这样的循环。

于是 Skill 本身可以逐步演化。

但是作者认为，这里还存在一层没有被优化。

假设我们现在有这样一套 Skill 自我改进流程：

  1. Analyzer 分析失败原因；
  2. Retriever 找相关历史经验；
  3. Allocator 决定尝试多少个修改方案；
  4. Proposer 提出具体修改；
  5. Evolver 真正修改 Skill 文件。

传统 Skill Evolution 优化的是：

Skill 本身。

但上面这五个步骤“应该怎么做”，通常仍然是研究者事先写死的。

例如：

  • Analyzer 应该怎么诊断错误？
  • Retriever 应该优先找什么经验？
  • 一次失败应该尝试一个修改方案还是三个？
  • Proposer 应该大胆重写还是保守微调？
  • Evolver 应该如何检查修改结果？

这些规则一旦写好，在整个 Self-Improvement 过程中基本不会变化。

作者因此把问题概括成：

现有系统会进化 what the agent does，但不会进化 how the agent improves。

也就是：

  • Task Skill：Agent 怎么做任务；
  • Meta-Skill：Agent 怎么改进自己做任务的方法。

MetaSkill-Evolve 的核心思想，就是让这两层一起进化。

image

【Figure 1（No-Skill、Static Skill、Single-Level Evolution 与 MetaSkill-Evolve 四种范式的对比）】

Figure 1 很直观地展示了论文想解决的问题：

范式 Task Skill Skill 改进流程
No-Skill 没有 没有
Static Skill 固定 没有
Single-Level Evolution 会进化 固定
MetaSkill-Evolve 会进化 也会进化

因此，这篇论文所谓的 Recursive Self-Improvement，并不是让模型无限层递归修改自己，而是一个受约束的一层递归：

用于修改 Skill 的改进流程，本身也成为被修改的对象。

2. 从 Single-Level Evolution 到 MetaSkill-Evolve

理解这篇论文最关键的一点，是区分两个东西：

  • Task Skill
  • Meta-Skill

2.1 Task Skill：Agent 应该怎么完成任务

论文把 Task Skill 记为 \(s\)。

它是一份 Markdown 格式的 Agent program，其中记录：

  • 任务步骤；
  • 工具使用方法；
  • 启发式规则；
  • 常见失败及处理策略；
  • 其他程序性知识。

对于一个任务 \(T\)，输入为 \(x\)，参考答案为 \(y\)，使用 Skill \(s\) 的 Agent 记为 \(A_s\)。

Skill 的效用定义为：

\[U(s) = \mathbb{E}_{(x,y)\sim T} \left[ r(A_s(x),y) \right] \]

其中：

  • \(U(s)\)：当前 Skill 的任务能力；
  • \(A_s(x)\)：Agent 使用 Skill \(s\) 后对输入 \(x\) 的输出；
  • \(r(\cdot)\)：任务奖励，取值范围为 \([0,1]\)。

实际运行时无法计算真正的期望，因此论文使用 validation batch 上的准确率估计 \(U(s)\)。

这就是传统 Skill Evolution 最主要的优化对象：

找到一个更好的 \(s\)，使 \(U(s)\) 更高。

2.2 但谁负责修改 Skill？

问题随之而来：

谁来决定怎么把 \(s\) 改得更好？

MetaSkill-Evolve 把整个 Skill Improvement Pipeline 拆成五个角色：

  1. Analyzer
  2. Retriever
  3. Allocator
  4. Proposer
  5. Evolver

作者进一步为每个角色定义一个 Meta-Skill。

于是：

\[m=(\psi,\sigma,\alpha,\pi,\varepsilon) \]

分别对应：

Meta-Skill Agent 负责什么
\(\psi\) Analyzer 如何诊断失败
\(\sigma\) Retriever 如何检索相关经验
\(\alpha\) Allocator 如何决定搜索预算
\(\pi\) Proposer 如何提出修改方案
\(\varepsilon\) Evolver 如何执行并验证修改

这里非常重要的一点是：

Meta-Skill 本身也只是 Markdown 格式的 SKILL.md。

也就是说，作者没有：

  • 训练一个新的 Meta Model；
  • 增加额外神经网络；
  • 修改 backbone 参数；
  • 设计新的强化学习目标。

Task Skill 是 Markdown 文件。

Meta-Skill 也是 Markdown 文件。

因此，原本能够修改 Task Skill 的那套 Agent Pipeline，理论上也能够反过来修改 Meta-Skill。

这便构成了论文所谓的 Recursive Self-Improvement。

3. Branch：每条进化路线都有自己的“改进方法”

MetaSkill-Evolve 并不是只维护一个全局 Skill。

系统中存在很多不同的进化分支 branch。

每个 branch 的状态定义为：

\[b=(s,m,h) \]

其中：

  • \(s\)：当前 Task Skill；
  • \(m\)：当前 branch 自己的 Meta-Skill；
  • \(h\)：该 branch 的历史记录。

这里有一个非常关键的设计：

Meta-Skill 是 branch-local 的，而不是全局共享的。

也就是说，不同进化路线不仅可以拥有不同 Task Skill，还可以发展出完全不同的“自我改进策略”。

例如：

一个 branch 可能逐渐学到：

对表格抽取类错误，应该采用更激进的大范围 Skill 重写。

另一个 branch 可能学到：

对算术推理错误，更适合进行小范围、保守、渐进式修改。

因此不同 branch 不仅代表：

“我学会了不同的东西。”

还可能代表：

“我学会了用不同的方法学习。”

这正是 MetaSkill-Evolve 相比普通 Skill Evolution 多出来的一层状态。

4. 五个 Agent 分别在做什么？

下面详细来看整个 Pipeline。

image

【Figure 2（MetaSkill-Evolve 完整系统结构，包括 branch state、五 Agent Pipeline、Evolution DAG 和 Frontier Selection）】

整体信息流可以概括成：

当前 Branch
→ 找到失败案例
→ Analyzer 诊断
→ Retriever 找相关历史经验
→ Allocator 决定生成多少个候选方案
→ Proposer 设计修改
→ Evolver 修改 Skill
→ validation 评估
→ 保存进化节点
→ 选择下一条值得继续探索的 Branch

4.1 Analyzer：为什么失败？

Analyzer 由 Meta-Skill \(\psi\) 控制。

系统首先在 training batch 上测试当前 Skill，并选择其中表现最差的案例作为诊断对象。

Analyzer 接收：

  • execution trace；
  • failure reason；
  • 当前相关 Skill。

然后生成三个主要结果：

  1. root-cause analysis；
  2. failure tag \(\phi\)；
  3. 建议修改的 Skill 文件。

例如，一个失败案例可能被标记成：

percentage scaling error

或者：

table row misalignment

这个 tag 后面会被 Retriever 用来寻找相似历史失败。

值得注意的是：

连 failure tag 应该如何分类，也是可以随着 \(\psi\) 的进化而变化的。

因此 MetaSkill-Evolve 不只是修改“错误以后怎么办”，甚至连“应该怎样理解错误”都属于可演化对象。

4.2 Retriever：从其他进化路线中寻找经验

Retriever 由 \(\sigma\) 控制。

它根据 Analyzer 得到的 failure tag \(\phi\)，从整个 Evolution Graph 中检索可能有帮助的历史节点。

候选来源包括：

  • 当前 branch 自己过去的节点；
  • 其他 branch 的节点。

因此不同进化路线之间可以共享经验。

Retriever 首先按照 tag similarity 做粗筛，并按照目标 inspiration 数量的约 3 倍进行 over-fetch。

随后再让 LLM 对这些候选节点进行重排序，最终选择真正交给 Proposer 的 inspiration。

所以 \(\sigma\) 实际控制的是：

不同历史经验应该怎样被重新利用。

这也是 MetaSkill-Evolve 能够实现 cross-branch knowledge sharing 的关键组件。

4.3 Allocator：这次值得尝试几个方案？

Allocator 由 \(\alpha\) 控制。

它负责决定当前父节点应该产生多少个 child：

\[K\in[1,K_{\max}] \]

如果最近很多修改都没有带来提升，说明当前 branch 可能已经进入 stagnation。

此时 Allocator 可以扩大搜索宽度：

一次生成更多不同修改方案。

反过来，如果最近的修改非常有效，就没有必要浪费大量计算尝试很多候选方案。

因此可以减少 \(K\)。

作者将其设计成一种 adaptive search budget：

卡住了，就多探索几个方向；
找到有效方向以后，就减少无意义的搜索。

默认情况下：

  • \(K_{\max}=3\)；
  • 初始 \(K=2\)。

4.4 Proposer：具体应该怎么修改？

Proposer 由 \(\pi\) 控制。

它接收：

  • 失败案例 \(f\)；
  • Analyzer 的分析 \(a\)；
  • Retriever 找到的 inspiration \(I\)。

然后生成一个具体编辑方案 \(\delta\)。

其中包含：

  • 修改哪个部分；
  • 修改成什么；
  • 为什么这么修改。

如果 Allocator 选择 \(K>1\)，系统还会额外要求不同 child：

从不同 intervention angle 提出修改。

目的是避免生成三个几乎一样的候选 Skill。

因此 Proposer 负责把：

“为什么失败”

真正转换成：

“Skill 应该怎么改”。

4.5 Evolver：真正修改文件

Evolver 由 \(\varepsilon\) 控制。

它负责把 Proposer 生成的修改方案真正落实到磁盘中的 Skill 文件。

具体包括：

  • 读取当前 Skill；
  • 执行文件修改；
  • 检查修改是否与 proposal 一致；
  • 使用修改前后的 hash 判断是否真的发生变化；
  • 刷新 Skill registry。

因此 Evolver 是真正将自然语言修改建议转化成 Agent 可使用工件的执行模块。

5. 为什么还需要 Evolution Graph？

如果只是：

失败 → 修改 → 使用新版本

那么整个过程很容易退化成单一路线的贪心搜索。

MetaSkill-Evolve 因此保存整个 Skill Evolution History。

作者使用 SQLite 保存一个有向无环图：

\[G=(V,E) \]

每一个节点 \(v\) 表示一个已经被评估过的 branch state，保存的信息包括：

  • Task Skill \(s_v\)；
  • Meta-Skill \(m_v\)；
  • Skill utility \(U_v\)；
  • 相比父节点的提升 \(\Delta U_v\)；
  • failure tag \(\phi_v\)；
  • branch path；
  • 被选择次数。

5.1 两类边

图中存在两类边。

Lineage Edge

表示正常的父子进化关系：

Parent Skill → Child Skill

即一个 Skill 是从哪个 Skill 修改而来的。

Inspiration Edge

表示 Retriever 使用了另外一条 branch 中的某个节点作为参考。

因此 Evolution Graph 不只记录：

“这个版本从谁修改而来。”

还记录：

“修改过程中借鉴了谁的经验。”

6. 并不是所有 Child 都能继续繁殖

一个 child Skill 生成以后，会在 validation set 上进行评估。

相对于 parent 的提升为：

\[\Delta U_v = U(s_v)-U(s_{\mathrm{parent}}) \]

只有：

\[\Delta U_v>0 \]

的节点才会进入 archive。

Archive 中的节点可以成为以后继续扩展的 parent。

而：

\[\Delta U_v\leq 0 \]

的节点不会成为新的 parent。

但是它们并不会被删除。

作者仍然把失败或者没有提升的节点保存在 Evolution Graph 中。

原因是：

一次失败的修改本身也可能包含有价值的信息。

因此这些节点虽然不能继续作为主要进化路线，却仍然可以在未来被 Retriever 当作 inspiration。

7. Frontier Selection：不是只选择当前分数最高的 Skill

这是论文中另一个比较重要的设计。

最简单的 Evolution Search 会选择当前 \(U(s)\) 最高的 Skill，然后继续修改。

但作者指出，这可能出现一个问题。

假设有两个 branch：

Branch A

当前准确率：

90%

但是最近连续修改很多次：

90% → 90% → 90%

已经完全 stagnate。

Branch B

当前准确率：

85%

但最近的变化是：

75% → 80% → 85%

虽然当前绝对分数更低，但它仍然持续产生更好的后代。

如果只按照当前 Skill Utility：

A 会一直被选中。

但从 Evolution Search 的角度来看：

B 可能更值得继续投入计算资源。

因此作者引入了 Meta-Productivity。

8. Meta-Productivity：衡量“这个改进策略还会不会继续产生好后代”

对于 Meta-Skill \(m\) 和当前 Skill \(s\)，论文定义：

\[P(m\mid s) = \mathbb{E} \left[ \frac{1}{K} \sum_{k=1}^{K} \left( U(s'_k)-U(s) \right) \right] \]

其中：

  • \(s\)：当前 Skill；
  • \(s'_k\)：当前 Meta-Skill 产生的第 \(k\) 个 child；
  • \(K\)：生成的 child 数量。

直观来看：

\(U(s)\) 衡量“我现在有多强”。

而：

\(P(m\mid s)\) 衡量“按照我现在这套自我改进方法继续下去，我还能不能持续产生更强的自己”。

因此两者并不相同。

一个 Skill 可以当前很强，但已经没有继续进步的能力。

另一个 Skill 当前没那么强，却处于一条非常有潜力的上升路线。

MetaSkill-Evolve 同时考虑这两个维度。

9. 第三个因素：Novelty

如果只考虑 Utility 和 Meta-Productivity，系统仍然可能反复选择某几个 branch。

因此作者又加入一个访问次数惩罚：

\[N_v = \frac{1} {1+\mathrm{times\_selected}_v} \]

一个节点被选择得越多：

\(N_v\) 越小。

这样可以防止某一条 branch 长期垄断全部搜索预算。

10. 最终的 Frontier Score

系统最终按照下面的分数选择下一轮 parent：

\[v^* = \arg\max_{v\in F} \left[ \eta_1U_v + \eta_2\hat{P}_v + \eta_3N_v \right] \]

三个部分分别负责：

项 含义 作用
\(U_v\) 当前 Skill Utility exploitation
\(\hat{P}_v\) Meta-Productivity 是否仍有继续进步的潜力
\(N_v\) Novelty 避免一直搜索同一 branch

默认权重为：

参数 默认值
\(\eta_1\) 1.0
\(\eta_2\) 0.5
\(\eta_3\) 0.25

因此 MetaSkill-Evolve 的搜索策略并不是：

永远追着当前最强 Skill 修改。

而是同时寻找：

当前能力不错、还能持续产生提升、而且没有被过度搜索的路线。

11. Fast Loop：Task Skill 如何进化？

接下来进入论文最核心的 Two-Timescale Evolution。

第一层是：

Fast Loop：每轮更新 Task Skill。

一次 Fast Iteration 大致如下。

Step 1：恢复 Branch 状态

首先从 SQLite 中恢复当前 parent 对应的：

  • Task Skill \(s_v\)；
  • Meta-Skill \(m_v\)。

这意味着不同 branch 是完全独立的。

系统不会简单使用磁盘里“最新”的文件，而是：

选中哪个 branch，就恢复哪个 branch 当时的 Task Skill 和 Meta-Skill snapshot。

从而避免不同 lineage 之间发生状态泄漏。

Step 2：寻找最差案例

系统使用当前 Skill 在 training batch 上执行任务。

然后从失败案例中选择：

worst-scoring example

作为本轮主要诊断对象。

作者认为这种方法可以获得较强的 failure signal。

需要注意的是：

虽然修改是由一个最差案例驱动的，但修改后的 Skill 是否真正有效，并不是只看这个案例。

它还必须经过 validation set 的重新评估。

因此单个异常样本造成错误修改的风险，会被 validation evaluation 进一步过滤。

Step 3：运行五 Agent Pipeline

随后依次运行：

Analyzer
→ Retriever
→ Allocator
→ Proposer
→ Evolver

产生 \(K\) 个新的 Task Skill：

\[s'_1,s'_2,\dots,s'_K \]

Step 4：Validation

每一个 child 都在 validation set 上重新评估：

\[\Delta U_k = U(s'_k)-U(s_v) \]

从而判断这次 Skill 修改究竟有没有产生真实提升。

Step 5：保存到 Evolution Graph

每个 child 都会被保存进 DAG。

其中：

  • \(\Delta U>0\)：进入 archive，可以成为未来 parent；
  • \(\Delta U\leq0\)：不进入 archive，但仍然作为历史经验保存。

随后重新执行 Frontier Selection，进入下一轮 Fast Loop。

12. Slow Loop：真正实现 Recursive Self-Improvement 的部分

如果论文到这里结束，那么它仍然只是一个比较完整的 Skill Evolution 框架。

MetaSkill-Evolve 真正关键的地方是第二层：

Slow Loop：Meta-Skill Evolution。

也就是：

不再修改“怎么做任务”，而是修改“怎么修改怎么做任务”。

12.1 为什么 Meta-Skill 不应该每一轮都更新？

Task Skill 可以根据某个失败案例快速修改。

但是 Meta-Skill 不一样。

例如，只因为一次错误就得出：

Analyzer 的整个错误诊断方式都有问题

显然可能过于激进。

Meta-Skill 描述的是一套更加高层、更加稳定的 improvement policy。

如果根据每个单独样本都修改它，很容易受到噪声影响。

因此作者使用两个不同时间尺度：

Task Skill：Fast Timescale
Meta-Skill：Slow Timescale

Meta-Skill 每经过 \(H\) 个 Fast Iteration 才更新一次。

论文默认：

\[H=2 \]

13. Slow Loop 的输入是什么？

Slow Loop 不直接拿某一个任务失败案例作为输入。

它观察的是最近 \(H\) 个后代的整体 evolution history。

例如：

  • 最近遇到了哪些 failure tag；
  • Analyzer 分别做了什么 diagnosis；
  • 提出了哪些修改；
  • 这些修改最终带来了多少 \(\Delta U\)；
  • 最近这套 improvement policy 是否仍然有效。

作者计算最近一段历史中的 empirical meta-productivity：

\[\hat{P} = \frac{1}{|\mathcal{H}|} \sum_{u\in\mathcal{H}} \Delta U_u \]

然后把：

  • tags；
  • diagnoses；
  • outcomes；
  • \(\hat{P}\)

共同整理成一个 synthetic meta-failure trace，记为 \(f_m\)。

可以把它理解成：

系统把最近一段时间“自己是如何学习的、学习效果怎么样”，包装成一个新的失败案例。

这样以后，就能直接复用原来的五 Agent Pipeline。

14. 同一套 Pipeline 开始修改自己

此时非常关键的一步发生了。

Fast Loop 中，五 Agent Pipeline 的目标是：

Task Skill 文件。

Slow Loop 中，完全相同的五 Agent Pipeline 被重新调用。

但是目标变成：

Meta-Skill 文件。

也就是说：

Analyzer
→ Retriever
→ Allocator
→ Proposer
→ Evolver

原本负责修改 Agent 的 Skill。

现在开始修改：

控制 Analyzer、Retriever、Allocator、Proposer、Evolver 自己行为方式的 Skill。

这就是论文定义的 Recursive Self-Improvement。

15. Slow Loop 中五个角色具体在做什么？

假设过去几轮 Skill Evolution 一直没有取得提升。

Slow Loop 首先构造一个 meta-failure trace。

然后：

Analyzer

分析：

为什么最近几轮 Self-Improvement 没有效果？

它会指出最可能有问题的 Meta-Skill component，例如：

Allocator 的 search budget policy 不合理。

或者：

Retriever 找到的 inspiration 质量太差。

Retriever

根据 meta-level failure tag，从其他 branch 中寻找：

有没有其他 lineage 遇到过类似的 Self-Improvement 问题，并且已经找到了解决办法？

因此跨 branch 传播的不再只是：

“这个任务怎么做”。

还可以包括：

“遇到这种情况应该怎样改进自己的学习方式”。

Allocator

决定这一轮 Meta-Skill 修改应该尝试多少轮。

Proposer

针对 Meta-Skill 提出修改方案。

例如：

当连续两轮 \(\Delta U\approx0\) 时，不应该继续保持 \(K=1\)，而应扩大候选 Skill 数量。

Evolver

真正修改对应的 Meta-Skill 文件。

16. 一个容易误解的地方：Slow Loop 实际会联合修改五个 Meta-Skill

论文这里还有一个值得注意的细节。

Analyzer 会判断：

哪一个 component 最可能是主要问题。

但这个判断主要用于确定：

  • failure tag；
  • retrieval direction。

它并不意味着：

最后只修改这一个 Meta-Skill 文件。

作者采用的是 Whole-\(m\) Rewrite。

也就是说一次 Meta Update 中，会考虑：

\[\{\psi,\sigma,\alpha,\pi,\varepsilon\} \]

五个 Meta-Skill 的联合修改。

原因是五个组件彼此依赖。

例如：

Analyzer \(\psi\) 生成了一套更加细粒度的 failure tag。

那么 Retriever \(\sigma\) 也可能必须同步学习：

应该如何根据新的 tag vocabulary 进行检索。

如果只修改 Analyzer，不修改 Retriever，整个 Pipeline 反而可能产生不一致。

因此 Slow Loop 强调：

Meta-Skill 的修改需要保持 cross-component coherence。

17. Accumulating Children：Meta 更新不是相互独立的

Fast Loop 中如果生成多个 child，通常每个 child 都从同一个 parent 出发。

Slow Loop 则有所不同。

假设 Meta-Skill 这一轮允许生成 \(K_m\) 次修改。

论文采用：

Child 1 修改 Parent
Child 2 在 Child 1 的基础上继续修改
Child 3 再在 Child 2 的基础上继续修改

而不是：

Parent → Child 1
Parent → Child 2
Parent → Child 3

作者将其称为 Accumulating Children。

目的在于让 Meta-Skill 进行连续的渐进式 refinement，而不是生成几个互不相关的独立版本。

18. 两个时间尺度放在一起看

到这里可以把整个系统压缩成两个循环。

Fast Loop

优化：

Task Skill \(s\)

问题：

我应该怎样更好地完成任务？

运行频率：

每轮执行。

输入：

当前任务失败案例。

输出：

新的 Task Skill。

Slow Loop

优化：

Meta-Skill \(m\)

问题：

我应该怎样更好地改进 Task Skill？

运行频率：

每隔 \(H\) 个 Fast Iteration 执行一次。

输入：

最近一段 Skill Evolution History。

输出：

新的 Meta-Skill。

二者形成：

Task Skill 改进任务行为
↓
Meta-Skill 观察 Task Skill 的改进过程
↓
Meta-Skill 改进“Task Skill 的改进方法”
↓
新的 Meta-Skill 又指导之后的 Task Skill Evolution

因此论文把它称为：

Two-Timescale Meta-Skill Evolution

19. 这是不是无限递归？

不是。

论文对此限定得很明确。

MetaSkill-Evolve 实现的是一种：

bounded, one-level recursion

也就是只多递归一层：

Task Skill
← Meta-Skill

虽然 Meta-Skill 会被同一套 Pipeline 修改，但：

整个五 Agent Pipeline 的角色和 wiring 本身仍然是固定的。

系统并不会进一步出现：

Meta-Meta-Skill
→ 修改 Meta-Skill 的修改方式
→ 再出现 Meta-Meta-Meta-Skill……

所以这并不是理论上无限展开的 Recursive Self-Improvement。

它是在现有 Agent Skill 系统中实现的一种有限、工程可执行的 RSI 形式。

20. 实验设置

作者在三个 Agent Benchmark 上进行测试：

Benchmark 主要测试能力
OfficeQA 企业文档、表格和多步 grounded reasoning
SealQA Search-Augmented QA 与复杂推理
ALFWorld 文本环境中的长程交互与具身任务

三个 Benchmark 被分为互不重叠的：

  • Train；
  • Validation；
  • Test。

其中：

Train

用于：

failure mining

也就是寻找错误案例，驱动 Skill Evolution。

Validation

用于：

  • Child Skill 评估；
  • \(\Delta U\) 计算；
  • Frontier Selection；
  • Best Skill Selection。

Test

Evolution Loop 完全看不到。

最终论文报告的是：

Held-Out Test Accuracy。

因此测试结果衡量的是 evolved Skill 对未见样本的泛化能力，而不是对参与进化样本的记忆。

21. Backbone：整个过程没有训练模型参数

所有五个 Pipeline Agent：

  • Analyzer；
  • Retriever；
  • Allocator；
  • Proposer；
  • Evolver；

都共享同一个冻结的：

Gemma-4 31B

作为 backbone。

论文没有对这些 Agent 进行 fine-tuning。

因此整个 Self-Improvement 的变化发生在：

Task Skill + Meta-Skill

这些外部 Markdown 工件上，而不是模型参数中。

这是一种 training-free Self-Improvement。

22. Baseline

论文比较四种配置。

22.1 No-Skill

只有原始 backbone。

不加载 Skill，也不开启 Reflection。

用于测量模型本身的能力。

22.2 Static Skill

加载作者人工编写的初始 Skill。

但整个实验中 Skill 完全不更新。

用于测试：

“拥有 Skill”本身能带来多少提升。

22.3 Single-Level Evolution

只开启 Fast Loop。

也就是：

Task Skill 会进化，但 Meta-Skill 不会进化。

论文在实验配置中还将该 baseline 设置为：

  • \(K_{\max}=1\)；
  • 不使用 cross-branch sharing；
  • 不进行 Meta-Skill 更新。

因此它代表作者实现中的单层 Skill Evolution 配置。

22.4 MetaSkill-Evolve

完整方法：

Task Skill Fast Evolution

  • Meta-Skill Slow Evolution
  • adaptive allocation
  • cross-branch sharing
  • Meta-aware Frontier Selection

23. 主实验结果

论文的主要结果如下：

Method OfficeQA SealQA ALFWorld
No-Skill 31.78 29.17 92.31
Static Skill 36.09 29.41 90.38
Single-Level Evolution 48.94 37.21 92.31
MetaSkill-Evolve 55.32 45.26 94.23
相比 No-Skill +23.54 +16.09 +1.92

OfficeQA 和 SealQA 上的趋势非常清晰：

No-Skill
→ Static Skill
→ Single-Level Evolution
→ MetaSkill-Evolve

性能逐步上升。

24. OfficeQA

OfficeQA 上：

  • No-Skill：31.78
  • Static Skill：36.09
  • Single-Level：48.94
  • MetaSkill-Evolve：55.32

从 No-Skill 到最终系统：

+23.54 points

Static Skill 本身带来了约：

+4.31

之后让 Skill 自我进化又进一步提升。

最终完整 MetaSkill-Evolve 相比 Single-Level：

+6.38 points

说明在作者的完整实验配置下，引入 Meta-Level Adaptation 后仍然能够继续改善系统。

25. SealQA

SealQA 上：

  • No-Skill：29.17
  • Static Skill：29.41
  • Single-Level：37.21
  • MetaSkill-Evolve：45.26

最终相比 No-Skill：

+16.09 points

相比 Single-Level：

+8.05 points

这里 Static Skill 几乎没有带来提升。

但：

Skill Evolution

和：

Meta-Skill Evolution

分别进一步提高了性能。

26. ALFWorld

ALFWorld 情况比较特殊。

原始模型已经达到：

92.31%

因此 benchmark 存在明显 ceiling effect。

结果为：

  • No-Skill：92.31
  • Static Skill：90.38
  • Single-Level：92.31
  • MetaSkill-Evolve：94.23

Static Skill 甚至下降了：

-1.93 points

Single-Level 只恢复到原始 backbone 水平。

而 MetaSkill-Evolve 最终达到：

94.23%

提升：

+1.92 points

由于 backbone 在这个 Benchmark 上本来就已经很强，所以总体提升空间明显小于两个 QA Benchmark。

27. Component Ablation

作者进一步分别移除不同 Meta-Skill Component。

结果如下：

Configuration OfficeQA SealQA ALFWorld
Full MetaSkill-Evolve 55.32 45.26 94.23
\(-\psi\)：关闭 Analyzer policy 39.09 39.63 88.46
\(-\sigma\)：关闭 inspiration retrieval 39.09 40.54 88.46
\(-\alpha\)：固定 \(K=2\) 35.58 40.54 88.46
\(-\pi\)：关闭 structured proposal 37.59 36.84 86.54
No cross-branch retrieval 39.84 41.44 92.31
No meta-updates 48.94 37.21 92.31

不同任务依赖的 Meta-Skill 并不完全一样。

28. OfficeQA：Allocator 最重要

OfficeQA 中：

完整模型：

55.32

移除 \(\alpha\) 之后：

35.58

下降约：

19.7 points

是所有组件中最大的下降。

作者认为 OfficeQA 中存在一些成片出现的、相互相关的错误，例如算术类问题。

当系统在某个方向上停滞时：

Allocator 能够扩大 \(K\)

让系统同时尝试更多不同 Skill 修改。

因此 adaptive search budget 在 OfficeQA 上非常重要。

Proposer \(\pi\) 同样影响明显。

移除以后：

55.32 → 37.59

29. SealQA：Proposer 最重要

SealQA 中影响最大的组件变成：

\(\pi\)

完整系统：

45.26

移除 Proposer Policy：

36.84

下降：

8.42 points

作者认为 SealQA 更依赖：

每一次 Skill 修改内容本身是否足够准确。

因此相比“搜索多少个方案”，SealQA 更依赖：

“具体应该改什么”。

这说明不同任务可能需要不同类型的 Self-Improvement Policy。

30. ALFWorld：Proposer 与 Cross-Branch Sharing

ALFWorld 中：

完整系统：

94.23

移除 \(\pi\) 后：

86.54

同样说明 edit proposal 的质量非常重要。

另外，当只关闭 cross-branch retrieval 时：

94.23 → 92.31

刚好退回 Single-Level baseline。

作者因此认为，ALFWorld 上最终的 +1.92 提升主要依赖：

不同 branch 之间迁移可复用的子策略。

例如：

  • object disambiguation；
  • deferred placement 等。

31. Meta-Update Horizon：Meta-Skill 应该多久改一次？

参数 \(H\) 控制：

每进行多少次 Fast Task-Skill Evolution，执行一次 Slow Meta-Skill Evolution。

作者测试：

\[H\in\{2,4,8\} \]

为了控制 Meta Update 次数，三个配置都执行 3 次 Meta Update，因此 Fast Iteration 总数分别为：

  • \(H=2\)：6 次；
  • \(H=4\)：12 次；
  • \(H=8\)：24 次。

结果：

Benchmark \(H=2\) \(H=4\) \(H=8\)
OfficeQA 48.94 41.35 39.84
SealQA 44.14 44.14 43.24
ALFWorld 90.38 90.38 88.46

总体上：

\(H=2\) 最稳定。

32. 为什么 Meta-Skill 不能更新得太慢？

作者认为：

Task Skill 本身一直在快速变化。

如果 Meta-Skill 很久才更新一次，那么它学到的 improvement policy 可能已经对应的是几轮之前的 Task Skill 状态。

此时就会出现：

Meta-Skill 已经过时。

论文称之为 stale meta-skill。

尤其 OfficeQA 对这个问题非常敏感：

48.94 → 41.35 → 39.84

从 \(H=2\) 增大到 \(H=8\)，下降约：

9.1 points。

33. 但为什么又不能每一轮都更新？

另一方面，如果 Meta-Skill 每一轮都根据一个失败案例更新：

又会过度受到单个样本噪声影响。

因此论文使用 Two-Timescale 的核心原因就是平衡：

响应速度和稳定性。

Task Skill 应该快速适应具体错误。

Meta-Skill 则应该观察一段时间后，再根据整体 Self-Improvement 表现做更稳定的修改。

论文最终默认：

\[H=2 \]

34. 其他主要超参数

论文默认设置还包括：

参数 默认值
Frontier Utility Weight \(\eta_1\) 1.0
Productivity Weight \(\eta_2\) 0.5
Novelty Weight \(\eta_3\) 0.25
Meta Update Horizon \(H\) 2
Fast Iteration Budget 5
\(K_{\max}\) 3
Initial \(K\) 2
Frontier Size \(K_F\) 3
Cross-Branch Retrieval Probability 0.2
Same-Branch Inspiration Limit 3
Cross-Branch Inspiration Limit 2

作者还发现：

适量 cross-branch retrieval 有帮助，但太强的 cross-branch retrieval 会引入噪声。

原因是不同 branch 可能正在处理结构完全不同的失败。

此时强行迁移经验，反而可能给 Proposer 提供无关的 inspiration。

35. Train / Validation Split 的补充实验

论文附录还研究了训练集和验证集比例的影响。

当 Validation 固定为 0.10 时：

Benchmark train=0.05 train=0.10 train=0.15
SealQA 45.98 43.68 48.28
OfficeQA 44.86 42.99 48.25
ALFWorld 87.74 88.68 90.57

增加 Training Data 对 OfficeQA 和 SealQA 的影响并不特别明显。

但 ALFWorld 随着 Training Ratio 增加有更稳定的增长。

36. 高基线任务尤其需要足够多的 Validation Failure

作者还在 ALFWorld 上调整 validation ratio：

Train Ratio val=0.10 val=0.25
0.05 87.74 89.69
0.10 88.68 92.96
0.15 90.57 93.02

可以看到，增加 Validation Set 明显提升 ALFWorld 的最终效果。

作者给出的解释是：

ALFWorld 的 backbone 已经能够解决绝大多数任务。

如果 Validation Set 太小：

其中甚至可能没有足够多的失败案例。

那么：

Analyzer 看不到 failure
→ Proposer 没有什么可以修改
→ Frontier Selection 没有有效信号
→ Slow Loop 也几乎变成 no-op

因此 Self-Improvement 系统本身存在一个很基础的前提：

必须能够持续观察到足够有信息量的失败。

如果任务已经高度饱和，Failure Signal 太少，Evolution Loop 就没有东西可以学习。

37. MetaSkill-Evolve 的核心贡献可以怎样概括？

回到整篇论文，作者主要提出了四个方面。

37.1 Two-Timescale Evolution

作者把 Self-Improvement 分成两个时间尺度：

Fast Loop：优化 Task Skill
Slow Loop：优化 Meta-Skill

让：

“完成任务”

和：

“学习如何改进任务能力”

成为两个独立但互相作用的优化过程。

37.2 五阶段 Skill Evolution Pipeline

作者把 Skill Evolution 明确拆成：

Analyzer
→ Retriever
→ Allocator
→ Proposer
→ Evolver

相比简单的：

Analyze → Propose → Evolve

额外显式加入：

  • Cross-Branch Retrieval；
  • Adaptive Search Allocation。

37.3 把 Improvement Procedure 本身表示成 Skill

这是论文最核心的思想。

作者没有把 Self-Improvement Policy 固定在代码中，而是将其表示为：

\[m=(\psi,\sigma,\alpha,\pi,\varepsilon) \]

五份可被 LLM 修改的 Skill 文件。

由于 Task Skill 和 Meta-Skill 使用同一种 Markdown 表示：

原来用于修改 Skill 的 Pipeline，也可以直接用于修改 Meta-Skill。

于是实现了一个 bounded Recursive Self-Improvement Loop。

37.4 Meta-Aware Frontier Selection

传统进化搜索主要关注：

当前哪个 Skill 最强。

MetaSkill-Evolve 进一步考虑：

哪条 branch 仍然具有较强的“继续自我改进能力”。

因此 Frontier Selection 综合：

  • Utility；
  • Meta-Productivity；
  • Novelty。

从而避免搜索长期停留在一个当前分数高、但已经完全 stagnate 的 branch 上。

38. 这篇论文中的 Recursive Self-Improvement 到底“递归”在哪里？

这一点可以单独再总结一次。

普通 Skill Evolution 是：

Agent
→ 根据固定 Improvement Policy
→ 修改 Task Skill

也就是：

改结果，不改改结果的方法。

MetaSkill-Evolve 则是：

Improvement Pipeline
→ 修改 Task Skill

同时：

Improvement Pipeline
→ 修改控制 Improvement Pipeline 自己行为的 Meta-Skill

所以它出现了一次：

Improvement Operator applied to itself

这就是论文所谓 Recursive 的来源。

但必须注意：

它递归修改的是五个角色的 Skill / Policy 文件。

而：

  • 五个 Agent 的角色定义；
  • Pipeline 顺序；
  • Analyzer → Retriever → Allocator → Proposer → Evolver 的 wiring；
  • 整个系统框架；

仍然由研究者固定。

所以这是一种：

受约束的、一层的 Recursive Self-Improvement

而不是系统能够任意重新设计自身架构。

39. 局限性

作者在论文结尾明确列出三个主要限制。

39.1 只在三个 Benchmark 上验证

目前实验集中于：

  • OfficeQA；
  • SealQA；
  • ALFWorld。

这些都属于相对受控的 Benchmark。

论文尚未验证：

在更加开放、长程、反馈更加嘈杂的真实世界 Agent 任务中，这套方法是否仍然有效。

39.2 五 Agent Pipeline 本身仍然是固定的

虽然：

Task Skill 会进化；

并且：

Meta-Skill 也会进化；

但是整个系统最外层的结构：

Analyzer
→ Retriever
→ Allocator
→ Proposer
→ Evolver

并不会变化。

作者明确指出：

系统会进化五个 Agent 使用的 Skill，但不会进化它们的 role 和 wiring。

因此 MetaSkill-Evolve 并没有让 Agent 完全重新设计自己的 Self-Improvement Architecture。

39.3 Meta Update Horizon 仍然固定

目前 \(H\) 是研究者预先设定的超参数。

例如默认：

\[H=2 \]

系统本身并不会动态判断：

“现在应该更新 Meta-Skill 了。”

因此 Two-Timescale 的调度规则本身仍然属于固定框架的一部分。

论文没有进一步让这一调度机制自适应进化。

40. 总结

MetaSkill-Evolve 关注的问题并不是：

如何再设计一种新的 Task Skill。

它关注的是更高一层的问题：

如果 Agent 已经可以根据失败修改自己的 Skill，那么负责“修改 Skill”的那套方法为什么必须永远由人固定？

传统 Skill Self-Improvement 可以写成：

执行任务
→ 观察失败
→ 固定 Improvement Pipeline
→ 修改 Task Skill
→ 得到更好的 Task Skill

MetaSkill-Evolve 则进一步变成：

执行任务
→ Fast Loop 修改 Task Skill
→ 观察最近几轮 Skill Evolution 是否有效
→ Slow Loop 修改 Meta-Skill
→ 新的 Meta-Skill 再改变之后的 Skill Evolution

其中每个 branch 同时维护：

\[b=(s,m,h) \]

Task Skill \(s\) 负责：

what to do

Meta-Skill \(m\) 负责：

how to improve

Evolution History \(h\) 则让系统能够观察：

当前这套 Self-Improvement 方法究竟有没有持续产生更好的后代。

最终，作者在 OfficeQA、SealQA 和 ALFWorld 上分别得到：

+23.54 / +16.09 / +1.92

相对于 No-Skill backbone 的提升。

整篇论文最核心的设计可以浓缩成一句话：

不要只让 Agent 学会修改自己的 Skill，还要把“如何修改 Skill”本身也做成 Skill，再让同一套 Self-Improvement Pipeline 去修改它。

这使得 Agent 的 Self-Improvement 从：

固定方法下的 Skill Evolution

向：

Improvement Policy 本身也参与 Evolution

进一步推进了一层。

参考

  1. Zefeng Wang, Minxi Yan, Jinhe Bi, Sikuan Yan, Volker Tresp, Yunpu Ma. MetaSkill-Evolve: Recursive Self-Improvement of LLM Agents via Two-Timescale Meta-Skill Evolution. arXiv:2607.05297, 2026.
    https://arxiv.org/abs/2607.05297

  2. Salaheddin Alzubi et al. EvoSkill: Automated Skill Discovery for Multi-Agent Systems. arXiv:2603.02766, 2026.
    https://arxiv.org/abs/2603.02766

  3. Boyuan Zheng et al. SkillWeaver: Web Agents Can Self-Improve by Discovering and Honing Skills. arXiv:2504.07079, 2025.
    https://arxiv.org/abs/2504.07079

  4. Chrisantha Fernando et al. Promptbreeder: Self-Referential Self-Improvement via Prompt Evolution. arXiv:2309.16797, 2023.
    https://arxiv.org/abs/2309.16797

  5. Eric Zelikman et al. Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation. arXiv:2310.02304, 2024.
    https://arxiv.org/abs/2310.02304

  6. Jenny Zhang et al. Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents. arXiv:2505.22954, 2026.
    https://arxiv.org/abs/2505.22954

posted @ 2026-10-27 16:26  YourF4u1t  阅读(11)  评论(0)    收藏  举报