Agent自进化系列（五）——Skill什么时候才算进化：从一次生成到持续维护

上一篇讨论了经验怎样被保存、调用和修正。当一套方法在工作中被反复使用，我们就会尝试把它整理成可复用的技能，供后续任务直接调用，也就是现在满天飞的skill。

记忆可以保存事实、经历，也可以保存操作方法，但每次使用都要检索，或者把整份记忆带回上下文。Skill 则把这些方法组织成可按需加载的技能，还可以附带脚本和参考资料。我把这种变化称为“经验开始拥有执行权”：同一份做法从供参考变成可调用。入口、触发和加载都挂在 Skill 上，经验是被装进去的内容。是否调用、怎样执行，仍由 Agent 和运行系统决定。

以出报告的日期规则为例，Agent 连续几周都靠汇总之前先统一日期这个经验完成任务，所以我们可以把它整理成 Skill，附上解析脚本。项目一直都问题，直到换一家供应商，`03/04/2026` 是月在前，脚本仍按日在前。表顺利跑完，没有报错，却把 3 月 4 日解析成了 4 月 3 日....

所以，Skill 不是 Memory 的替代品。它是记忆里更结构化、可执行的一类，skill同样也要被检索、验证、更新和淘汰。

一、封装一条 Skill，也是在固定一组假设

“统一日期”听起来很通用。但真要把它交给后面的任务反复调用，马上会遇到具体问题：哪个字段是日期？年月和日的顺序由谁提供？原始值能不能覆盖？解析不出来时，应该猜一个结果，还是停下来？

边界就是这些问题的答案。Skill 如果只记下先统一日期，下次再跑时，字段是哪一列、月日谁在前、解析失败该停还是该猜，都还要现场再决定一遍。能力并没有真的被定住。

以Agent Skills 开放格式为例，下面这份日期 Skill 的简化说明，就遗漏了来源格式与歧义处理：

--- name: normalize-dates description: 汇总报表前，先把日期列统一为同一格式 --- 做按日或按周汇总时，先识别日期列，解析后写成 YYYY-MM-DD，保留原列。

即使说明里没有显式声明输入输出约定，配套脚本也可能已经固定了一组假设：它认哪一列、按日在前还是月在前、解析失败是跳过还是猜一个。这些往往不在 SKILL.md 里，而在默认参数里。下一张表踩中其中一个，不管对不对，任务都会跑完。

一条记忆可以只记上次这家供应商用了日在前。整理成 Skill 之后，这些默认值可能被沿用到后续调用中。抽象既要去掉偶然细节，也要保护那些决定做法是否成立的条件。

Skill、Memory、Tool 和 Workflow 在这里有交叉，边界取决于系统怎样实现。为了讨论方便，可以把 Memory 理解为供检索和参考的经验，把 Skill 理解为可复用的能力包。Tool 提供一次操作的接口，Workflow 组织多步任务；Skill 可以调用工具，也可以被工作流组合起来。它可以存放在记忆系统中，但不能仅凭存放位置判断它扮演什么角色。

MUSE-Autoskill: Self-Evolving Agents via Skill Creation, Memory, Management, and Evaluation

MUSE给出了一个比较具体的能力包形态：除了说明文件，还可以包含脚本、测试，以及这个 Skill 自己的调用记忆。创建、记忆、管理、评测、精炼被放进同一个生命周期，底座模型不必修改权重。

其中的“每个 Skill 自带记忆”这个点比较有意思。如果日期规则总在某种来源上失败，这段记录就应该能对应到具体技能及其使用情况。否则系统只知道“报告做错了”，很难判断该修哪一项能力。

MUSE 的实验也暴露了能力资产的两个维度：做出来的质量，以及能覆盖多少任务。在它使用的 SkillsBench 覆盖子集上，自造 Skill 得到 85.24%，人工 Skill 为 81.17%；但还有 28 道题没有可用的自造 Skill，实验中直接计为 0 分，所以拖低了全量结果。

所以，高质量的几个skill和可依赖的整个库之间，隔着覆盖问题。比如报表 Agent 可能特别擅长清洗日期，却对币种、退款和跨表连接没有形成相应能力。只挑有 Skill 的任务展示，就会把这种缺点藏起来。

这套生命周期管理提供了维护和操作的入口，但是如何稳定保留条件、补全覆盖、维护整个技能库，还需要独立证据。至少从实验结果只能证明能覆盖到的skill是有收益的。

二、提炼得更简洁，为什么反而更不会做

还是用出错的供应商表举例，最初的成功轨迹里，Agent 可能执行的流程：查看来源说明，确认日在前，抽查两个样例，再开始解析。提炼成 Skill 后，却只记录下对日期列使用日在前的解析器。

步骤精简了，但是关键前提也丢了。

我认为这里比较难的是分清：哪些是下次必须要做的检查，哪些只是这次碰巧成立的结论。查看来源、抽查样例，属于前者；日在前属于后者，不该写成对所有表的默认。模型在提炼 Skill 时，如果只留下好记的结论，就可能把检查细节删掉。步骤变短、读起来更通用，不等于分对了。

SkillEvolBench ：Benchmarking the Evolution from Episodic Experience to Procedural Skills

SkillEvolBench 评测了这类问题：经历抽成 Skill、库冻住之后，换题还能不能做。它不逐条核对哪次删掉了哪条检查。基准包含 180 道题、6 类环境。Agent 先在一组学习题上依据轨迹与反馈写入、修改 Skill；然后吧技能库冻结，再到另一组未曾用于生成这些 Skill 的题目上，只允许检索与调用。后一组里，有的只是换了数据或场景，有的故意给出一条抄近路但不成立的做法，有的必须把几条 Skill 接起来用——对应的是变了场景还是否有效、会不会走捷径、能不能组合。

对照包括人工整理的 Skill，以及由独立于执行环的 Skill Author 根据轨迹摘要生成的 Skill。还有一条基线不写 Skill：把学习阶段的执行过程压成摘要，供后来检索。摘要里有那次怎么做的，但没有抽成一条可复用的步骤。底座模型与执行环境保持不变，变化的是上下文。

在基于经历生成并修改了Skill 后，Claude Opus 4.6 相比不使用 Skill 的baseline，学习题成功率提高 5.5 个百分点；冻结技能库后重做同一批学习题，提高 10.0 个百分点。但在没参与生成的相关新题上，总体成功率从 37.8% 降到 32.2%。其中，情境变化与组合任务的成功率下降，抗捷径指标持平。

将同一段经历压缩为执行摘要、不写成 Skill，冻结后相关新题的平均成功率为 37.6%，是各对照最高的，这是跨模型配置的平均值，自生成 Skill 的均值未超过基线。说明执行摘要中可能保留了抽象后的skill没能保留的重要信息。

这些实验结果说明，抽成 Skill 时可能丢失后续任务仍需要的上下文线索。 在日期例子中，这种损失可能就是“确认来源、检查歧义”等步骤。当然，具体一次掉点到底由什么造成，还是要回到执行轨迹判断，不能仅凭成功率变化认定是某一步被删掉了。

但是写得更勤、往技能库里再塞更多脚本和参考资料，也不等于把检查这些信息留住了。SkillEvolBench 还有一组设定，要求更强制地写入。Gemini 3 Flash 在强制更新并附加资源的自生成实验中，冻库后新题成功率为 27.8%，还是低于不使用 Skill 时的 35.6%。这说明增加资源并不保证迁移效果改善；是否引入了任务特例、冗余指引或调用困难，还需要结合轨迹诊断。

人工写好的SkillsBench 里，人工整理的 Skill 能把平均通过率从 33.9% 提到 50.5%。而让 Agent 只从一次经历里就能自己写：下次还要做哪些检查，去判断哪些只是这次碰巧成立的结论是很困难的。

三、每条 Skill 都能用，整个库仍可能用不好

假设日期 Skill 已经修好，Agent 还学会了按周汇总、合并附件、剔除退款，每条单独运行都能得到正确结果。后来，报表接入了带时间戳的交易明细，日期 Skill 也扩展为处理时区。

可一组合，报告仍可能出错：日期 Skill 将北京时间的交易时间转换为 UTC，按周汇总却把输出直接当作本地时间分组。北京时间星期一凌晨的交易，就可能被算进上一周。两个包各自遵守自己的约定，交接处却不兼容。

这就是把 Skill 当作能力资产之后，绕不过去的系统问题。一个库的收益取决于有哪些能力，还取决于任务来了能否选对、输入能否绑定正确、输出能否接给下一条。

从选择调用到交接，同一份报告的失败可以停在不同位置：

分类的用途很直接：同样是Skill 导致任务失败，需要修改的对象可能完全不同。 若是误触发，扩写内部步骤甚至可能加重问题；若是输出约定冲突，再给两个skill各跑一遍独立单测，也未必能发现组合错误。

SkillEvolBench 把抗捷径与组合从学习题里拆出来，在冻库后的相关新题上单独计分，正是因为在原学习题上重做成功，不能回答这些问题。它没有证明上表每一种故障出现的频率，却提醒我们：评估的单位需要从“一条 Skill”扩展到“Skill 被放进任务后怎样工作”。

这也解释了为什么我们不认同把自动写 Skill直接等同于能力增长。假如新增十条功能近似的日期技能，Agent 面对的选择反而更困难。检索命中一个看起来相关的skill，不代表它适用于当前数据，更不代表它能和已有步骤兼容。

好的技能库需要足够清楚的差异：这一条处理什么，另一条补什么，两者在哪里不能混用。这里已经有了类似软件组件管理的问题了，只是许多接口变成了自然语言，兼容性检查也变得更难。

时区错配时，该改的是日期 Skill 的输出约定，以及它和按周汇总之间的组合测试。再扩写一条功能近似的日期 Skill，只会让选择更困难。若把这次局部判断立刻写成后续所有任务的默认，故障还会扩散到原本正确的场景。

四、一次修改，不应该默认可入库

报表出了错，Agent 很容易写下一条修正：今后所有日期都转成 UTC。如果这句话立刻进入正式技能，后续任务就会继承这次判断。一个局部故障，可能因此扩散到原本正确的场景。

所以我们需要区分两件事：提出修改，以及让修改成为后续默认行为。前者需要发现问题的能力，后者还要承担兼容性和回归责任。

如果问题全部由人发现、修改由人编写并决定是否采用，它仍然是人工维护技能。本文讨论的自进化，是让系统从任务轨迹与反馈中提出候选修改，再由评估机制决定是否保留。人工可以参与审核；关键是经验能否进入持续的更新闭环，并改善后续任务。

EvoSkill:Automated Skill Discovery for Multi-Agent Systemsl

EvoSkill把这种分工落实为三个角色。Executor 执行任务并留下轨迹；Proposer 读取轨迹与标准答案，分析失败并提出新建或修改建议；Skill-Builder 负责构建技能文件夹，是其中能写入 `skills/` 的角色。写出来的还是候选。它们要在没参与生成的验证集上打分；比当前保留版本里最弱的一条更强，才能进入后续默认，否则丢掉。

这篇论文的启发是，失败分析可以保留为提案，没必要立即变成执行者必须遵守的规则。候选之间也应保留trace，便于解释为什么引入、从哪个版本修改、失败后退回哪里。

EvoSkill 在 OfficeQA 的一个配置上，将准确率从 60.6% 提升到 67.9%。从 SealQA 学到的技能迁移到 BrowseComp 的 128 题评估中，还有 5.3 个百分点的提升。这说明从失败中构造可复用 Skill 存在成功路径。

但 Proposer 能看到标准答案，是这条路径的重要条件。真实报表任务里，Agent 往往只有业务方说数不对，没有现成的正确结果。论文中的角色分工值得借鉴，失败诊断所需的监督信号却不能凭空获得。

把这一点和前面的故障分类连起来，工程选择会更具体。遇到时区错配，提案应说明修改哪个接口、影响哪些调用者；Builder 生成相应候选；评估覆盖原来的场景以及受影响的组合。这里的验证是在决定一次能力变更能否进入后续执行链，而不仅是给生成文本打一个质量分。

更进一步，反馈也应该落到具体版本和使用情境。如果日志只写调用日期 Skill，报告成功，后来很难解释某个版本是否改善了结果，也无法判断新版本破坏了哪些原本有效的行为。

五、技能库的价值，有时来自撤掉一条规则

技能库库一旦开始自动生长，需要回答的问题就不只是怎么再写一条。

前面的日期 Skill，本来只是一套短流程：识别日期列，看来源，解析，写回。几个月后，根据业务需求很快会出现优先日在前，某供应商月在前，先统一时区 ，附件继承主表设置等信息。有的写重了，有的只对某一家导出格式成立，有的会盖住后来更可信的来源说明。短流程里的关键检查不能随意删除；去掉看来源，日期解析就可能失去依据。真正该问的，是后贴上去的那些段落还在不在贡献。

成功时加载过它，不等于因为有它才做对。只会增加的技能库，过一段时间就会变成检索噪声。遗忘、降权、合并，不是维护的附属动作，是进化的一部分。

SkillProx

SkillProx将修改与收缩纳入同一个过程，不更新模型权重，而是修改技能说明。前向阶段提出补丁后，必须在同一批任务上重跑验收；表现退步就回滚，并把这次结果留给后续诊断。判断听起来合理，还不足以让修改生效。

后向阶段审查积累的内容。它按二级标题和参考文件划分单元，在固定验证集上比较暂时移除一个单元前后的表现，再对候选修改逐项复验，决定合并、降级或删除。有时可以删去整节，有时则要去掉写死的特例，把仍然有用的原则合并进保留章节。收缩的目标是减少无效或有害内容，同时保住任务表现。

论文用一个概念目标同时看两件事：题要做对，文本不能无限变厚。

\min_X J_λ\mathrm{(} X\mathrm{)=} L_{\mathrm{T}}\mathrm{(} X\mathrm{)+} λG\mathrm{(} X\mathrm{)}

X表示技能文本，，L_{\mathrm{T}}\mathrm{(} X\mathrm{)}表示使用它完成任务时的期望损失，G\mathrm{(} X\mathrm{)}用生效文本的字符数衡量复杂度，λ表示复杂度项的权重。实现时，论文通过整题全对率和单元格准确率衡量表现。这个公式用于解释优化方向，并不意味着对技能文本求导或更新模型参数：前向尝试减少任务错误，后向在验证约束下收缩内容。

后向审计更接近一次对照。其余条件尽量不变，只拿掉单元 u，用 S 表示当前技能内容， S_{\mathrm{−} u}表示移除该单元后的内容，以越高越好的任务得分衡量贡献：

差值为负，拿掉之后验证集更好，这段就可能在拖后腿。SkillProx 的一个案例中，系统删掉写死的任务模板，并将可迁移原则合并到保留章节，文本缩短 3.12%，独立评测的整题全对率从 46% 升到 54%。另一组从人工稿出发的实验中，Qwen3.6-27B 在 SpreadsheetBench 上从 36.7% 到 54.5%。数字属于各自设定，不能理解成任意技能库删一段都会涨分；它们表明，内容减少和能力改善可以同时发生。

这次对照说明一件事：在这批题、这份稿上，拿掉某一段会不会更好。它不能证明这段对以后所有任务都多余。验证集没覆盖到的约束，删了当时看不出来；旁边文字改过之后，同一段也可能重新变得必要。按标题整节切掉也会切错，有用的主节旁边可能挂着有害的参考。按段落往下剥，是给已经写厚的技能用的。

对日期技能来说，撤掉失效的猜测规则，保留来源约定和歧义出口，可能比继续补充例外更有效。系统学到的不只是更多做法，还有哪些旧做法应该停止。

六、多更新几轮，能力就会持续变好吗

技能库有了反馈和修改机制，很容易让人产生一种期待：再运行一轮，再多看一些反馈，能力就会继续变好。

反馈当然有用。失败记录能帮助系统定位能力边界在哪里失效。可又更新了一轮本身不是收益。这些变化有时增加内容，有时减少内容，有时只收窄触发范围。它们共同调整的是：在什么条件下，系统能够可靠地做什么。但这些修改是否有效，需要逐轮验证；只增加轮次，并不会自动变成持续提升。

Rethinking Self-Evolving Agent Skills

在每个模型与基准组合中，固定修改方法、验证规则和轮次预算，只改变优化器能看到的反馈：成败都看、只看失败、只看成功。优化器一共写出 388 份候选，其中只有 55 份在验证集上超过了当时最好的那份。14 个设定中，验证筛选在 11 个设定中选中了更新后的技能，其余 3 个保留原版本。这 11 个全部来自包含失败轨迹的反馈条件；只看成功的条件没有被选中。

这 11 个更新后的技能中，9 个在公开测试集上也获得提升，稳健性和迁移同时改善的只有 7 个。在这组实验里，更新收益是稀疏的，验证集上的最佳版本也未必在其他评估中全面占优。

论文还比较了额外采样的作用。在 GPT-5.5 的测试中，若允许事后从多次采样中完美选出正确结果，SearchQA 上的成绩已接近更新后的 Skill，所以看起来是不用沉淀skill多跑几次也能达到同样的效果；但在所测试的预算范围内，SpreadsheetBench 上仍落后约 31 个百分点。

不同任务从额外采样中获得的收益是不同的，评估技能更新时，也需要区分持久的skill改进与当前任务上增加搜索的效果。

所以，多更新几轮，能力就会持续变好吗？不会。 反馈有用，尤其是失败；但有效更新是稀疏的，而且有的涨点只是多试几次，不能都算进化。

结语：写进库是开始

我们希望看到的 Skill 自进化系统，能回答这样的问题：“这次失败需要新能力，还是现有能力被用错了？”“应该修改实现，还是缩小适用范围？”“新增内容和哪条旧规则冲突？”“哪项能力已经可以退役？”

缺少可靠反馈时，应该先把修改留在候选区，不直接加入技能库。成功轨迹可以提供可复用步骤，失败轨迹则帮助发现适用边界；两者最终都要接受后续任务的检验。

现在再看每周报表 Agent，成长可以很具体：从默认猜测格式，变成主动看来源；从只输出一列结果，变成解析不清就停；从各条单独正确，变成时区对得上；从只加补丁，变成能撤掉失效的猜测。这不一定让技能库变大，却让系统更清楚自己能做什么、什么时候该停下来。

Skill 把可复用的步骤变成可以加载、调用、组合的东西。这种明确的封装，也容易让人误以为能力已经形成。我们不应该把Agent 会写 SKILL.md写成自进化。我会看技能库冻结后换一张表是否仍然有效，更新失败后能否回滚，多运行一轮是否改善了能力的适用边界。写进库是开始。后续任务稳定变好，才接近成立。

当出报告的日期规则真的过了这些门，它才从库里多了一条变成以后还靠得住。当然agent并不满足于只改 Skill，好需要去改调度这些 Skill 的控制逻辑。那是下一篇的问题：Agent 改自己，究竟在改什么。