MetaSkill-Evolve：Agent 开始学习如何学习，递归自我改进离现实还有多远？ --- 这篇不热门的论文，可能是这个月除了nvda很火的那篇论文Red Queen Gödel Machine之外，最有意思的一篇 最近，LMU Munich、MCML、香港中文大学联合发布了论文 MetaSkill-Evolve: Recursive Self-Improvement of LLM Agents via Two-Timescale Meta-Skill Evolution。 这篇论文提出了一个新的问题： Agent 不仅应该学习如何完成任务（Skill），改进skill，还应该学习如何不断增强改进自己的 Skill的能力（Meta-Skill）。 这意味着，Agent 的优化对象第一次从「怎么做好」扩展到了「如何提升不断做好的能力」。 一、从 Skill Evolution 到 Meta-Skill Evolution 近半年来，Self-Improving Agent 已经成为热点。 无论是 Reflexion、SkillWeaver、GEPA，还是 EvoSkill，本质都遵循类似流程： 执行任务 ↓ 失败分析 ↓ 修改 Skill ↓ 重新执行 Skill 在不断进化，但整个改进流程却始终保持不变。 例如： 如何分析失败？ 如何寻找历史经验？ 一次生成几个修改方案？ 如何真正修改 Skill？ 这些流程几乎都是人工设计的。 MetaSkill-Evolve 认为，这才是真正限制 Agent 长期能力增长的地方。 论文提出，既然 Skill 可以不断演化，那么 Skill 的演化机制为什么不能继续演化？ 二、Meta Skill 到底是什么？ 论文把整个 Skill Evolution Pipeline 拆成五个可独立进化的模块： Analyzer（ψ）：分析失败原因。 Retriever（σ）：寻找历史经验。 Allocator（α）：决定搜索预算，生成多少 Candidate。 Proposer（π）：提出具体修改方案。 Evolver（ε）：真正修改 Skill 文件。 传统方法固定这五个模块，而 MetaSkill-Evolve 将它们本身也表示成 Markdown Skill 文件，与普通 Skill 使用完全相同的形式，因此同样能够被 Agent 修改。 于是系统形成两层循环： Fast Loop Task ↓ Skill Evolution 负责持续优化 Task Skill。 Slow Loop Meta Skill Evolution ↓ 修改 Fast Loop 的工作方式 负责持续优化整个 Skill Evolution Pipeline。 论文称之为 Two-Timescale Evolution。 这其实是在增加推理算力，而不是增加模型参数 这篇论文还有一个值得注意的特点： 整个系统始终使用同一个冻结的 Gemma-4 31B。 没有训练，没有微调，没有新增模型。 所有性能提升都来自： 更多 Agent 调用 更多推理 Token 更多搜索 更多 Skill Evolution 因此它属于典型的 Inference-Time Scaling。 换句话说： 不是让模型变大，而是让推理越来越复杂。 这一趋势与 AlphaEvolve、Deep Research、Darwin Gödel Machine、Red Queen Gödel Machine 等近期工作高度一致。 未来 Agent 能力的提升，很可能越来越依赖推理时计算，而不是继续增加模型参数。 三、Reflection 与 MetaSkill 的区别 很多人会把它理解成 Reflection 的升级版。 其实两者并不一样。 Reflection： 执行 ↓ Reflection ↓ 重新执行 Token 消耗大致随 Reflection 次数线性增长。 如果 Reflection N 次： Cost ≈ O(N) MetaSkill-Evolve 不只是增加 Reflection，而是增加了多个新的计算维度。 一次 Skill Evolution 包括： Analyzer Retriever Allocator Proposer Evolver 随后 Allocator 还可能生成多个 Candidate，每个 Candidate 都需要重新执行 Benchmark。 每隔 H 次，还要再运行一次 Meta Loop，对整个 Evolution Pipeline 本身进行分析与修改。 因此： Task Compute + Skill Evolution Compute + Meta Evolution Compute + Retrieval Compute 都成为推理成本的一部分。 本质上，这就是一种 Loop of Loop。 Token 会指数增长吗？ 直觉上似乎会。 因为每次 Evolution 都可能生成多个 Child： Skill0 ├──Skill1 ├──Skill2 └──Skill3 如果每个 Child 再生成三个： 3 ↓ 9 ↓ 27 ↓ 81 理论复杂度就是： O(K^Depth) 即指数增长。 但论文并没有允许搜索树无限扩张。 原因就在于它的另一个核心设计： Frontier Search。 四、Frontier Search：把指数搜索压回可计算范围 Frontier Selection 是整篇论文最重要的工程设计之一。 它的思想非常简单： 永远只扩展最值得继续探索的少数几个 Branch。 论文将所有 Skill 全部保存到 SQLite DAG 中。 例如： Skill0 ├──Skill1 │ ├──Skill4 │ └──Skill5 ├──Skill2 │ ├──Skill6 │ └──Skill7 └──Skill3 整个 DAG 会越来越大。 但是： 真正继续扩展的，永远只有 Frontier。 论文默认： Frontier Size = 3 也就是说： 无论 DAG 有几十个节点，还是几百个节点，同时继续演化的 Branch 始终只有三个。 Frontier 怎么选？ 论文采用三个指标共同评分： Utility 当前 Skill 有多好。 例如当前 Accuracy。 Meta Productivity 论文最大的创新。 它不是看今天最好，而是看： 这个 Branch 是否仍然持续产生越来越好的后代。 例如： Branch A： 80 ↓ 81 ↓ 82 ↓ 83 持续成长。 Branch B： 95 ↓ 95 ↓ 95 虽然分数高，但已经停止进化。 论文认为，应继续投入计算资源给 Branch A。 Novelty 防止计算资源全部集中到同一条 Branch。 已经被大量扩展的 Branch，会降低分数。 最终评分： Score = Utility + Meta Productivity + Novelty 然后选择 Top-K 作为新的 Frontier。 因此，Frontier 实际上把原本可能指数增长的搜索控制在近似线性的计算预算内。 为什么整个 DAG 还要保存？ 虽然 Frontier 只扩展少量节点，但整个 DAG 不会删除。 原因是 Retriever。 例如： 当前 Branch 遇到： Table Parsing Error Retriever 可以在整个 DAG 中寻找： 过去有没有 Branch 解决过类似问题？ 即使那个 Branch 很久以前已经退出 Frontier，其经验依然能够被复用。 这就是论文强调的 Cross-Branch Retrieval。 搜索停止了。 经验没有停止。 实验效果如何？ 论文全部实验都基于同一个冻结的 Gemma-4 31B。 五、最终结果： Benchmark相比原始模型提升OfficeQA+23.54SealQA+16.09ALFWorld+1.92 相比普通 Skill Evolution： Meta Skill 又额外带来： OfficeQA：+6.38 SealQA：+8.05 ALFWorld：+1.92 论文还进行了完整的消融实验。 结果发现： OfficeQA 最重要的是 Allocator。 SealQA 最重要的是 Proposer。 ALFWorld 则主要依赖 Cross-Branch Retrieval。 说明不同任务真正决定性能的 Meta Skill 并不相同。 六、个人观点 这篇论文真正重要的地方不是性能提升了多少，而是提出了一种新的 Agent 演化范式。 过去： Model ↓ Answer 后来： Model ↓ Reflection ↓ Answer 现在开始变成： Model ↓ Skill ↓ Meta Skill ↓ Frontier Search ↓ Retriever ↓ Verifier ↓ Answer 模型没有变。 推理越来越复杂。 未来 Agent 的能力，很可能越来越依赖 Inference-Time Scaling，而不是继续依赖更大的参数规模。 如果把 最近nvda很火的那篇论文Red Queen Gödel Machine 与 MetaSkill-Evolve 放在一起看，可以看到一个共同趋势： Agent 正在逐渐从「一次推理」演化为「持续进化」。 真正决定能力上限的，不再只是模型本身，而是模型能够调度多少计算资源，在多大的搜索空间里持续寻找更好的自己。(rick awsb ($people, $people))