阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
现如今，Agent Skills 已经成为 Agent 架构中非常重要的组成部分，是一种知识和工具的资源集合包，Agent 的最终效果与 Skill 的质量有着极高的相关度。
在 Agent Skills 的发展最早期的阶段，大家基本上主要就通过人工手写 Skill，这就需要投入大量的精力来进行撰写、调试、优化，效率较低且很难规模化。之后，许多 Agent 的工具或平台都提供了各式各样的 Skill Creator，通过 AI 辅助的方式去帮助用户自动生成 Skill，这在一定程度上提升了 Skill 的生产效率。再后来，就像我前段时间在《深度解析 Hermes Agent 如何实现”自进化”》中所写的那样，Agent 实现”自进化”的核心方式之一，就是 “Skill 的自动沉淀”：每执行完一轮 Agent，就会有 Agent 的运行轨迹（Trajectory）数据，模型基于这个轨迹的上下文去做判断，是否需要将当前的轨迹总结、沉淀为一个全新的 Skill，或者是否需要去更新一个已有的 Skill。
然而，在大家应用 Hermes Agent 的过程中，是不是也经常会遇到很多类似如下的问题：
那么，今天我们就重点来探讨一下 Skill 自进化中遇到的这些坑以及有哪些好的解法。
使用 Hermes 等目前各类 Agent 工具本身提供的方式去做 Skill 的自进化，出现上述这些问题现象是非常正常的。因为目前的 Skill 自我沉淀机制，大部分都是基于单通 Agent 对话轨迹来进行的。这意味着，当前这一轮对话 Session 中任务完成的效果，直接决定了这个 Skill 进化的方向。如果这一轮轨迹本身存在偶然性、特殊性，甚至是极端 Case，那么基于此生成的 Skill 就有可能会”带偏”进化的方向。
在个人场景下应用这种 Skill 自动沉淀模式，问题其实还不算大。但在企业级场景中，情况就完全不同了。
很多企业级 Agent 都是每天在线上承接同一类或多类重复任务，会积累垂直领域内海量的、不同用户的 Query。虽然它们虽然是同一个任务类型，其运行逻辑、流程应该也是高度趋同的，但由于用户 Query 之间存在差异，因此 Agent 中间产生的结果不同，在层层累积之后，最终执行轨迹和结论也可能会有较大差异，而且还会出现各类边界情况和长尾场景。如果我们简单地根据每一轮的轨迹运行情况，就直接在线上进行 Skill 的沉淀或更新，极易导致 Skill 质量”飘忽不定”，稳定性大幅降低。
这其实与早期的 Prompt 调优也有着很大的相似性：以前在做提示词调优的时候，如果你只是简单地把 badcase 丢给模型，让它根据这些个案去优化提示词，很容易就出现”顾此失彼”的现象。模型为了迎合当前的 badcase，甚至会去过拟合（Overfitting）。
这种受个例影响而不断”找补式的优化”，并不是一种好的优化方式。 Skill 的自进化如果缺乏科学、有效的机制，单纯的基于个例轨迹来实现自动更新，同样很容易让 Skill”过拟合”，陷入局部情况，甚至”越优化越差”。
在企业级的线上任务中应用 Agent Skill 时，我们通常不太敢让其直接实现真正意义上进行 Online 的自进化。更稳妥的做法是采取 Offline 的优化策略：
这种”离线优化 + 在线验证”的流程，尽可能去保障了企业级服务的稳定性和可靠性，但如果有大量的这些 Skill 需要优化和验证，也都每个像这样人工深度参与，就严重制约生产力，很难”规模化”。严格来说，这种”离线优化”并不是真正意义上的”自进化”，而是由人指导、在离线环境中进行的，Agent 本身并没有具备自主判断和修正的能力，核心的决策权依然在人的手中。
这就引出了本文想要深入探讨的核心话题：如何更科学、更可控、更保质保量的实现 Skill 自进化？ 我们追求的不再是那种”无脑”的、方向不稳定的盲目自进化，而是一种能够在保证质量前提下，真正释放人力、实现闭环优化的智能机制。
第一个要介绍的论文是来自阿里千问团队的《Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills》。
Trace2Skill 的核心思路在于强化”归纳能力”。它让一支”分析师小分队”并行地看大量的 Agent 执行轨迹，把每条轨迹里学到的零碎经验合并成一份完整、无冲突的 Skill 文档。它模仿了人的工作方式：先广泛积累领域知识，再一次性写出一份成熟的操作手册，而不是边干边改，整理出一堆碎片。
构建高质量的”数据原材料”：
实践中，使用一个 122B 参数的 LLM 生成 200 条包含 50+ 个轮次的 Agent 轨迹，所需时间不到两个小时。
这是 Trace2Skill 非常创新性的部分。它不再让一个 LLM 处理所有信息，而是为每一条轨迹独立分配一个 Sub-Agent 的分析师，输出一个针对该轨迹的”补丁提案”（Patch Proposal）。采用不对称的角色设计策略：
将分散的补丁池 p 合并成一份最终的更新 p∗。这是层次归并（Hierarchical Merge）过程：
在合并过程中，如果合并器发现那些在多个补丁中反复出现的模式，就会被保留并升级为通用原则；而那些只出现一两次的个例的修改，就很可能是个例或噪声，则会被果断丢弃。
阿里云服务领域的例子：如果我们打算总结”ECS 无法远程连接”这一类问题的通用解决方案，仅看 1~2 个工单，是非常难抽象出完整的、具有普遍性的诊断思路的。但如果我们把这一类工单放在一起看，可以从大量相似轨迹中抽取出”最大公约数”的核心内容（如”CPU/内存跑高”、”磁盘写满”、”端口不通”、”安全组拦截”等）。
Trace2Skill 可以把复杂的 Agent 经验打包成一份高度可迁移的 Skill，不需要更新模型参数，也不需要引入复杂的外部 RAG 检索模块，只需要使用开源级的模型就可以完成从 Agent 轨迹中构建 Skill。
Trace2Skill 的实验结果有力地挑战了一个传统假设：”经验本质上是任务特定的，必须通过情景记忆（Episodic Memory）库检索”的假设。这说明，一个高质量的 Skill 里的逻辑规则比零散的记忆（Memory）更具泛化性。
“先看够多 → 再写一份完整文档”。让 Agent 先充分阅读和分析大量轨迹，经过深度的归纳推理后，输出一份结构完整、逻辑自洽的 Skill 文档。这种”批处理式”的知识沉淀，往往比”流式”的反应更能捕捉到任务的本质规律。
如果说 Trace2Skill 是通过”归纳法”将经验聚合成静态的 Skill，那么 EvoSkill 则引入了动态的”验证”过程。EvoSkill 是由 Sentient Labs 发布的一款开源 Skill 自进化项目，论文标题《EvoSkill: Automated Skill Discovery for Multi-Agent Systems》。
这种从”构建 → 验证”机制的设计灵感，高度抽象了人类专家在离线优化 Skill 时的思维过程。EvoSkill 的核心在于将自进化的 LLM 拆解为三个角色明确的 Sub-Agent，形成一个 Pipeline：
在这个架构之上，EvoSkill 建立了一套严格的验证机制：
EvoSkill 采用了一种基于”前沿集合（Frontier）“的迭代算法。Frontier 集合 G 是一个容量固定为 k 的”精英池”，始终保留当前迭代中得分最高的 k 个程序（Program）。 这个 Program 是 Agent 能力的完整载体，包括封装了的系统提示词（System Prompt）和累积的各种 Skills 库，本质上类似 RL 里的策略（Policy）。
整体进化过程是一个 Loop，每一轮迭代 t 都严格遵循以下步骤：
这样做的好处是可以做正向筛选，使用固定容量的前沿集合机制，确保了只有真正带来性能提升的 Skill 才能被保留，防止无效优化导致的退化。而针对失败的尝试并非无用，它们作为”反面教材”存入历史库 H，帮助 Proposer Agent 学会识别无效的优化路径，从而越进化越聪明。
通过这种”执行 → 提案 → 构建 → 验证“的闭环，EvoSkill 就实现了 Skill 的自动化迭代。它不仅是在更新成功经验或者修补了一些失败错误，更是在不断的这种验证和选择过程中，让 Agent 逐渐摸索出更通用、更优的解题策略。
很多 Agent 开发者在初期构建 Agent 时，依赖的是”人的体感”——我觉得这个 Prompt 改得更好了。在企业级场景下，靠体感是不可持续且无法规模化（Scaling）的。
当任务复杂度上升，人的主观判断会出现偏差，甚至产生”我觉得写得很清楚，但模型理解有误”的认知错位。如果没有一套客观、可量化的验证机制，我们就无法区分是”Skill 本身的质量下降”还是”线上环境的其他因素导致了指标波动”，这种模糊性会导致迭代变得盲目且不稳定。
不知道大家有没有发现，尤其是进入 2026 年后的这几个月，Claude Ops、GPT、Qwen 等头部 LLM 迭代和发布速度越来越快。其中一个比较核心原因就在模型效果的衡量，越来越可验证。例如 AI Coding 场景，代码能否跑通、单元测试是否通过，这些都是验证成本较低且结果比较客观的场景。
Agent 也是同理，构建一套高质量、自动化的验证评估体系，才是 Agent 效果能”起飞”的前提。 一旦验证闭环打通，数据飞轮才能真正转动起来：
“Agent 产生轨迹” → “自动化验证给出即时反馈” → “根据反馈快速调整 Skill” → “新 Skill 再次进入验证循环”
只有在这样的模式下，迭代速度才能从”人力驱动”转变为”算力驱动”，实现质的飞跃。
如果说 EvoSkill 是通过”自验证”式和优胜劣汰来进化，那么 SkillOpt 则走了一条更硬核的路线：它将 Skill 的优化过程，直接对标为 LLM 的参数训练过程。 SkillOpt 是由微软公司联合上海交大、同济、复旦等多所高校一起提出的 Skill 优化新范式，论文标题《SkillOpt: Executive Strategy for Self-Evolving Agent Skills》。
在传统的深度学习范式里，模型主要是通过梯度下降（Gradient Descent）不断更新模型的权重（Weights），以最小化损失函数。而 SkillOpt 则创造性地提出了一个类比：
在这种视角下，Skill 不再仅仅是一段静态的提示词，而被视为一种”外部的、可训练的文本参数”。SkillOpt 引入了一个专门的”优化器 Agent”，它像 SGD 或 Adam 优化器一样，根据验证集上的表现（即”Loss”），不断地对 Skill 文本进行微调、重写和迭代，直到收敛到一个高质量的状态。
传统的 Prompt 优化往往依赖于人工调试，缺乏明确的方向感。而 SkillOpt 通过引入”训练范式”，带来了两个关键优势：
- 方向明确：每一次 Skill 的修改，都是基于明确的”误差信号”
- 系统化迭代：摒弃了零敲碎打的修补，将整个 Skill 作为一个整体对象进行系统性优化。同时还引入了文本领域的”学习率”（Learning Rate），能够控制每次 Skill 优化的粒度
让目标模型在训练集上执行任务（默认 Batch Size=40）：
优化器模型（Optimizer）接收前向传播产生的轨迹，并进行结构化分析：
这是 SkillOpt 与传统”无约束 Prompt 重写”最大的区别：
| 对比项 | Trace2Skill | EvoSkill | SkillOpt |
|---|---|---|---|
| 优化对象 | 单份 SKILL.md + Reference md 文档 | 可多个 Skill 文档 | 单份 best_skill.md 文档 |
| 数据采集 | 一次性跑完训练集，全部轨迹送进合并器 | 每轮跑训练 batch，收集失败样本 | 每步跑 rollout batch（默认 40），区分成功/失败 |
| 更新粒度 | 并行跑 patch，层次化合并所有 patch | 每轮一个新 Skill 或一次编辑 | 每步多个 bounded 原子编辑（新增/修改/替换） |
| 验证过程 | 编程式格式校验 + 冲突检测（无显式验证） | 验证集得分超过前沿集合最弱者才进入 | 严格大于当前最优才被接受（平局也拒绝） |
| 失败信号利用 | 通过 Multi-turn Agentic Error Analyst 找根因 | Proposer 读 Trace GroundTruth 找根因 | 分 minibatch 反思失败，被拒编辑进 buffer 作负反馈 |
| 学习率 | ❌ 一次成型 | ❌ 每次一个 Skill | ✅ 每次 Lt 条 |
| 动量 | ❌ | ❌ | ✅ |
| 元学习 | ❌ | 累计反馈历史 H（帮 Proposer 不重复出错） | Meta Skill（只给优化器看，沉淀调优经验） |
| 执行 Harness | ReAct 即可 | 需要底座 Harness | Chat / Codex / Claude Code 等 Harness 无关 |
| 模型分离 | 同一模型自给自足 | 同一模型扮演三个角色 | 优化器、目标模型 分离 |
这三种范式代表了 Agent Skill 进化正在从”经验主义”走向”科学工程”路径：
整体来看，引入验证机制的方案会优于纯归纳方案，因为后者在验证的过程中，会引导 Agent 不断走向了进化的正确方向。但同时，随着方法复杂度的提升，计算成本和迭代周期也在显著增加。因此，还是需要根据实际业务情况来决策使用哪种方案：
Agent 的构建方法论将从”玄学调试”真正走向”科学工程”。