Agent 与 Skill 的迭代自进化

摘要

「agent 和 skill 如何迭代自进化」在 2026 年从论文话题变成了工程赛道。我们记录五个事实：

1. (1) 所有自进化系统共享同一个闭环：执行 → 评估 → 反思/变异 → 验证 → 沉淀或回滚。Evolutionary Context（ACE）、达尔文.skill、Hermes Self-Evolution 的文档用不同词汇描述同一个循环。[E04,E08,E11]
2. (2) 赛道分化为三条路径：离线优化器（SkillOpt、GEPA、DSPy——人在环外，优化产物是文本）、skill 生命周期治理（skill-up、SkillEvaluator、better-harness——人审批，产物是版本）、在线自进化（Hermes、Ouroboros、ECC——agent 在环内，人是守门人）。[E02,E05,E08]
3. (3) 巨头全部进场：Microsoft 交出 SkillOpt（5 个月 17.9k star），阿里有 skill-up，NVIDIA 有 SkillEvaluator，火山引擎有 OpenViking（39k）——「skill 怎么变好」被当成平台级能力建。[E02,E05,E06,E12]
4. (4) DSPy + GEPA 成为在线自进化的发动机：Hermes Self-Evolution 明确以「DSPy + GEPA」为优化内核——离线优化器正在被在线系统当作子程序调用。[E03,E08]
5. (5) 自进化的争议收敛为「门控」：纯粹的放开自改没有赢家，Ouroboros 的「面谈门控、分阶段放权」与 darwin-skill 的「保留或回滚」都把人放在回路里——2026 年的共识是进化自由 + 审批纪律。[E04,E09]

14 个项目的逐个对比见第 2 章；演化闭环的五个环节见第 3 章；选型建议见第 4 章。

1 自进化的三种路径

「自进化」这个词被用在四种不同的东西上：优化 prompt 的、治理 skill 的、agent 自己改自己的、沉淀记忆的。分清路径是选型的前提。

为什么 2026 年突然扎堆：三个条件同时成熟——skill 文件格式被 Claude Code 统一（有「被优化的对象」）、GEPA 证明反射式优化比强化学习便宜几个数量级（有「优化器」）、eval 框架就位（有「质量门」）。三者齐了，闭环才能转起来。[E03,E17]

2 Top 12+2 全景

选样 14 个（12 个核心 + 记忆侧 2 个对照），覆盖三条路径。ECC 的 269k star 远超其他项目，为不压扁其余条目，条形图不含 ECC 与 Letta，见注。

2.1 重点项目

2.2 其余项目速览

star 数为 2026-09-29 GitHub API 实测读数 [E01–E14]；创建时间为仓库创建年月。AgentCompass 等论文项目未入样。

3 演化闭环：五个环节，各有人管

把 14 个项目的能力拆到闭环的五个环节上，谁强在哪一目了然：

机制上为什么闭环难建全：五个环节的优化目标互相冲突——评估要严格（慢、贵），变异要多样（快、杂），验证要保守（慢），沉淀要激进（多存）。一个系统把五层都做到 80 分，等于同时做 eval 平台、优化器和数据库。这就是为什么 14 个项目里没有一个覆盖全环，跨项目组合才是常态。[E18]

4 怎么选怎么用

4.1 三个工程纪律

1. skill 仓库必须 git 化，进化必须走 PR。无论用哪个工具，「保留或回滚」的物理载体是版本控制；没有回滚能力的自进化在第一次 reward hacking 后就会污染整个 skill 库。[E04,E09]
2. 进化用的 eval 集和线上任务要定期对齐。离线优化器最大的坑是「在旧任务分布上越优化越偏」；SkillOpt 训练出的 skill 上线前要在真实任务样本上复验。[E02]
3. 记忆沉淀 ≠ skill 进化，别混。Letta/MemOS 让 agent「下次更好」，但不产生可审查、可分发的 skill 资产；两条腿都要有，缺 skill 治理的团队会发现经验全锁在某个人的记忆库里。[E13,E14]

5 方法、数据来源与局限性

5.1 方法

选样。14 个项目：用户提供 6 个起点（SkillEvaluator、better-harness、alibaba/skill-up、Hermes Self-Evolution、SkillOpt、DSPy+GEPA），经 GitHub Topic/关键词检索补充 8 个（darwin-skill、Ouroboros、ECC、ACE、OpenViking、MemOS、Letta、及作为 DSPy 内核的 GEPA 单列）。纳入标准：GitHub 可检索、2026 年仍活跃、与「agent/skill 迭代自进化」直接相关。排除纯 prompt 模板库与纯 RAG 项目。

事实采集。star 数以 2026-09-29 GitHub API 实测读数为准；项目描述与机制说明以各仓库 README 为准逐条核对。14 条数据点均标注 [E01–E14]。

路径划分与象限定位。三条路径与 Figure 2.2 象限是定性判断（依据 README 机制描述），用于看格局。

5.2 局限性与替代解释

star 数不等于采用质量。ECC 5 个月 269k star 的增速远超同类工具项目，我们的解释是「覆盖 Claude Code/Codex/OpenCode/Cursor 多 harness 的工具集合 + 社区病毒式传播」；替代解释是存在刷 star 或空转 fork 的可能——无法从公开数据排除，读者使用前建议自行查验 issue 活跃度与提交质量。[E10]

「闭环」为模式归纳。五环节闭环是从 14 个项目的 README 归纳的公共模式，不是任何官方标准的定义；个别项目（如 ACE）用「delta 更新」而非「版本回滚」处理验证环节，映射有近似。

赛道早期，结论保质期短。样本中 10 个仓库创建于 2026 年内，最老的核心项目 DSPy 也有大量破坏性迭代。本报告数据截至 2026-09-29，三个月后的格局可能显著不同。

样本偏差。偏 GitHub 开源与英文/中文社区可见的项目；闭源平台（OpenAI/Anthropic 内部的 skill 优化管线、商用 agent 平台的记忆产品）不在样本内，其做法可能领先开源可见状态。

数据速查表

14 个项目关键属性一页汇总。

star 为 2026-09-29 GitHub API 实测 [E01–E14]；创建时间为仓库创建年月。