Agent Skill Evolution 正在成为一个非常重要的方向。
最近几篇论文和项目，几乎都在围绕同一个问题展开：
Trace2Skill 试图从 Agent 执行轨迹中提炼可迁移 Skill，对应代码库是 Qwen-Applications/Trace2Skill。
EvoSkill 关注自动发现、生成和修改 Skill，对应代码库是 sentient-agi/EvoSkill。
SkillOpt 更进一步，把 Skill 当成 frozen agent 的外部可训练状态，并通过验证门禁避免 Skill 越改越笨，对应代码库是 microsoft/SkillOpt，项目页是 microsoft.github.io/SkillOpt。
SkillClaw 讨论多用户、多 Agent 的集体 Skill Evolution，对应代码库是 AMAP-ML/SkillClaw。
WildClawBench 提供真实长链路 Agent 任务评测，对应代码库是 InternLM/WildClawBench，排行榜页面是 internlm.github.io/WildClawBench。
Memento-Skills 则提出 Let Agents Design Agents，让 Agent 通过 Skill Memory 自我设计和持续改进，对应代码库是 Memento-Teams/Memento-Skills，项目页是 skills.memento.run。
这些项目表面上都在讲 Skill Evolution，但真正共同指向的是一个更大的问题：
Agent 不只要会执行任务，还要能把执行经验沉淀成可验证、可回滚、可共享的能力资产。
但这里有一个更危险的问题：
如果 Agent 不断总结经验、不断改写 Skill，它真的会越来越聪明吗？
不一定。
甚至在很多情况下，它会越进化越笨。
不是因为 Skill Evolution 这个方向错了，而是因为很多所谓的“进化”，本质上只是把未经验证的局部经验，不断写进系统上下文。
这不是学习。
这是污染。
一、Skill 为什么会变笨？
Skill 的本质，不是普通提示词。
提示词影响一次对话，Skill 会影响之后很多次执行。
一个错误提示词，最多让一次回答变差。
一个错误 Skill，会持续污染 Agent 的行为策略。
所以 Skill 一旦进入系统，它就不再是文本，而是 Agent 的行为资产。
它会影响：
- Agent 如何理解任务；
- Agent 如何选择工具；
- Agent 如何拆解步骤；
- Agent 如何处理异常；
- Agent 如何判断是否继续执行；
- Agent 如何在不确定时恢复。
正因为如此，Skill 的进化不能像普通 prompt 那样随便改。
很多 Agent 系统最大的问题是：
每次失败都总结一条经验，每次总结都写进 Skill，每次写入都默认是进步。
但真实情况不是这样。
一次失败可能来自很多原因：
- 输入样本特殊；
- 工具调用失败；
- 文件没有读全；
- API 返回异常；
- evaluator 判断不稳定；
- 模型随机性；
- 上下文被截断；
- 任务本身表述不清；
- 当前环境和未来环境不同。
如果系统把这些局部失败直接写成通用规则，Skill 就会开始过拟合。
它不是学到了规律，而是记住了事故。
久而久之，Skill Library 会变成一个事故备忘录：
上次这里错了，加一条规则。 上次那里错了，再加一条规则。 上次某个工具失败了，再写一条禁止条件。 上次某个任务绕过去了，再补一个例外说明。
最后 Skill 越来越长，规则越来越碎，触发越来越乱。
Agent 不是不会做事，而是不知道该听哪条规则。
二、第一种退化：把局部经验当成全局规律
Trace2Skill 的问题定义非常关键。
它指出，自动生成 Skill 很容易产生脆弱或碎片化的结果，一个重要原因是系统可能顺序地过拟合到不可泛化的 trajectory-local lessons。
换成产品语言，就是：
单条轨迹里的教训，不等于可复用 Skill。
例如，一个 Agent 在处理表格任务时失败了。失败原因可能是它没有先检查列名。于是系统总结出一条 Skill：
以后处理表格前，必须先检查所有列名。
这条规则看似合理。
但如果之后的任务是大规模文件处理、列名很多、目标只涉及少数区域，强制检查所有列名反而会浪费上下文和时间。
一个局部正确的规则，到了另一个任务里可能变成负担。
这就是 Skill 退化最常见的路径：
单次失败
↓
局部总结
↓
写入 Skill
↓
变成全局规则
↓
影响更多任务
↓
系统整体变差所以，真正可靠的 Skill 不是从单次失败中反射出来的，而是从大量成功和失败轨迹中归纳出来的。
这也是 Trace2Skill 的价值：它不是让 Agent 看到一条失败就立刻改 Skill，而是通过多条轨迹、多 Agent 分析、层级合并，把局部经验提炼成更通用的 Skill。
这里的关键不是“自动生成”，而是“归纳”。
没有归纳，Skill Evolution 就会变成失败日志堆积。
三、第二种退化：只修失败，不保护成功
很多系统做自我进化时，只盯着失败。
它会问：
这次为什么失败？ 下次怎么避免？
但它很少问另一个更关键的问题：
如果我加入这条新规则，会不会破坏之前已经成功的任务？
这就是 Skill Evolution 比普通复盘更难的地方。
普通复盘只需要解释失败。
Skill Evolution 必须验证整体收益。
一个 Skill 修改，如果修好了 3 个失败案例，却破坏了 10 个原本成功的案例，它就不是进化，而是退化。
这也是 SkillOpt 最有价值的地方。
SkillOpt 不把 Skill 当成随便修改的提示词，而是把它当成 frozen agent 的外部可训练状态。它强调 bounded edits、held-out validation gate、rejected-edit buffer、textual learning rate。
这些机制背后的核心思想只有一个：
Skill 修改必须被验证，不能因为看起来合理就被接受。
这和深度学习里的训练纪律很像。
模型训练不是每看到一个样本就随便大幅修改权重。
Skill 训练也不应该每看到一次失败就整篇重写 Skill。
它需要：
- 小步修改；
- 验证集；
- 拒绝劣化版本；
- 记录失败 edit；
- 保留最佳版本；
- 支持回滚。
否则所谓“进化”，只是无约束自我改写。
而无约束自我改写，极容易变成自我污染。
四、第三种退化：Skill 越多，路由越难
很多人以为 Skill Library 越大越好。
这也是一个误区。
Skill 多了以后，真正的问题不是“有没有经验”，而是：
当前任务到底应该加载哪个 Skill？
如果 Skill 路由不准，Agent 会出现几个问题：
第一，加载了不相关 Skill，污染上下文。
第二，多个 Skill 互相冲突，导致 Agent 犹豫。
第三，触发条件相似，系统不知道该优先哪个。
第四，简单任务被复杂 Skill 过度处理。
第五，高风险 Skill 被错误加载，影响安全性。
所以 Skill Library 的复杂度不是线性增加，而是系统性增加。
当 Skill 从 10 个变成 100 个，问题不是多了 90 个文件，而是多了大量组合冲突、触发冲突、上下文污染和版本治理问题。
这也是为什么 EvoSkill 这类自动生成 Skill 的方法，不能直接接入生产环境。
EvoSkill 的价值在于提出候选 Skill，而不是直接上线 Skill。
候选生成越强，越需要质量门禁。
否则系统会不断生成新的 Skill，但没有人负责判断：
- 这个 Skill 是否重复？
- 是否真的提升？
- 是否破坏旧任务？
- 是否和其他 Skill 冲突？
- 是否应该合并而不是新增？
- 是否应该删除而不是强化？
真正成熟的 Skill Evolution，不只是 Skill Creation。
它还包括：
- Skill Deepening；
- Skill Merging；
- Skill Pruning；
- Skill Routing；
- Skill Validation；
- Skill Rollback。
如果只会新增，不会删除，Skill Library 必然膨胀。
Skill 一膨胀，Agent 就会变笨。
五、第四种退化：组织级共享会放大污染
SkillClaw 提出了一个非常重要的方向：Collective Skill Evolution。
一个用户踩过的坑，另一个用户不应该再踩一次。
一个 Agent 学到的经验，团队里的其他 Agent 应该可以复用。
这是非常有价值的方向。
因为未来 Agent 的能力，不只来自模型本身，也来自组织内部长期沉淀的执行经验。
但 Collective Skill Evolution 有一个更大的风险：
个人 Skill 错了，只影响个人。 共享 Skill 错了，会污染整个组织。
这就是 SkillClaw 方向必须面对的问题。
一旦某个错误 Skill 被同步到共享库，它可能影响：
- 多个用户；
- 多个项目；
- 多个 Agent；
- 多个工作流；
- 多个生产任务。
所以组织级 Skill Evolution 不能只是共享，还必须有治理。
至少需要：
- 用户隔离；
- 团队隔离；
- 权限控制；
- trace 脱敏；
- 发布审批；
- 灰度同步；
- 效果监控；
- 异常回滚；
- 来源追踪；
- 风险分级。
否则，Collective Learning 会变成 Collective Pollution。
集体学习的另一面，就是集体污染。
这也是为什么 SkillClaw 必须和 SkillOpt 结合。
SkillClaw 负责组织级经验网络。
SkillOpt 负责质量门禁。
没有门禁的共享，会把错误扩散得更快。
六、第五种退化：Agent 自我设计缺少边界
Memento-Skills 更进一步：让 Agent 设计 Agent。
这代表一个更大的趋势：
Skill 不只是操作说明，而是 Agent 的外部记忆和自我设计接口。
如果 Agent 可以读写 Skill，它就可以通过经验不断调整自己的行为模式。
这很强。
但也很危险。
因为一旦 Agent 可以改写自己的 Skill，它本质上就在改写自己的行为边界。
它可能出现几类问题：
第一，自我强化错误。
Agent 把错误经验写入 Skill，未来又不断调用这个 Skill，于是错误被反复强化。
第二，身份漂移。
原本 Agent 的职责边界很清楚，但 Skill 不断改写后，它的行为越来越不可预测。
第三，路由偏置。
某些 Skill 被频繁调用，导致其他更合适的 Skill 永远不会被选中。
第四，过度专用化。
Agent 为了某类任务优化过度，结果在其他任务上退化。
第五，缺少审计。
如果 Agent 自己改写了行为规则，但系统无法解释“为什么改、谁批准、影响什么”，生产环境就很难接受。
所以，Agent 可以设计 Agent，但不能绕过治理。
Memento-Skills 的战略意义很大：它说明 Agent 的学习未必依赖模型微调，也可以通过外部 Skill Memory 进行持续适配。
但它要真正进入生产系统，必须接入 SkillOpt 式验证门禁和 Skill Registry 式治理层。
否则它不是 Agent 自我进化，而是 Agent 自我漂移。
七、第六种退化：没有真实评测，系统会以为自己变强了
很多 Skill Evolution 系统还有一个问题：
它们只在局部任务上验证自己，却没有真实长链路评测。
这会导致一个错觉：
在几个测试样本上变好了，就以为整体 Agent 能力提升了。
但真实 Agent 任务不是这样。
真实任务通常包含：
- 多轮上下文；
- 多工具调用；
- 文件系统操作；
- 浏览器搜索；
- 代码执行；
- 邮件、日历、表格等真实环境；
- 中间状态变化；
- 最终结果检查；
- 安全与权限约束。
这也是 WildClawBench 的价值。
它不是简单问答 benchmark，而是面向真实长链路 Agent 任务的评测环境。它对应代码库是 InternLM/WildClawBench，也提供了 Leaderboard。
对 Skill Evolution 来说，WildClawBench 这类 benchmark 的意义是：
不要只证明某个 Skill 在单点样本上有效，要证明 Agent 在真实工作流中整体变强。
没有真实评测，Skill 系统很容易自我感觉良好。
它会看到：
- 当前失败样本修好了；
- 某个指标提升了；
- 某个 prompt 看起来更完整了；
- 某个 Skill 文件更长了。
但它没有看到：
- 执行时间变长了；
- 工具调用变多了；
- 成功路径被破坏了；
- 简单任务被复杂化了；
- 新 Skill 污染了旧任务；
- 用户体验反而变差了。
所以 Skill Evolution 必须接入真实评测，而不是只靠主观反思。
八、真正的问题：Skill 被当成文档，而不是资产
很多团队做 Skill 系统时，会把 Skill 当成文档。
这就是问题的根源。
如果 Skill 只是文档，那它可以随便写、随便改、随便堆。
但如果 Skill 会影响 Agent 的执行行为，它就不是文档，而是生产资产。
生产资产必须有资产管理方式。
一个成熟的 Skill 系统，至少应该记录：
- Skill 名称；
- Skill 版本；
- Skill 来源；
- 关联 trace；
- 触发条件；
- 适用模型；
- 适用工具；
- 适用任务；
- eval 结果；
- 修改 diff；
- 接受原因；
- 拒绝记录；
- 风险等级；
- owner；
- rollback version。
没有这些，Skill Library 就会失控。
你甚至无法回答几个最基本的问题：
- 这个 Skill 为什么存在？
- 它解决了什么问题？
- 它从哪几条 trace 来？
- 它有没有提升验证集？
- 它破坏过哪些任务？
- 它和哪些 Skill 冲突？
- 上一个稳定版本是什么？
- 出问题能不能回滚？
如果这些问题回答不了，Skill Evolution 就不是真正的 evolution。
它只是一个自动追加规则的系统。
九、正确的 Skill Evolution 应该怎么做？
我认为正确路线不是“让 Agent 自动写 Skill”。
而是建立一套 Skill CI/CD。
它的流程应该是：
Trace Capture
捕获成功和失败轨迹
Trace Distillation
从大量轨迹中提炼经验
Candidate Proposal
生成新增、修改、合并、删除 Skill 的候选方案
Validation Gate
用验证集和回归测试判断是否接受
Skill Registry
版本化、权限、灰度、回滚、审计
Runtime Routing
运行时按任务、上下文、风险加载合适 Skill
Continuous Eval
持续观察上线后的真实表现这套系统里，Trace2Skill、EvoSkill、SkillOpt、SkillClaw、Memento-Skills、WildClawBench 各有位置。
Trace2Skill 解决经验从哪里来。
EvoSkill 解决候选怎么生成。
SkillOpt 解决修改是否真的变好。
SkillClaw 解决组织经验如何复利。
Memento-Skills 解决 Agent 如何从通用变专用。
WildClawBench 解决真实任务如何验证。
它们不是互相替代，而是组成一个完整链路。
如果只做 Trace2Skill，没有 SkillOpt，可能提炼出未经验证的经验。
如果只做 EvoSkill，没有 Registry，可能产生大量 Skill 垃圾。
如果只做 SkillClaw，没有权限治理，可能把错误扩散到整个组织。
如果只做 Memento-Skills，没有边界控制，可能让 Agent 自我漂移。
如果没有 WildClawBench 或内部 Eval，就无法证明系统真的变强。
所以最终答案不是选某一个项目。
真正要做的是：
把 Skill Evolution 从“自动生成文本”升级为“经验资产训练系统”。
十、为什么这件事重要？
未来 Agent 产品的竞争，不会只看谁接了更强的模型。
模型会越来越强，也会越来越接近。
工具会越来越标准。
Agent framework 会越来越相似。
真正拉开差距的，会是每个组织沉淀下来的经验资产。
一个公司每天让 Agent 跑 1000 个任务。
真正有价值的不只是这 1000 个任务结果，而是其中沉淀出来的：
- 哪些任务容易失败；
- 哪些工具调用顺序更稳；
- 哪些上下文必须提前读取；
- 哪些场景需要人类确认；
- 哪些异常应该自动恢复；
- 哪些流程可以压缩；
- 哪些判断标准可以复用。
这些东西如果只是日志，就没有复利。
如果变成 Skill，而且能被验证、版本化、共享、回滚，它就会成为组织智能。
这才是 Agent Skill Evolution 的真正价值。
不是让 Agent 看起来更会反思。
不是让 Skill 文件越来越多。
不是让系统每天自动改几次 prompt。
而是把每次执行后的经验，变成可复用、可验证、可治理的生产能力。
十一、参考项目与论文
| 项目 | 论文 | 代码 / 项目页 | 在本文中的定位 |
|---|---|---|---|
| Trace2Skill | Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills | GitHub: Qwen-Applications/Trace2Skill | 从 Agent 执行轨迹中提炼可迁移 Skill，解决“经验从哪里来” |
| EvoSkill | EvoSkill: Automated Skill Discovery for Multi-Agent Systems | GitHub: sentient-agi/EvoSkill | 自动发现、生成、修改 Skill，解决“候选 Skill 怎么产生” |
| SkillOpt | SkillOpt: Executive Strategy for Self-Evolving Agent Skills | GitHub: microsoft/SkillOpt / 项目页 | 把 Skill 当成 frozen agent 的外部可训练状态，解决“如何避免越改越笨” |
| SkillClaw | SkillClaw: Let Skills Evolve Collectively with Agentic Evolver | GitHub: AMAP-ML/SkillClaw | 多用户、多 Agent 的集体 Skill Evolution，解决“组织经验如何复利” |
| WildClawBench | WildClawBench: A Benchmark for Real-World, Long-Horizon Agent Evaluation | GitHub: InternLM/WildClawBench / Leaderboard | 真实长链路 Agent 任务评测，解决“Skill/Agent 到底有没有真实工作能力” |
| Memento-Skills | Memento-Skills: Let Agents Design Agents | GitHub: Memento-Teams/Memento-Skills / 项目页 | 让 Agent 通过 Skill Memory 自我设计，解决“Agent 如何从通用变专用” |
如果把这些项目放进同一张系统图里，可以这样理解：
Trace2Skill：从轨迹中提炼经验
↓
EvoSkill / Memento-Skills：生成候选 Skill / 设计任务型 Agent
↓
SkillOpt：验证候选修改是否真的提升，拒绝劣化版本
↓
SkillClaw：把有效经验同步为组织级共享 Skill
↓
WildClawBench / Internal Eval：用真实长链路任务持续验证最后的判断
Skill 不是越进化越聪明。
无约束的 Skill Evolution，一定会越进化越笨。
因为它会把局部经验当成全局规律，把失败日志当成操作原则，把规则堆积当成能力提升，把共享同步当成组织学习。
真正的 Skill Evolution，必须有训练纪律。
它需要：
- 从大量 trace 中归纳，而不是从单次失败中反射；
- 同时保护成功路径，而不是只修失败样本；
- 小步修改，而不是整篇重写；
- 验证集门禁，而不是自我感觉变好；
- rejected edit buffer，而不是忘记失败修改；
- skill pruning，而不是无限新增；
- registry 和 rollback，而不是直接覆盖；
- 权限和审计，而不是全员共享污染；
- runtime routing，而不是盲目加载所有 Skill；
- 真实任务 eval，而不是只看局部样本。
一句话：
Skill 的未来，不是越进化越多，而是越训练越准。
真正值得构建的不是 Skill Generator。
而是 Skill Trust Layer。
它让 Skill 从“经验文本”变成“可信资产”；
让 Agent 从“会执行任务”变成“会沉淀能力”；
让组织从“重复踩坑”变成“经验复利”。
所以，为什么 Skill 会越进化越笨？
因为很多系统只做了 evolution，没有做 trust。
而未来真正重要的，是：
让 Skill 可以进化，也让每一次进化都可以被验证、被拒绝、被回滚、被沉淀。