背景现如今Agent Skills 已经成为 Agent 架构中非常重要的组成部分是一种知识和工具的资源集合包Agent 的最终效果与 Skill 的质量有着极高的相关度。在Agent Skills 的发展最早期的阶段大家基本上主要就通过人工手写 Skill这就需要投入大量的精力来进行撰写、调试、优化效率较低且很难规模化。之后许多 Agent 的工具或平台都提供了各式各样的 Skill Creator通过 AI 辅助的方式去帮助用户自动生成 Skill这在一定程度上提升了 Skill 的生产效率。再后来就像我前段时间在《深度解析Hermes Agent 如何实现“自进化”及其 Prompt / Context / Harness 的设计实践》中所写的那样Agent 实现“自进化”的核心方式之一就是 “Skill 的自动沉淀”。这个核心逻辑是每执行完一轮Agent就会有 Agent 的运行轨迹Trajectory数据模型基于这个轨迹的上下文去做判断是否需要将当前的轨迹总结、沉淀为一个全新的Skill或者是否需要去更新一个已有的 Skill。这种方式可以说在很大程度上解放了人力不再需要让人完全从头写 Skill或者基于已有的 Skill 也不需要做太多手动优化的动作模型可以自动迭代从而迈向了一种更加自动化的Skill 构建新形态。然而在大家应用Hermes Agent 的过程中是不是也经常会遇到很多类似如下的问题●为什么自动沉淀的Skill质量不高对Agent 的效果帮助不大●为什么Skill 更新后反而比原来的版本效果更差了●原本精简清爽的Skill经过几次自动迭代后变的越冗长复杂、难以阅读那么今天我们就重点来探讨一下Skill 自进化中遇到的这些坑以及有哪些好的解法。Skill自进化有哪些难点使用Hermes 等目前各类 Agent 工具本身提供的方式去做 Skill 的自进化出现上述这些问题现象其实也是非常正常的。因为目前的 Skill 自我沉淀机制大部分都是基于单通Agent 对话轨迹来进行的。这意味着当前这一轮对话Session 中任务完成的效果直接决定了这个 Skill 进化的方向。如果这一轮轨迹本身存在偶然性、特殊性甚至是极端Case那么基于此生成的Skill 就有可能会**“带偏”进化的方向**。在个人场景下应用这种Skill 自动沉淀模式问题其实还不算大。因为个人用户的任务多样性比较高任务要求相对分散同一个任务再次运行或遇到完全相同场景的概率相对低一些Skill 的复用比例不高因此即使个别 Skill 进化偏差对整体体验的影响也相对有限大家可能察觉不到明显的**“降智”**。但在企业级场景中情况就完全不同了。很多企业级Agent 都是每天在线上承接同一类或多类重复任务会积累垂直领域内海量的、不同用户的Query。虽然它们虽然是同一个任务类型其运行逻辑、流程应该也是高度趋同的但由于用户 Query 之间存在差异因此 Agent 中间产生的结果不同在层层累积之后最终执行轨迹和结论也可能会有较大差异而且还会出现各类边界情况和长尾场景。如果我们简单地根据每一轮的轨迹运行情况就直接在线上进行Skill 的沉淀或更新极易导致 Skill质量“飘忽不定”稳定性大幅降低。它可能出现“一会儿变好一会儿变差”的现象甚至因为某个特定的极端 Case 而被引导至错误的进化方向导致整个 Skill 体系逐渐“跑偏”。这其实与早期的Prompt 调优也有着很大的相似性。大家可以回顾一下以前在做提示词调优的时候如果你只是简单地把badcase 丢给模型让它根据这些个案去优化提示词很容易就出现“顾此失彼”的现象。模型为了迎合当前的badcase甚至会去过拟合Overfitting把这些个例情况补进去不但导致Prompt 变得越来越臃肿、发散甚至还会破坏了原本的泛化性和通用性。这种受个例影响而不断**“找补式的优化”并不是一种好的优化方式。所以说Skill 的自进化如果缺乏科学、有效的机制单纯的基于个例轨迹来实现自动更新同样很容易让 Skill “过拟合”陷入局部情况甚至“越优化越差”**。因此在企业级的线上任务中应用Agent Skill 时我们通常不太敢让其直接实现真正意义上进行Online 的自进化。更稳妥的做法是采取Offline的优化策略比如1.离线收集轨迹数据在离线环境中收集Agent 执行轨迹手动进行 Skill 的更新、进化和维护模拟2.**人工审核与评测验证**优化后的Skill 必须经过人工审核和确认甚至很多场景会建立一套完善的回归评测体系去验证新版本的 Skill 是否真的带来了效果提升并且没有引入新的额外问题3.**灰度切流上线**只有在离线验证Skill 确认无误后才敢去替换线上的版本并且还要灰度切流持续观察效果。这种“离线优化 在线验证”的流程尽可能去保障了企业级服务的稳定性和可靠性但如果有大量的这些Skill 需要优化和验证也都每个像这样人工深度参与就严重制约生产力很难“规模化”。并且整个过程从收集轨迹数据、离线优化、评测验证整个链路非常耗时耗力。因此严格来说这种**“离线优化”并不是真正意义上的“自进化”**而是由人指导、在离线环境中进行的Agent 本身并没有具备自主判断和修正的能力核心的决策权依然在人的手中。这就引出了本文想要深入探讨的核心话题如何更科学、更可控、更保质保量的实现Skill 自进化我们追求的不再是那种“无脑”的、方向不稳定的盲目自进化而是一种能够在保证质量前提下真正释放人力、实现闭环优化的智能机制。近期我深入调研了 Skill 自进化领域的相关的论文。其中有三篇我个人认为比较有里程碑意义的论文它们代表了三种Skill 的优化思路并且这三篇论文对应的代码均已开源。对于正在探索Agent Skill 落地的和应用的同学来说这无疑是非常好的参考素材。所以本文我会对这三篇论文进行深度解析有兴趣的同学也可以深入去阅读以下论文原文以及 GitHub 上的开源代码看看哪种方案更契合自己的业务场景。Trace2Skill“归纳法”的聚合式进化第一个要介绍的论文是来自阿里千问团队的《Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills》这个项目的名字也叫Trace2Skill。从名字就能看出来它的目标就是将轨迹Trace转换为Skill同时它也直击我们前面提到的痛点单点Agent 轨迹的局限性。就像我在上文中所说的如果我们仅仅依据某一轮Agent 的执行轨迹来更新 Skill极易陷入“盲人摸象”的困境导致 Skill 的方向“跑偏”。因此Trace2Skill 的核心思路在于强化“归纳能力”。它让一支“分析师小分队”并行地看大量的Agent 执行轨迹把每条轨迹里学到的零碎经验合并成一份完整、无冲突的Skill 文档它模仿了人的工作方式先广泛积累领域知识再一次性写出一份成熟的操作手册而不是边干边改整理出一堆碎片。这个图里面左侧是传统的Online 的 Skill 自进化传入的单个轨迹的经验会按照顺序依次去更新 Skill 库里的 Skill。而右侧就是 Trace2Skill 的做法会并行去分析大量轨迹并以分层方式整合经验教训从而归纳出可泛化的、标准的 Skill。Trace2Skill 的核心实现过程可以拆解为三个关键步骤如下图所示我们就每个步骤具体来看下。轨迹生成这一步的目标是构建高质量的“数据原材料”。●初始输入给定一份初始Skill比如是S0可以是人工编写的也可以是模型生成的初始草稿●轨迹生成让Agent 通过 ReAct 的方式在一批用户任务上运行产生大量的执行轨迹。这个过程是完全可以并行的效率会比较高比如在实践中使用一个 122B 参数的 LLM 生成 200 条包含 50 个轮次的 Agent 轨迹所需时间不到两个小时●正负样本分离根据执行结果是否正确将轨迹严格划分为成功集T和失败集T−。这种分层为后续的差异化分析奠定了基础并行提案这是Trace2Skill 非常创新性的部分。它不再让一个 LLM 处理所有信息而是为每一条轨迹独立分配一个Sub-Agent 的分析师输出一个针对该轨迹的**“补丁提案”Patch Proposal。这里采用了一种不对称的角色设计策略**●Success Analyst (A) - 成功经验提取■机制针对成功集T进行分析一次性调用LLM■逻辑成功的案例通常比较容易识别和分析。分析师只需清理轨迹噪声提取出可泛化的成功行为模式直接写成补丁即可■特点高效、低成本因为成功路径往往具有较高的一致性●Error Analyst (A−) - 失败根因挖掘■机制针对失败集T−进行分析采用ReAct 多轮循环推理■逻辑失败的原因千奇百怪单次LLM 调用极易产生幻觉或误判。因此A−需要能够读取输入输出文件、对比Ground Truth并通过迭代验证假设来寻找真正的根因写成补丁■质量门控如果经过多轮推理仍无法找到明确根因该条轨迹会被直接丢弃。这确保了进入下一阶段的都是高质量、有明确改进方向的反馈■隔离性所有分析师都基于同一份冻结的初始SkillS0进行分析互不干扰。这种设计保留了观察的多样性避免了早期错误观点的相互污染无冲突归纳最后一步是将分散的补丁池p合并成一份最终的更新p∗。这本质上是一个**层次归并Hierarchical Merge**的过程●递归合并每层最多B**merge个补丁合成一个逐层递归向上直到合并为最终版本。●单一模型整个合并过程由同一个LLM 充当“合并器”负责去重、解决冲突、保留独特见解。●硬约束Hard Constraints在合并这些补丁集的时候会通过代码来做一些硬约束■引用检查如果补丁引用了不存在的文件或变量直接拒绝■冲突标记如果同一文件的同一行被多个补丁多次编辑标记为冲突并暂缓处理■格式校验最终生成的Skill 必须通过严格的格式校验器检查确保语法正确。在这种层次化的归并中如果合并器发现那些在多个补丁中反复出现的模式这就恰恰说明这是系统性问题或通用规律就会被保留并升级为通用原则而那些只出现一两次的个例的修改就很可能是个例或噪声则会被果断丢弃。这样Trace2Skill 就实现了从**“单点试错”到“群体归纳”的跨越有效地解决了Skill 进化中的被个例引导走偏从而失去泛化性问题**举个例子在我们的阿里云服务领域中如果我们打算总结某一类问题的通用解决方案比如“ECS无法远程连接”仅看1~2个工单是非常难抽象出完整的、具有普遍性的诊断思路的因为单个案例往往带有强烈的偶然性和特异性。但如果我们将这一类工单放在一起看情况就完全不同了。我们可以对大量相似轨迹进行分析、聚合从中抽取出那些符合“最大公约数”的核心内容。比如“CPU/内存跑高”、“磁盘写满”、“端口不通”、“安全组拦截”等等这些检测项才是被多次验证、高频出现的内容才是真正稳定、有价值的知识沉淀。结论与思考为了验证Trace2Skill 的有效性论文将实验放在极具挑战性的表格领域用了**SpreadsheetBench-Verified 和 WikiTableQuestions 来做为Benchmark**重点考察其泛化能力与跨模型迁移性。具体的实验数据在论文中都有大家可以去看原文因为篇幅的关系我这里写一下核心结论希望能为大家在构建自主Agent 时提供新的视角。1. 轻量级的高度可迁移方案Trace2Skill 可以把复杂的 Agent 经验打包成一份高度可迁移的 Skill不需要更新模型参数也不需要引入复杂的外部 RAG 检索模块只需要使用开源级的模型就可以完成从 Agent 轨迹中构建 Skill。2. 轨迹分析做出来的 Skill 真的能泛化Trace2Skill 的实验结果有力地挑战了一个传统假设**“经验本质上是任务特定的必须通过情景记忆Episodic Memory库检索”**的假设。实践证明通过轨迹分析提炼出的Skill 具有泛化能力是可以跨任务领域迁移的。这说明一个高质量的Skill 里的逻辑规则比零散的记忆Memory更具泛化性。3. 设计哲学像人类专家一样“先观察后总结”在方法论层面这种模仿人类专家学习路径的设计哲学还是挺有用的“先看够多 → 再写一份完整文档”。让Agent 先充分阅读和分析大量轨迹经过深度的归纳推理后输出一份结构完整、逻辑自洽的 Skill 文档。这种“批处理式”的知识沉淀往往比“流式”的反应更能捕捉到任务的本质规律。4. 一些局限性与展望当然Trace2Skill 目前的探索也不完善仍存在局限性后续可以重点突破的方向●因果贡献难以定量目前还无法精确量化Skill 中某个具体补丁Patch对最终效果提升的贡献值●使用率追踪缺失对于生成的Skill 文档还缺乏细粒度的监控手段来追踪各段落在实际运行中的真实调用率和有效性●缺乏验证机制Skill 的构造过程已经比较像人类专家了但验证还是需要人来做还不能自动验证没有自动化的验证机制就很难保证自动迭代出来的Skill 是否真的会提升EvoSkill“自验证”的自然选择如果说Trace2Skill 是通过“归纳法”将经验聚合成静态的 Skill那么EvoSkill则引入了动态的“验证”过程虽然从 EvoSkill 名字上似乎只能看出它的核心目标是实现Skill 的自进化。EvoSkill 是由 Sentient Labs 发布的一款开源 Skill 自进化项目论文标题叫做《EvoSkill: Automated Skill Discovery for Multi-Agent Systems》。从“构建 → 验证”的架构设计这种从**“构建 → 验证”机制的设计灵感就有点像武侠小说中的“左右互搏”**了也高度抽象了人类专家在离线优化Skill 时的思维过程不再依赖人工去手动构建和调试而是构建了一个由三个专用 Agent 组成的闭环系统让它们相互协作、互相验证自动完成 Skill 的分析和进化。EvoSkill 的核心在于将自进化的LLM拆解为三个角色明确的Sub-Agent了形成一个Pipline●执行者Executor负责“跑”。它基于当前待优化的 Skill去执行具体任务并产生完整的 Agent 运行轨迹和最终答案。这是进化的“素材来源”这一步和 Trace2Skill 的第一步是一样的●提案者Proposer负责“诊”。它深入分析执行者产生的轨迹判断结果是否正确。如果失败它需要精准定位问题根源并提出具体的优化方向和改进提案如果成功它也会总结有效模式。这个和 Trace2Skill 里的分析师差有点像但这里没有去做并行的轨迹分析并且EvoSkill 的分析师还会决定是新建一个Skill还是改一个已有的Skill做一个决策●搭建者Builder负责“改”。它接收分析师提出的优化建议真正动手编写或修改 Skill 文档将其落实为可执行的代码或指令规则。在这个架构之上EvoSkill 建立了一套严格的验证机制来确保每一次进化都是正向的这个是EvoSkill最核心的创新点●生成与执行搭建者完成Skill 修改后系统会在一个独立的**验证集Validation Set**上重新运行该Skill。●效果比对系统会自动比对优化前后的性能指标。只有当新Skill 在验证集上的表现确实优于旧版本时这次进化才会被确认保留。●负向反馈记录如果验证结果显示效果没有提升甚至下降EvoSkill 并不会直接丢弃这次尝试而是将这一“失败案例”记录下来。这些记录会成为分析师后续学习的宝贵数据帮助它更准确地识别哪些优化方向是无效的从而避免在未来的迭代中重蹈覆辙。进化过程的算法实现为了保证进化的方向始终朝向更优解EvoSkill 采用了一种基于“前沿集合Frontier”的迭代算法。什么叫前沿集合呢定义为G指的是一个容量固定为kk的“精英池”始终保留当前迭代中得分最高的k个程序Program。等等你可能会问这里的程序又是什么概念呢这个程序指的是Agent 能力的完整载体包括封装了的系统提示词System Prompt和累积的各种Skills 库。那么EvoSkill 的进化的过程本质上就是用更强的新程序替换池中较弱的旧程序的过程。这个程序非常像 RL 里的策略Policy如果大家了解RL 的话可能会更好理解一些。整体进化过程是一个Loop每一轮迭代t都严格遵循以下步骤来确保进化方向的正确性1.选择父代从前沿集合G中轮询选择一个父程序p确保每个成员都有被优化的机会。2.挖掘失败在训练集上运行p收集得分低于阈值的失败样本集F。若没有失败的样本则说明当前程的序已足够强大可以直接跳过本轮迭代。3.诊断提案ProposerProposer Agent 结合失败集FF和历史记录分析执行轨迹与能力差距输出文本形式的优化提案π。4.落地构建Skill-BuilderSkill-Builder Agent 将提案π具体化为候选程序p~即在父程序基础上新增或修订技能。5.严格验证在独立的预留验证集VV上评估p。若其得分高于G*G*中**最弱**的成员则*p*进入集合并取代最弱者否则丢弃。6.历史沉淀无论成败都将提案、得分及判决结果记入历史库H供后续迭代参考避免重蹈覆辙。最终经过T次迭代系统输出前沿集合G中得分最高的程序这里面的System Prompt 和 Skill 都是最优解的版本。这样做的好处是可以做正向筛选使用固定容量的前沿集合机制确保了只有真正带来性能提升的Skill 才能被保留防止无效优化导致的退化。而针对失败的尝试并非无用它们作为“反面教材”存入历史库H帮助Proposer Agent 学会识别无效的优化路径从而越进化越聪明。这个过程基本上就是将人工调试 Skill 的过程给 Agent 化了为构建具备长期自主进化能力的智能体系统提供了极具参考价值的新范式。通过这种**“执行 → 提案 → 构建 → 验证”**的闭环EvoSkill 就实现了 Skill 的自动化迭代。它不仅仅是在更新成功经验或者修补了一些失败错误更是在不断的这种验证和选择过程中让 Agent 逐渐摸索出更通用、更优的解题策略。确保了 Agent 在一个能正向提升的方向上“进化”而不是盲目进化。结论与思考EvoSkill 的核心算法其实不复杂一个里程碑式的创新就是加入了**“验证”那么这就需要我们思考一下为什么引入严格的验证机制能让Agent 的效果更可控**本质上验证就是Agent 进化过程中的“奖励函数”Reward Function。这就好比强化学习RL中的逻辑我们需要一个明确的信号来告诉模型**“什么是好的”。在EvoSkill 中验证集上的得分就是这个信号。它也像梯度下降中的损失函数**一样指引着Skill 优化的方向。如果没有这个可量化的“导航仪”Agent 的迭代就会陷入盲目。1. 从“体感”到“量化”打破不可持续的瓶颈很多Agent 开发者在初期构建 Agent 时依赖的是“人的体感”——我觉得这个 Prompt 改得更好了我觉得回答更流畅了。在个人场景下靠体感没问题因为你就是唯一的用户和裁判。但在企业级场景下靠体感是**不可持续且无法规模化Scaling**的。当任务复杂度上升人的主观判断会出现偏差甚至产生“我觉得写得很清楚但模型理解有误”的认知错位。如果没有一套客观、可量化的验证机制如自动化测试用例、代码执行通过率等我们就无法区分是**“Skill 本身的质量下降”还是“线上环境的其他因素导致了指标波动”**这种模糊性会导致迭代变得盲目且不稳定。只有通过严格的验证我们才能自信地说“我的 Skill 质量确实提升了”或者精准定位问题所在。2. 可验证性决定迭代速度数据飞轮的关键不知道大家有没有发现尤其是进入2026年后的这几个月Claude Ops、GPT、Qwen 等头部 LLM 迭代和发布速度越来越快之所以这些 LLM 能以月甚至以周为单位快速迭代其中一个比较核心原因就在模型效果的衡量越来越可验证。例如AI Coding 场景代码能否跑通、单元测试是否通过这些都是验证成本较低且结果比较客观的场景。如果每次迭代都需要大量人工标注或主观评估则迭代周期久会被无限拉长。其实Agent 也是同理构建一套高质量、自动化的验证评估体系才是Agent 效果能“起飞”的前提。一旦验证闭环打通数据飞轮才能真正转动起来从“Agent 产生轨迹” → “自动化验证给出即时反馈” → “根据反馈快速调整 Skill”→ “新 Skill 再次进入验证循环”。只有在这样的模式下迭代速度才能从“人力驱动”转变为“算力驱动”实现质的飞跃。反之若缺乏可验证的标尺任何优化都可能是原地踏步甚至南辕北辙不进反退。SkillOpt将 Skill 进化对标为“模型训练”如果说EvoSkill 是通过“自验证”式和优胜劣汰来进化那么 SkillOpt 则走了一条更硬核的路线它将Skill 的优化过程直接对标为LLM的参数训练过程。SkillOpt 是由微软公司联合上海交大、同济、复旦等多所高校一起提出的 Skill 优化新范式论文标题叫做《SkillOpt: Executive Strategy for Self-Evolving Agent Skills》最近讨论的热度也比较高我也认为这是一个新的里程碑式的项目。以后这类基于文本的优化过程应该也会像模型权重的训练一样越来越标准化和科学化。Skill 是“外部可训练参数”在传统的深度学习范式里模型主要是通过梯度下降Gradient Descent不断更新模型的权重Weights以最小化损失函数。而SkillOpt 则创造性地提出了一个类比把**“Skill 文本”类比为“模型权重” 把“基于反馈的文本重构”类比为“梯度更新” 、把“LLM 驱动的改写引擎”类比为“优化器Optimizer”。**在这种视角下Skill 不再仅仅是一段静态的提示词而被视为一种**“外部的、可训练的文本参数”。**SkillOpt 引入了一个专门的“优化器 Agent”它像 SGD 或 Adam 优化器一样根据验证集上的表现即“Loss”不断地对 Skill 文本进行微调、重写和迭代直到收敛到一个高质量的状态。上图是SkillOpt 的一个概览图。目标模型利用当前Skill 执行任务一个额外的前沿优化器模型将Agent 轨迹转化为有界的添加、删除、替换 Skill 的编辑操作一个 hold-out 的门控机制仅接受那些能提升验证集效果的修改。被接受的修改会被导出为可复用的Skill而被拒绝的修改则作为负面反馈用于后续的更新。那SkillOpt 为什么这样做呢传统的 Prompt 优化往往依赖于人工调试缺乏明确的方向感。而 SkillOpt 通过引入“训练范式”带来了两个关键优势●方向明确每一次Skill 的修改都是基于明确的“误差信号”即验证失败的原因。这就像梯度指向了损失函数下降最快的方向SkillOpt 让文本优化也有了明确的“梯度”这个逻辑和 EvoSkill 的“验证”思路其实是一样的。●系统化迭代它摒弃了零敲碎打的修补而是将整个Skill 作为一个整体对象进行系统性优化。这种“端到端”的训练思维使得 Skill 的结构更加紧凑、逻辑更加自洽。同时还引入了文本领域的**“学习率”Learning Rate**能够控制每次Skill 优化的粒度也就是文本修改的比重。六大核心组件详解为了将“Skill 即参数”的理念落地SkillOpt 设计了六大核心组件和工作流程。这套流程严格对标深度学习中的训练范式从数据收集、梯度计算、参数更新到验证 gating每一步都经过精心设计以确保 Skill 优化的稳定性和高效性。SkillOpt 整体的流程如下图所示冻结参数的目标模型利用当前 Skill 执行一批 Rollout优化器模型对成功和失败案例进行小批量的反思提出有界的添加、删除、替换优化操作在预定的编辑额度下对这些操作进行合并和排序并且仅通过预留的 hold-out 验证门控机制来接受候选 Skill。在各个 epoch 中慢速、元更新在不改变目标模型的情况下保留更长视野的经验教训。具体的细节我们展开来看下。1. 前向传播证据收集Forward PassRollout Evidence就像模型训练需要先进行前向传播以获取LossSkillOpt 的第一步是让目标模型在训练集上执行任务。这个其实和 Trace2Skill、EvoSkill 的第一步都是一样的先生成 Agent 轨迹●**批量执行**默认以Batch Size40 运行一个 rollout batch。●**全量记录**不仅记录最终答案还完整捕获任务上下文、消息历史、工具调用、观察结果、验证器反馈以及Harness 特定的元数据如表格预览、文档引用、执行 Trace 摘要等。●**解耦设计**支持累积多个Batch 后再统一进行反思实现了“执行节奏”与“更新节奏”的解耦提升了工程灵活性。2. 反向传播小批量反思Backward PassMinibatch Reflection这就是SkillOpt 的“梯度计算”环节。优化器模型Optimizer接收前向传播产生的轨迹并进行结构化分析。这个和 Trace2Skill、EvoSkill 的分析、提案的步骤基本上也是一样的但更加细节●分组与分片将轨迹分为“成功”和“失败”两组并进一步切分为 Minibatch默认大小 8。●为什么用Minibatch单个轨迹容易导致过拟合产生过于具体的修补Over-specific Fix而 Minibatch 能暴露反复出现的程序性错误Procedural Errors从而提炼出更具通用性的规则这个有点类似Trace2Skill 多个Batch聚合过程。●原子化编辑每个Minibatch 产出一组结构化的原子编辑操作比如追加、添加、删除、替换等。●层次化合并先分别合并Failure 和 Success 组的编辑建议最后再做全局合并且遵循“Failure 优先于 Success”的原则确保优先解决致命问题。3. 学习率约束有界文本更新Bounded Text UpdatesLearning Rate Constraint这是SkillOpt 与传统“无约束 Prompt 重写”最大的区别也是其稳定性的核心来源。●核心创新每一步迭代只允许L**t条编辑生效。这相当于深度学习中的**学习率Learning Rate**控制控制的越细节迭代越慢也越容易陷入局部最优解但是控制太粗又可能跳出全局最优解。●避免灾难性遗忘无约束的重写容易清掉原有有用规则、引入逻辑冲突或过拟合到局部失败案例。通过限制编辑数量SkillOpt 确保了更新的平滑性。●调度策略支持Cosine默认、Constant、Linear和 Autonomous 四种调度方式。默认的 Cosine 策略从大步长开始逐渐收敛模拟了模型训练后期的精细调优过程。●编辑模式默认采用Patch 模式局部微调也可切换为 Rewrite 模式整体重写。4. 验证门控 负反馈缓冲Validation Gate Rejected-Edit Buffer这一步对应模型训练中的“验证集评估”但引入了更严格的准入机制●严格优于才接受候选Skill 必须在独立的验证集 *Dsel上运行只有当得分严格高于*当前最优Skill 时才被接受平局也被拒绝防止性能抖动。●负反馈价值化被拒绝的编辑并不会被丢弃而是连同其导致的分数跌幅一起存入Rejected-Edit Buffer。这些“失败教训”会被喂给后续的优化器帮助它理解哪些修改方向是危险的从而避免重蹈覆辙。这将流程从“无条件自我编辑”升级为严谨的Propose-and-Test优化闭环。5. 慢更新 元更新动量机制Epoch-Wise Slow/Meta Update为了捕捉长期趋势并维持知识稳定性SkillOpt 引入了类似训练里的动量Momentum的机制。●四类样本归因每个Epoch 结束时用同一批训练样本分别在“上一 Epoch Skill”和“当前 Skill”下重跑将结果归为四类Improvements提升、Regressions退步、Persistent Failures持续失败、Stable Successes稳定成功。●受保护区域更新优化器会将纵向的指导原则写入Skill 中的受保护区域常规的步级编辑无法修改这部分内容确保了核心逻辑的稳定性。●Meta-Skill维护一份仅对优化器可见、不随Skill 部署的“元记忆”记录“哪些编辑模式好用”、“哪些被频繁拒绝”、“哪些失败一直未解决”从而指导优化器自身的策略调整你可以理解为这是“调优Skill 经验的 Skill 的经验”套娃了。6. Harness 无关部署Harness-Agnostic Deployment最后SkillOpt 强调了工程落地的简洁性与通用性是 Harness 无关的●轻量适配通过轻量级适配器接口同一套优化器逻辑可以无缝运行于直接对话、Codex CLI、Claude Code CLI 等多种执行 Harness 框架。●极简产物最终的部署产物仅仅是一个best_skill.md 文件通常300 ~ 2000 Tokens不包含任何复杂的依赖或外部模块。这种“纯文本、零依赖”的特性使得 Skill 极易移植、版本管理和大规模分发。通过这六大组件的协同工作SkillOpt 成功地将非结构化的文本优化问题转化为一个可控、可解释、可迭代的类训练过程为 Agent 能力的自动化提升提供了一套标准化的解决方案。结论与思考从最后的效果上来看在SkillOpt 论文中所对比的这些benchmark上来看SkillOpt 的效果是更好一些的。当然在实际场景上还是需要各位同学用的时候进一步做测试和验证。下面主要总结一下SkillOpt所带来的创新●Skill 应当被像参数一样训练——SkillOpt 是首个系统性、可控的文本空间优化器。●关键设计边界化的学习率、验证gate、rejected-edit buffer等都被消融实验证明是必需的。●产物是真正可部署的best_skill.md 是个三百到两千token 的小文档可以跨模型、跨 harness、跨任务迁移。●**不足的地方**只自进化调优了best_skill.md 这个单Skill文档对于其他的文件比如 References 里的Markdown文件或者 Resources 中的脚本代码等文件没有考虑到自进化中。并且没有考虑跨领域的 Skill 库等等。三者的对比最后在介绍完这三个Skill 自进化的论文之后我们来做一个总体的对比让大家更加清晰明了的看到他们的区别。Trace2Skill归纳推理学派●核心假设好的Skill 应该来自对大量轨迹的归纳单条轨迹的教训不可靠●关键动作并行处理 层次化合并●类比就像专家开会大家分头看不同案例然后开会合并意见“被多人提到的”才进最终报告●**优势**一次成型效率高最终Skill 简洁可读●**风险**合并器要够强否则会丢细节EvoSkill自验证选择学派●核心假设Skill 应该慢慢长出来每轮针对一个具体失败提出改进能跑赢前沿集合就保留●关键动作前沿集合 失败驱动提案 累计反馈历史●**类比自然选择进化**每一代基因有突变产生新Skill适应度验证分数高的才能延续下来●优势自然生长出一个Skill 库每个Skill 都对应一个具体的失败模式可解释性更强。●**风险**每轮只改一处收敛慢、需要不少迭代不同轮次跑的结果差异大。SkillOpt训练优化器学派●核心假设Skill 应该被像神经网络参数一样训练要有严格的约束来保证稳定收敛。●关键动作学习率约束 验证 gate 负反馈 buffer 元学习●类比带momentum early stopping 的 SGD每步只动一点点被拒的更新留作负样本每轮epoch 做长期巩固。●**优势**可控性最强每个组件都有明确的解释并且与神经网络学习对标●**风险**组件太多并且强依赖一个稳定的验证集和打分函数更多的对比细节我通过这个表格列出来吧写的也不一定全也是按照我个人的理解来的对比项Trace2SkillEvoSkillSkillOpt优化对象单份 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只给优化器看沉淀调优经验执行 HarnessReAct 即可需要底座 HarnessChat / Codex / Claude Code 等 Harness 无关模型分离同一模型自给自足同一模型扮演三个角色优化器、目标模型 分离总结最后再次回顾这三种范式我们实际上见证了Agent Skill 进化正在从“经验主义”走向“科学工程”路径Trace2Skill是归纳法的代表它通过“由点及面”的思维将分散的单点轨迹提炼为通用的核心思考解决了从 0 到 1 的快速启动问题。EvoSkill是自动化离线Pipeline的进阶它引入了“分析-验证-更新”的闭环让 Skill 具备了基于反馈的自进化能力解决了静态规则无法适应动态场景的痛点。而SkillOpt则是训练范式的极致体现它在验证的基础上引入了学习率、动量等更科学的约束机制通过小步迭代和严格门控实现了效果的可控性与稳定性最大化。那么哪种方案最好呢虽然论文的实验数据给出了部分场景中的测试结果但实际业务场景决定了最终选择。整体来看引入验证机制的方案会优于纯归纳方案因为后者在验证的过程中会引导Agent 不断走向了进化的正确方向。但同时随着方法复杂度的提升计算成本和迭代周期也在显著增加。因此还是需要根据实际业务情况来决策使用哪种方案●如果你的场景相对简单追求快速落地并且规律性比较明显Trace2Skill 的性价比可能最高。●如果你对Skill 的效果有明确要求且拥有完善的自动化评估体系那么 EvoSkill、SkillOpt 就更适合。●也许混合策略可能是比较好的解法比如用Trace2Skill 快速生成基线用 EvoSkill 持续扩充技能库再对核心瓶颈模块使用 SkillOpt 进行精细打磨。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 如何更科学、方向可控的实现 Skill 的“自进化”?
背景现如今Agent Skills 已经成为 Agent 架构中非常重要的组成部分是一种知识和工具的资源集合包Agent 的最终效果与 Skill 的质量有着极高的相关度。在Agent Skills 的发展最早期的阶段大家基本上主要就通过人工手写 Skill这就需要投入大量的精力来进行撰写、调试、优化效率较低且很难规模化。之后许多 Agent 的工具或平台都提供了各式各样的 Skill Creator通过 AI 辅助的方式去帮助用户自动生成 Skill这在一定程度上提升了 Skill 的生产效率。再后来就像我前段时间在《深度解析Hermes Agent 如何实现“自进化”及其 Prompt / Context / Harness 的设计实践》中所写的那样Agent 实现“自进化”的核心方式之一就是 “Skill 的自动沉淀”。这个核心逻辑是每执行完一轮Agent就会有 Agent 的运行轨迹Trajectory数据模型基于这个轨迹的上下文去做判断是否需要将当前的轨迹总结、沉淀为一个全新的Skill或者是否需要去更新一个已有的 Skill。这种方式可以说在很大程度上解放了人力不再需要让人完全从头写 Skill或者基于已有的 Skill 也不需要做太多手动优化的动作模型可以自动迭代从而迈向了一种更加自动化的Skill 构建新形态。然而在大家应用Hermes Agent 的过程中是不是也经常会遇到很多类似如下的问题●为什么自动沉淀的Skill质量不高对Agent 的效果帮助不大●为什么Skill 更新后反而比原来的版本效果更差了●原本精简清爽的Skill经过几次自动迭代后变的越冗长复杂、难以阅读那么今天我们就重点来探讨一下Skill 自进化中遇到的这些坑以及有哪些好的解法。Skill自进化有哪些难点使用Hermes 等目前各类 Agent 工具本身提供的方式去做 Skill 的自进化出现上述这些问题现象其实也是非常正常的。因为目前的 Skill 自我沉淀机制大部分都是基于单通Agent 对话轨迹来进行的。这意味着当前这一轮对话Session 中任务完成的效果直接决定了这个 Skill 进化的方向。如果这一轮轨迹本身存在偶然性、特殊性甚至是极端Case那么基于此生成的Skill 就有可能会**“带偏”进化的方向**。在个人场景下应用这种Skill 自动沉淀模式问题其实还不算大。因为个人用户的任务多样性比较高任务要求相对分散同一个任务再次运行或遇到完全相同场景的概率相对低一些Skill 的复用比例不高因此即使个别 Skill 进化偏差对整体体验的影响也相对有限大家可能察觉不到明显的**“降智”**。但在企业级场景中情况就完全不同了。很多企业级Agent 都是每天在线上承接同一类或多类重复任务会积累垂直领域内海量的、不同用户的Query。虽然它们虽然是同一个任务类型其运行逻辑、流程应该也是高度趋同的但由于用户 Query 之间存在差异因此 Agent 中间产生的结果不同在层层累积之后最终执行轨迹和结论也可能会有较大差异而且还会出现各类边界情况和长尾场景。如果我们简单地根据每一轮的轨迹运行情况就直接在线上进行Skill 的沉淀或更新极易导致 Skill质量“飘忽不定”稳定性大幅降低。它可能出现“一会儿变好一会儿变差”的现象甚至因为某个特定的极端 Case 而被引导至错误的进化方向导致整个 Skill 体系逐渐“跑偏”。这其实与早期的Prompt 调优也有着很大的相似性。大家可以回顾一下以前在做提示词调优的时候如果你只是简单地把badcase 丢给模型让它根据这些个案去优化提示词很容易就出现“顾此失彼”的现象。模型为了迎合当前的badcase甚至会去过拟合Overfitting把这些个例情况补进去不但导致Prompt 变得越来越臃肿、发散甚至还会破坏了原本的泛化性和通用性。这种受个例影响而不断**“找补式的优化”并不是一种好的优化方式。所以说Skill 的自进化如果缺乏科学、有效的机制单纯的基于个例轨迹来实现自动更新同样很容易让 Skill “过拟合”陷入局部情况甚至“越优化越差”**。因此在企业级的线上任务中应用Agent Skill 时我们通常不太敢让其直接实现真正意义上进行Online 的自进化。更稳妥的做法是采取Offline的优化策略比如1.离线收集轨迹数据在离线环境中收集Agent 执行轨迹手动进行 Skill 的更新、进化和维护模拟2.**人工审核与评测验证**优化后的Skill 必须经过人工审核和确认甚至很多场景会建立一套完善的回归评测体系去验证新版本的 Skill 是否真的带来了效果提升并且没有引入新的额外问题3.**灰度切流上线**只有在离线验证Skill 确认无误后才敢去替换线上的版本并且还要灰度切流持续观察效果。这种“离线优化 在线验证”的流程尽可能去保障了企业级服务的稳定性和可靠性但如果有大量的这些Skill 需要优化和验证也都每个像这样人工深度参与就严重制约生产力很难“规模化”。并且整个过程从收集轨迹数据、离线优化、评测验证整个链路非常耗时耗力。因此严格来说这种**“离线优化”并不是真正意义上的“自进化”**而是由人指导、在离线环境中进行的Agent 本身并没有具备自主判断和修正的能力核心的决策权依然在人的手中。这就引出了本文想要深入探讨的核心话题如何更科学、更可控、更保质保量的实现Skill 自进化我们追求的不再是那种“无脑”的、方向不稳定的盲目自进化而是一种能够在保证质量前提下真正释放人力、实现闭环优化的智能机制。近期我深入调研了 Skill 自进化领域的相关的论文。其中有三篇我个人认为比较有里程碑意义的论文它们代表了三种Skill 的优化思路并且这三篇论文对应的代码均已开源。对于正在探索Agent Skill 落地的和应用的同学来说这无疑是非常好的参考素材。所以本文我会对这三篇论文进行深度解析有兴趣的同学也可以深入去阅读以下论文原文以及 GitHub 上的开源代码看看哪种方案更契合自己的业务场景。Trace2Skill“归纳法”的聚合式进化第一个要介绍的论文是来自阿里千问团队的《Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills》这个项目的名字也叫Trace2Skill。从名字就能看出来它的目标就是将轨迹Trace转换为Skill同时它也直击我们前面提到的痛点单点Agent 轨迹的局限性。就像我在上文中所说的如果我们仅仅依据某一轮Agent 的执行轨迹来更新 Skill极易陷入“盲人摸象”的困境导致 Skill 的方向“跑偏”。因此Trace2Skill 的核心思路在于强化“归纳能力”。它让一支“分析师小分队”并行地看大量的Agent 执行轨迹把每条轨迹里学到的零碎经验合并成一份完整、无冲突的Skill 文档它模仿了人的工作方式先广泛积累领域知识再一次性写出一份成熟的操作手册而不是边干边改整理出一堆碎片。这个图里面左侧是传统的Online 的 Skill 自进化传入的单个轨迹的经验会按照顺序依次去更新 Skill 库里的 Skill。而右侧就是 Trace2Skill 的做法会并行去分析大量轨迹并以分层方式整合经验教训从而归纳出可泛化的、标准的 Skill。Trace2Skill 的核心实现过程可以拆解为三个关键步骤如下图所示我们就每个步骤具体来看下。轨迹生成这一步的目标是构建高质量的“数据原材料”。●初始输入给定一份初始Skill比如是S0可以是人工编写的也可以是模型生成的初始草稿●轨迹生成让Agent 通过 ReAct 的方式在一批用户任务上运行产生大量的执行轨迹。这个过程是完全可以并行的效率会比较高比如在实践中使用一个 122B 参数的 LLM 生成 200 条包含 50 个轮次的 Agent 轨迹所需时间不到两个小时●正负样本分离根据执行结果是否正确将轨迹严格划分为成功集T和失败集T−。这种分层为后续的差异化分析奠定了基础并行提案这是Trace2Skill 非常创新性的部分。它不再让一个 LLM 处理所有信息而是为每一条轨迹独立分配一个Sub-Agent 的分析师输出一个针对该轨迹的**“补丁提案”Patch Proposal。这里采用了一种不对称的角色设计策略**●Success Analyst (A) - 成功经验提取■机制针对成功集T进行分析一次性调用LLM■逻辑成功的案例通常比较容易识别和分析。分析师只需清理轨迹噪声提取出可泛化的成功行为模式直接写成补丁即可■特点高效、低成本因为成功路径往往具有较高的一致性●Error Analyst (A−) - 失败根因挖掘■机制针对失败集T−进行分析采用ReAct 多轮循环推理■逻辑失败的原因千奇百怪单次LLM 调用极易产生幻觉或误判。因此A−需要能够读取输入输出文件、对比Ground Truth并通过迭代验证假设来寻找真正的根因写成补丁■质量门控如果经过多轮推理仍无法找到明确根因该条轨迹会被直接丢弃。这确保了进入下一阶段的都是高质量、有明确改进方向的反馈■隔离性所有分析师都基于同一份冻结的初始SkillS0进行分析互不干扰。这种设计保留了观察的多样性避免了早期错误观点的相互污染无冲突归纳最后一步是将分散的补丁池p合并成一份最终的更新p∗。这本质上是一个**层次归并Hierarchical Merge**的过程●递归合并每层最多B**merge个补丁合成一个逐层递归向上直到合并为最终版本。●单一模型整个合并过程由同一个LLM 充当“合并器”负责去重、解决冲突、保留独特见解。●硬约束Hard Constraints在合并这些补丁集的时候会通过代码来做一些硬约束■引用检查如果补丁引用了不存在的文件或变量直接拒绝■冲突标记如果同一文件的同一行被多个补丁多次编辑标记为冲突并暂缓处理■格式校验最终生成的Skill 必须通过严格的格式校验器检查确保语法正确。在这种层次化的归并中如果合并器发现那些在多个补丁中反复出现的模式这就恰恰说明这是系统性问题或通用规律就会被保留并升级为通用原则而那些只出现一两次的个例的修改就很可能是个例或噪声则会被果断丢弃。这样Trace2Skill 就实现了从**“单点试错”到“群体归纳”的跨越有效地解决了Skill 进化中的被个例引导走偏从而失去泛化性问题**举个例子在我们的阿里云服务领域中如果我们打算总结某一类问题的通用解决方案比如“ECS无法远程连接”仅看1~2个工单是非常难抽象出完整的、具有普遍性的诊断思路的因为单个案例往往带有强烈的偶然性和特异性。但如果我们将这一类工单放在一起看情况就完全不同了。我们可以对大量相似轨迹进行分析、聚合从中抽取出那些符合“最大公约数”的核心内容。比如“CPU/内存跑高”、“磁盘写满”、“端口不通”、“安全组拦截”等等这些检测项才是被多次验证、高频出现的内容才是真正稳定、有价值的知识沉淀。结论与思考为了验证Trace2Skill 的有效性论文将实验放在极具挑战性的表格领域用了**SpreadsheetBench-Verified 和 WikiTableQuestions 来做为Benchmark**重点考察其泛化能力与跨模型迁移性。具体的实验数据在论文中都有大家可以去看原文因为篇幅的关系我这里写一下核心结论希望能为大家在构建自主Agent 时提供新的视角。1. 轻量级的高度可迁移方案Trace2Skill 可以把复杂的 Agent 经验打包成一份高度可迁移的 Skill不需要更新模型参数也不需要引入复杂的外部 RAG 检索模块只需要使用开源级的模型就可以完成从 Agent 轨迹中构建 Skill。2. 轨迹分析做出来的 Skill 真的能泛化Trace2Skill 的实验结果有力地挑战了一个传统假设**“经验本质上是任务特定的必须通过情景记忆Episodic Memory库检索”**的假设。实践证明通过轨迹分析提炼出的Skill 具有泛化能力是可以跨任务领域迁移的。这说明一个高质量的Skill 里的逻辑规则比零散的记忆Memory更具泛化性。3. 设计哲学像人类专家一样“先观察后总结”在方法论层面这种模仿人类专家学习路径的设计哲学还是挺有用的“先看够多 → 再写一份完整文档”。让Agent 先充分阅读和分析大量轨迹经过深度的归纳推理后输出一份结构完整、逻辑自洽的 Skill 文档。这种“批处理式”的知识沉淀往往比“流式”的反应更能捕捉到任务的本质规律。4. 一些局限性与展望当然Trace2Skill 目前的探索也不完善仍存在局限性后续可以重点突破的方向●因果贡献难以定量目前还无法精确量化Skill 中某个具体补丁Patch对最终效果提升的贡献值●使用率追踪缺失对于生成的Skill 文档还缺乏细粒度的监控手段来追踪各段落在实际运行中的真实调用率和有效性●缺乏验证机制Skill 的构造过程已经比较像人类专家了但验证还是需要人来做还不能自动验证没有自动化的验证机制就很难保证自动迭代出来的Skill 是否真的会提升EvoSkill“自验证”的自然选择如果说Trace2Skill 是通过“归纳法”将经验聚合成静态的 Skill那么EvoSkill则引入了动态的“验证”过程虽然从 EvoSkill 名字上似乎只能看出它的核心目标是实现Skill 的自进化。EvoSkill 是由 Sentient Labs 发布的一款开源 Skill 自进化项目论文标题叫做《EvoSkill: Automated Skill Discovery for Multi-Agent Systems》。从“构建 → 验证”的架构设计这种从**“构建 → 验证”机制的设计灵感就有点像武侠小说中的“左右互搏”**了也高度抽象了人类专家在离线优化Skill 时的思维过程不再依赖人工去手动构建和调试而是构建了一个由三个专用 Agent 组成的闭环系统让它们相互协作、互相验证自动完成 Skill 的分析和进化。EvoSkill 的核心在于将自进化的LLM拆解为三个角色明确的Sub-Agent了形成一个Pipline●执行者Executor负责“跑”。它基于当前待优化的 Skill去执行具体任务并产生完整的 Agent 运行轨迹和最终答案。这是进化的“素材来源”这一步和 Trace2Skill 的第一步是一样的●提案者Proposer负责“诊”。它深入分析执行者产生的轨迹判断结果是否正确。如果失败它需要精准定位问题根源并提出具体的优化方向和改进提案如果成功它也会总结有效模式。这个和 Trace2Skill 里的分析师差有点像但这里没有去做并行的轨迹分析并且EvoSkill 的分析师还会决定是新建一个Skill还是改一个已有的Skill做一个决策●搭建者Builder负责“改”。它接收分析师提出的优化建议真正动手编写或修改 Skill 文档将其落实为可执行的代码或指令规则。在这个架构之上EvoSkill 建立了一套严格的验证机制来确保每一次进化都是正向的这个是EvoSkill最核心的创新点●生成与执行搭建者完成Skill 修改后系统会在一个独立的**验证集Validation Set**上重新运行该Skill。●效果比对系统会自动比对优化前后的性能指标。只有当新Skill 在验证集上的表现确实优于旧版本时这次进化才会被确认保留。●负向反馈记录如果验证结果显示效果没有提升甚至下降EvoSkill 并不会直接丢弃这次尝试而是将这一“失败案例”记录下来。这些记录会成为分析师后续学习的宝贵数据帮助它更准确地识别哪些优化方向是无效的从而避免在未来的迭代中重蹈覆辙。进化过程的算法实现为了保证进化的方向始终朝向更优解EvoSkill 采用了一种基于“前沿集合Frontier”的迭代算法。什么叫前沿集合呢定义为G指的是一个容量固定为kk的“精英池”始终保留当前迭代中得分最高的k个程序Program。等等你可能会问这里的程序又是什么概念呢这个程序指的是Agent 能力的完整载体包括封装了的系统提示词System Prompt和累积的各种Skills 库。那么EvoSkill 的进化的过程本质上就是用更强的新程序替换池中较弱的旧程序的过程。这个程序非常像 RL 里的策略Policy如果大家了解RL 的话可能会更好理解一些。整体进化过程是一个Loop每一轮迭代t都严格遵循以下步骤来确保进化方向的正确性1.选择父代从前沿集合G中轮询选择一个父程序p确保每个成员都有被优化的机会。2.挖掘失败在训练集上运行p收集得分低于阈值的失败样本集F。若没有失败的样本则说明当前程的序已足够强大可以直接跳过本轮迭代。3.诊断提案ProposerProposer Agent 结合失败集FF和历史记录分析执行轨迹与能力差距输出文本形式的优化提案π。4.落地构建Skill-BuilderSkill-Builder Agent 将提案π具体化为候选程序p~即在父程序基础上新增或修订技能。5.严格验证在独立的预留验证集VV上评估p。若其得分高于G*G*中**最弱**的成员则*p*进入集合并取代最弱者否则丢弃。6.历史沉淀无论成败都将提案、得分及判决结果记入历史库H供后续迭代参考避免重蹈覆辙。最终经过T次迭代系统输出前沿集合G中得分最高的程序这里面的System Prompt 和 Skill 都是最优解的版本。这样做的好处是可以做正向筛选使用固定容量的前沿集合机制确保了只有真正带来性能提升的Skill 才能被保留防止无效优化导致的退化。而针对失败的尝试并非无用它们作为“反面教材”存入历史库H帮助Proposer Agent 学会识别无效的优化路径从而越进化越聪明。这个过程基本上就是将人工调试 Skill 的过程给 Agent 化了为构建具备长期自主进化能力的智能体系统提供了极具参考价值的新范式。通过这种**“执行 → 提案 → 构建 → 验证”**的闭环EvoSkill 就实现了 Skill 的自动化迭代。它不仅仅是在更新成功经验或者修补了一些失败错误更是在不断的这种验证和选择过程中让 Agent 逐渐摸索出更通用、更优的解题策略。确保了 Agent 在一个能正向提升的方向上“进化”而不是盲目进化。结论与思考EvoSkill 的核心算法其实不复杂一个里程碑式的创新就是加入了**“验证”那么这就需要我们思考一下为什么引入严格的验证机制能让Agent 的效果更可控**本质上验证就是Agent 进化过程中的“奖励函数”Reward Function。这就好比强化学习RL中的逻辑我们需要一个明确的信号来告诉模型**“什么是好的”。在EvoSkill 中验证集上的得分就是这个信号。它也像梯度下降中的损失函数**一样指引着Skill 优化的方向。如果没有这个可量化的“导航仪”Agent 的迭代就会陷入盲目。1. 从“体感”到“量化”打破不可持续的瓶颈很多Agent 开发者在初期构建 Agent 时依赖的是“人的体感”——我觉得这个 Prompt 改得更好了我觉得回答更流畅了。在个人场景下靠体感没问题因为你就是唯一的用户和裁判。但在企业级场景下靠体感是**不可持续且无法规模化Scaling**的。当任务复杂度上升人的主观判断会出现偏差甚至产生“我觉得写得很清楚但模型理解有误”的认知错位。如果没有一套客观、可量化的验证机制如自动化测试用例、代码执行通过率等我们就无法区分是**“Skill 本身的质量下降”还是“线上环境的其他因素导致了指标波动”**这种模糊性会导致迭代变得盲目且不稳定。只有通过严格的验证我们才能自信地说“我的 Skill 质量确实提升了”或者精准定位问题所在。2. 可验证性决定迭代速度数据飞轮的关键不知道大家有没有发现尤其是进入2026年后的这几个月Claude Ops、GPT、Qwen 等头部 LLM 迭代和发布速度越来越快之所以这些 LLM 能以月甚至以周为单位快速迭代其中一个比较核心原因就在模型效果的衡量越来越可验证。例如AI Coding 场景代码能否跑通、单元测试是否通过这些都是验证成本较低且结果比较客观的场景。如果每次迭代都需要大量人工标注或主观评估则迭代周期久会被无限拉长。其实Agent 也是同理构建一套高质量、自动化的验证评估体系才是Agent 效果能“起飞”的前提。一旦验证闭环打通数据飞轮才能真正转动起来从“Agent 产生轨迹” → “自动化验证给出即时反馈” → “根据反馈快速调整 Skill”→ “新 Skill 再次进入验证循环”。只有在这样的模式下迭代速度才能从“人力驱动”转变为“算力驱动”实现质的飞跃。反之若缺乏可验证的标尺任何优化都可能是原地踏步甚至南辕北辙不进反退。SkillOpt将 Skill 进化对标为“模型训练”如果说EvoSkill 是通过“自验证”式和优胜劣汰来进化那么 SkillOpt 则走了一条更硬核的路线它将Skill 的优化过程直接对标为LLM的参数训练过程。SkillOpt 是由微软公司联合上海交大、同济、复旦等多所高校一起提出的 Skill 优化新范式论文标题叫做《SkillOpt: Executive Strategy for Self-Evolving Agent Skills》最近讨论的热度也比较高我也认为这是一个新的里程碑式的项目。以后这类基于文本的优化过程应该也会像模型权重的训练一样越来越标准化和科学化。Skill 是“外部可训练参数”在传统的深度学习范式里模型主要是通过梯度下降Gradient Descent不断更新模型的权重Weights以最小化损失函数。而SkillOpt 则创造性地提出了一个类比把**“Skill 文本”类比为“模型权重” 把“基于反馈的文本重构”类比为“梯度更新” 、把“LLM 驱动的改写引擎”类比为“优化器Optimizer”。**在这种视角下Skill 不再仅仅是一段静态的提示词而被视为一种**“外部的、可训练的文本参数”。**SkillOpt 引入了一个专门的“优化器 Agent”它像 SGD 或 Adam 优化器一样根据验证集上的表现即“Loss”不断地对 Skill 文本进行微调、重写和迭代直到收敛到一个高质量的状态。上图是SkillOpt 的一个概览图。目标模型利用当前Skill 执行任务一个额外的前沿优化器模型将Agent 轨迹转化为有界的添加、删除、替换 Skill 的编辑操作一个 hold-out 的门控机制仅接受那些能提升验证集效果的修改。被接受的修改会被导出为可复用的Skill而被拒绝的修改则作为负面反馈用于后续的更新。那SkillOpt 为什么这样做呢传统的 Prompt 优化往往依赖于人工调试缺乏明确的方向感。而 SkillOpt 通过引入“训练范式”带来了两个关键优势●方向明确每一次Skill 的修改都是基于明确的“误差信号”即验证失败的原因。这就像梯度指向了损失函数下降最快的方向SkillOpt 让文本优化也有了明确的“梯度”这个逻辑和 EvoSkill 的“验证”思路其实是一样的。●系统化迭代它摒弃了零敲碎打的修补而是将整个Skill 作为一个整体对象进行系统性优化。这种“端到端”的训练思维使得 Skill 的结构更加紧凑、逻辑更加自洽。同时还引入了文本领域的**“学习率”Learning Rate**能够控制每次Skill 优化的粒度也就是文本修改的比重。六大核心组件详解为了将“Skill 即参数”的理念落地SkillOpt 设计了六大核心组件和工作流程。这套流程严格对标深度学习中的训练范式从数据收集、梯度计算、参数更新到验证 gating每一步都经过精心设计以确保 Skill 优化的稳定性和高效性。SkillOpt 整体的流程如下图所示冻结参数的目标模型利用当前 Skill 执行一批 Rollout优化器模型对成功和失败案例进行小批量的反思提出有界的添加、删除、替换优化操作在预定的编辑额度下对这些操作进行合并和排序并且仅通过预留的 hold-out 验证门控机制来接受候选 Skill。在各个 epoch 中慢速、元更新在不改变目标模型的情况下保留更长视野的经验教训。具体的细节我们展开来看下。1. 前向传播证据收集Forward PassRollout Evidence就像模型训练需要先进行前向传播以获取LossSkillOpt 的第一步是让目标模型在训练集上执行任务。这个其实和 Trace2Skill、EvoSkill 的第一步都是一样的先生成 Agent 轨迹●**批量执行**默认以Batch Size40 运行一个 rollout batch。●**全量记录**不仅记录最终答案还完整捕获任务上下文、消息历史、工具调用、观察结果、验证器反馈以及Harness 特定的元数据如表格预览、文档引用、执行 Trace 摘要等。●**解耦设计**支持累积多个Batch 后再统一进行反思实现了“执行节奏”与“更新节奏”的解耦提升了工程灵活性。2. 反向传播小批量反思Backward PassMinibatch Reflection这就是SkillOpt 的“梯度计算”环节。优化器模型Optimizer接收前向传播产生的轨迹并进行结构化分析。这个和 Trace2Skill、EvoSkill 的分析、提案的步骤基本上也是一样的但更加细节●分组与分片将轨迹分为“成功”和“失败”两组并进一步切分为 Minibatch默认大小 8。●为什么用Minibatch单个轨迹容易导致过拟合产生过于具体的修补Over-specific Fix而 Minibatch 能暴露反复出现的程序性错误Procedural Errors从而提炼出更具通用性的规则这个有点类似Trace2Skill 多个Batch聚合过程。●原子化编辑每个Minibatch 产出一组结构化的原子编辑操作比如追加、添加、删除、替换等。●层次化合并先分别合并Failure 和 Success 组的编辑建议最后再做全局合并且遵循“Failure 优先于 Success”的原则确保优先解决致命问题。3. 学习率约束有界文本更新Bounded Text UpdatesLearning Rate Constraint这是SkillOpt 与传统“无约束 Prompt 重写”最大的区别也是其稳定性的核心来源。●核心创新每一步迭代只允许L**t条编辑生效。这相当于深度学习中的**学习率Learning Rate**控制控制的越细节迭代越慢也越容易陷入局部最优解但是控制太粗又可能跳出全局最优解。●避免灾难性遗忘无约束的重写容易清掉原有有用规则、引入逻辑冲突或过拟合到局部失败案例。通过限制编辑数量SkillOpt 确保了更新的平滑性。●调度策略支持Cosine默认、Constant、Linear和 Autonomous 四种调度方式。默认的 Cosine 策略从大步长开始逐渐收敛模拟了模型训练后期的精细调优过程。●编辑模式默认采用Patch 模式局部微调也可切换为 Rewrite 模式整体重写。4. 验证门控 负反馈缓冲Validation Gate Rejected-Edit Buffer这一步对应模型训练中的“验证集评估”但引入了更严格的准入机制●严格优于才接受候选Skill 必须在独立的验证集 *Dsel上运行只有当得分严格高于*当前最优Skill 时才被接受平局也被拒绝防止性能抖动。●负反馈价值化被拒绝的编辑并不会被丢弃而是连同其导致的分数跌幅一起存入Rejected-Edit Buffer。这些“失败教训”会被喂给后续的优化器帮助它理解哪些修改方向是危险的从而避免重蹈覆辙。这将流程从“无条件自我编辑”升级为严谨的Propose-and-Test优化闭环。5. 慢更新 元更新动量机制Epoch-Wise Slow/Meta Update为了捕捉长期趋势并维持知识稳定性SkillOpt 引入了类似训练里的动量Momentum的机制。●四类样本归因每个Epoch 结束时用同一批训练样本分别在“上一 Epoch Skill”和“当前 Skill”下重跑将结果归为四类Improvements提升、Regressions退步、Persistent Failures持续失败、Stable Successes稳定成功。●受保护区域更新优化器会将纵向的指导原则写入Skill 中的受保护区域常规的步级编辑无法修改这部分内容确保了核心逻辑的稳定性。●Meta-Skill维护一份仅对优化器可见、不随Skill 部署的“元记忆”记录“哪些编辑模式好用”、“哪些被频繁拒绝”、“哪些失败一直未解决”从而指导优化器自身的策略调整你可以理解为这是“调优Skill 经验的 Skill 的经验”套娃了。6. Harness 无关部署Harness-Agnostic Deployment最后SkillOpt 强调了工程落地的简洁性与通用性是 Harness 无关的●轻量适配通过轻量级适配器接口同一套优化器逻辑可以无缝运行于直接对话、Codex CLI、Claude Code CLI 等多种执行 Harness 框架。●极简产物最终的部署产物仅仅是一个best_skill.md 文件通常300 ~ 2000 Tokens不包含任何复杂的依赖或外部模块。这种“纯文本、零依赖”的特性使得 Skill 极易移植、版本管理和大规模分发。通过这六大组件的协同工作SkillOpt 成功地将非结构化的文本优化问题转化为一个可控、可解释、可迭代的类训练过程为 Agent 能力的自动化提升提供了一套标准化的解决方案。结论与思考从最后的效果上来看在SkillOpt 论文中所对比的这些benchmark上来看SkillOpt 的效果是更好一些的。当然在实际场景上还是需要各位同学用的时候进一步做测试和验证。下面主要总结一下SkillOpt所带来的创新●Skill 应当被像参数一样训练——SkillOpt 是首个系统性、可控的文本空间优化器。●关键设计边界化的学习率、验证gate、rejected-edit buffer等都被消融实验证明是必需的。●产物是真正可部署的best_skill.md 是个三百到两千token 的小文档可以跨模型、跨 harness、跨任务迁移。●**不足的地方**只自进化调优了best_skill.md 这个单Skill文档对于其他的文件比如 References 里的Markdown文件或者 Resources 中的脚本代码等文件没有考虑到自进化中。并且没有考虑跨领域的 Skill 库等等。三者的对比最后在介绍完这三个Skill 自进化的论文之后我们来做一个总体的对比让大家更加清晰明了的看到他们的区别。Trace2Skill归纳推理学派●核心假设好的Skill 应该来自对大量轨迹的归纳单条轨迹的教训不可靠●关键动作并行处理 层次化合并●类比就像专家开会大家分头看不同案例然后开会合并意见“被多人提到的”才进最终报告●**优势**一次成型效率高最终Skill 简洁可读●**风险**合并器要够强否则会丢细节EvoSkill自验证选择学派●核心假设Skill 应该慢慢长出来每轮针对一个具体失败提出改进能跑赢前沿集合就保留●关键动作前沿集合 失败驱动提案 累计反馈历史●**类比自然选择进化**每一代基因有突变产生新Skill适应度验证分数高的才能延续下来●优势自然生长出一个Skill 库每个Skill 都对应一个具体的失败模式可解释性更强。●**风险**每轮只改一处收敛慢、需要不少迭代不同轮次跑的结果差异大。SkillOpt训练优化器学派●核心假设Skill 应该被像神经网络参数一样训练要有严格的约束来保证稳定收敛。●关键动作学习率约束 验证 gate 负反馈 buffer 元学习●类比带momentum early stopping 的 SGD每步只动一点点被拒的更新留作负样本每轮epoch 做长期巩固。●**优势**可控性最强每个组件都有明确的解释并且与神经网络学习对标●**风险**组件太多并且强依赖一个稳定的验证集和打分函数更多的对比细节我通过这个表格列出来吧写的也不一定全也是按照我个人的理解来的对比项Trace2SkillEvoSkillSkillOpt优化对象单份 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只给优化器看沉淀调优经验执行 HarnessReAct 即可需要底座 HarnessChat / Codex / Claude Code 等 Harness 无关模型分离同一模型自给自足同一模型扮演三个角色优化器、目标模型 分离总结最后再次回顾这三种范式我们实际上见证了Agent Skill 进化正在从“经验主义”走向“科学工程”路径Trace2Skill是归纳法的代表它通过“由点及面”的思维将分散的单点轨迹提炼为通用的核心思考解决了从 0 到 1 的快速启动问题。EvoSkill是自动化离线Pipeline的进阶它引入了“分析-验证-更新”的闭环让 Skill 具备了基于反馈的自进化能力解决了静态规则无法适应动态场景的痛点。而SkillOpt则是训练范式的极致体现它在验证的基础上引入了学习率、动量等更科学的约束机制通过小步迭代和严格门控实现了效果的可控性与稳定性最大化。那么哪种方案最好呢虽然论文的实验数据给出了部分场景中的测试结果但实际业务场景决定了最终选择。整体来看引入验证机制的方案会优于纯归纳方案因为后者在验证的过程中会引导Agent 不断走向了进化的正确方向。但同时随着方法复杂度的提升计算成本和迭代周期也在显著增加。因此还是需要根据实际业务情况来决策使用哪种方案●如果你的场景相对简单追求快速落地并且规律性比较明显Trace2Skill 的性价比可能最高。●如果你对Skill 的效果有明确要求且拥有完善的自动化评估体系那么 EvoSkill、SkillOpt 就更适合。●也许混合策略可能是比较好的解法比如用Trace2Skill 快速生成基线用 EvoSkill 持续扩充技能库再对核心瓶颈模块使用 SkillOpt 进行精细打磨。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】