EvoSkill: A New Paradigm for Self-Evolving AI Agents
Overview
当通用编码代理进入专业任务后,性能瓶颈往往不再只是底层模型能力,而是缺少可复用、可触发、可组合的任务经验。手工编写技能(Skill)可以补上这层能力,但这种做法高度依赖人工经验,难以覆盖不断扩张的任务空间。
EvoSkill: A New Paradigm for Self-Evolving AI Agents 讨论的就是这个缺口。论文不再直接优化提示词、也不直接修改底层代码库,而是把“技能”本身作为进化对象:代理先在任务上暴露失败样本,再由提案器分析失败原因,最后由技能构建器把高层建议写成结构化技能目录,包括触发元数据、SKILL.md 指令文件,以及可选的脚本或参考材料。
这篇工作的价值不只是把技能自动写出来,而是把代理改进问题重新定义为一种更高层的程序搜索问题。论文中的“程序(program)”由系统提示词和技能库共同组成,底层模型参数始终冻结;系统通过验证集上的 Pareto 前沿(Pareto frontier)筛选出真正有用的候选程序。这样得到的改进更像一组可审计、可迁移的工作流,而不是只对单一模型和单一任务有效的脆弱补丁。
Motivation
现有代理优化方法大致有两类。一类是提示词优化,另一类是直接改写代码。前者实现成本低,但通常和具体模型、具体任务分布强绑定;后者表达力强,但搜索空间巨大,修改结果也不一定容易复用。两类方法都很难自然产出“可复用能力单元”。
技能抽象更接近工程实践。一个技能可以明确声明何时触发、应该遵循怎样的步骤、是否需要调用脚本,以及脚本的输入输出约定。这种表示天然支持渐进式加载:系统启动时只读元数据,真正用到时再打开详细指令,必要时再执行辅助脚本。也正因为这个接口已经存在,论文才有空间把“自动发现技能”作为独立研究对象,而不是把技能当作提示词搜索的副产品。
论文的另一个切入点是失败驱动。多数代理任务不是“完全不会做”,而是会在一小批模式上稳定犯错,例如表格抽取时取错相邻单元格、开放网页搜索时过早停止、数值推导时遗漏校验步骤。与其在所有样本上平均优化,不如先找出低分样本,再围绕这些失败模式生成专门技能。这个思路延续了有监督学习里的误差分析,但最终产物不是新的权重,而是新的能力模块。
Problem Formulation
论文正文没有把整个系统写成统一的数学目标,这里给出一个基于算法描述的形式化重述,并明确标注为对原文的整理与推演。
设监督数据集为:
其中 $x_i$ 是任务输入,$y_i$ 是标准答案,另外给定任务相关的打分函数 $r(\hat y, y)\in [0,1]$。EvoSkill 中的一个代理程序记为:
这里 $\sigma$ 表示系统提示词,$\mathcal{K}$ 表示当前技能库。底层模型权重不变,进化真正修改的是 $\mathcal{K}$,在某些配置下也可以同时修改 $\sigma$。论文的默认重点放在技能演化上。
在第 $t$ 次迭代中,从训练池采样一批样本 $\mathcal{B}_t$。如果程序 $p_t$ 在某个样本上的得分低于阈值 $\tau$,该样本会被加入失败集:
这一步的含义很直接:EvoSkill 不对“所有行为”做统一总结,只对“明确失败的行为”做定向诊断。若 $\mathcal{F}_t=\varnothing$,本轮迭代直接跳过。
接下来,提案器根据失败集 $\mathcal{F}_t$ 和历史反馈日志 $\mathcal{H}_t$ 生成一个技能提案 $\pi_t$;技能构建器再把提案变成候选程序 $\tilde p_t$。这条更新链可以写成:
候选程序在验证集 $\mathcal{V}$ 上得到分数:
系统维护一个容量为 $k$ 的前沿集合 $\mathcal{G}_t$。若候选程序优于当前最弱成员,就把它放入前沿:
这里的 $\operatorname{TopK}$ 表示按验证分数保留前 $k$ 个程序。最终返回的是整个前沿里分数最高的程序,而不是最后一次迭代的结果。
如果把这几步连起来看,EvoSkill 优化的并不是单次回答,而是“失败模式 $\rightarrow$ 技能提案 $\rightarrow$ 结构化技能文件 $\rightarrow$ 新程序”的离散搜索过程。这个抽象是全文最重要的部分。
Methodology
Framework Overview
EvoSkill 由三个代理角色组成。
第一类是执行器(Executor Agent)。它承担真正做题的工作,使用当前程序里的系统提示词和技能库完成任务。
第二类是提案器(Proposer Agent)。它查看执行轨迹、预测答案、标准答案,以及已有技能,判断错误究竟来自缺少哪个工作流、哪个校验步骤,或者已有技能需要怎样修改。论文特别强调,标准答案只用于失败诊断,不会原封不动写进生成出来的技能。
第三类是技能构建器(Skill-Builder Agent)。它把高层提案具体化成技能目录,包括触发元数据、SKILL.md、以及可选的 Python 或 Typescript 脚本。构建器本身还带有一个元技能,用于约束技能编写风格,使输出更像可运行资产,而不是随意文本。
这三个角色的分工,使 EvoSkill 的优化对象从“句子级反馈”变成了“可执行能力模块”。这也是它与普通提示词反思式更新(reflection)方法的本质差异。
Failure-Driven Proposal
提案器的输入不是抽象分数,而是失败样本对应的执行过程。这样它可以判断错误到底出在检索、解析、计算还是最终作答阶段。
历史反馈日志 $\mathcal{H}_t$ 在这里很关键。它记录先前所有提案、验证分数和是否被前沿接受。论文给出的作用有两个:
- 避免重复提出已经失败过的技能思路。
- 在已有提案部分有效时,沿着相同方向继续细化,而不是每轮都从零开始。
这让搜索过程更像带记忆的定向搜索,而不是独立同分布的随机试错。实际含义是,EvoSkill 并不假设一次失败分析就足够好,它允许技能经历“先写出来,再修正,再筛掉”的生命周期。
Skill Materialization
论文把技能定义为一种文件系统级资产,而不是上下文里的临时文本片段。一个技能目录通常包含三层内容:
- 触发元数据:告诉代理什么情况下应该读取这个技能。
SKILL.md:给出流程、检查项、输入输出格式和决策规则。- 辅助脚本或参考文件:在需要精确计算、数据变换或格式化时提供可执行支持。
这个设计直接继承了 Agent Skills 技能生态里已有的“渐进式披露(progressive disclosure)”思路。元数据在启动时加载,完整说明在触发后加载,脚本只有真正执行时才会运行。因此,即便技能库不断增长,代理也不需要把所有详细说明都塞进上下文窗口。
这一步还有一个经常被忽略的工程意义:技能是可以审计的。相比“把系统提示词再改长一点”,技能目录更容易追踪来源,也更容易做版本控制、单独测试和人工复查。
Frontier Search
EvoSkill 不是单链式自改进,而是前沿搜索。论文维护一个固定容量的程序前沿,每一轮从前沿里轮转(round-robin)选择一个父程序,而不是永远只从当前最优程序继续扩展。
这个策略有两个直接效果。
一是避免过早收敛。如果搜索始终围绕单一最优程序展开,系统容易在一条局部最优路径上越走越深;轮转选择可以让多个演化分支并行探索不同失败模式。
二是让技能具备谱系结构。论文的实现里,每个程序对应一个独立的 git 分支,分支只在技能目录和元数据上与父分支不同。这样一来,验证分数的差异更容易归因到新增或修改的技能,而不是其他环境噪声。
这部分可以按原文算法继续拆开。若记父程序得分为 $s(p)$,候选程序得分为 $\tilde s_t$,则接受规则是:
只有当候选分数超过当前前沿最弱成员时,它才会留下来。于是前沿更新本质上是一个带容量约束的保优操作,而不是无条件累积技能。这个机制解释了为什么论文强调“技能不断增加”,但又不会让所有发现都永久保留。
Why Skill-Level Search Transfers
论文最值得注意的观点是,技能级搜索比提示词级搜索更容易迁移。原因不是技能一定更强,而是技能的接口更稳定。
提示词优化通常直接把任务分布、模型习惯和措辞技巧耦合在一起。一旦底层模型换了、工具接口换了、任务目标换了,原来最优的提示词可能立刻失效。技能则不同:它把能力写成显式触发条件和程序化步骤,例如“遇到歧义词时先列出所有解释”“做时间序列分析前先对齐时间粒度并执行通胀调整”。这些规则本质上是工作流知识,而不是语言表面模式。
因此,EvoSkill 的真正贡献不是证明技能一定比提示词更优,而是证明“把优化对象上移到技能层”后,系统更有机会得到跨任务保真的能力模块。论文后面的零样本迁移实验就是这个论点的直接证据。
Experiments
OfficeQA 是一个建立在美国财政部公报上的 grounded reasoning(有依据推理)基准,数据源大约覆盖 8.9 万页文档,问题需要跨文档定位表格、图表和文本,再做数值推导。论文把它当成“文档解析 + 数值计算”型任务。
实验使用 Claude Code with Opus 4.5。按照论文的数据切分策略,验证集固定为 17 个样本,训练集分别取 5%、10%、15%,即 12、24、36 个样本,每组进化 1.5 个 epoch。这里有一个非常醒目的结果:10% 训练数据已经把精确匹配率从 60.6% 提高到 65.8%,继续加到 15% 反而回落到 64.5%。这说明 EvoSkill 并不单调依赖更多失败样本,技能搜索也会出现边际收益递减,甚至轻微过拟合。
论文还报告了一个“合并唯一技能”的配置:把独立运行中发现的不同技能合并到同一个技能库里,精确匹配率达到 67.9%。表格里对应数字写成 68.1%,正文与图注使用的是 67.9%。无论取哪个值,结论都一致:不同演化分支找到的技能具有互补性,前沿搜索得到的分支并不只是互相替代,也可能在后期进行组合。
更重要的是,论文给出的技能实例确实具有很强的可解释性。一个技能围绕 Treasury 表格抽取与核验,另一个技能围绕经济时间序列分析,明确要求做通胀调整、线性回归、输出格式规范化和计算前检查点。这样的产物更像资深分析员写下来的工作流程,而不是模型偶然学到的一段隐式偏好。
SealQA 测的是搜索增强问答,难点不在长文档解析,而在开放网页环境里存在噪声检索、互相冲突的来源和容易过早停止搜索。
在这个基准上,EvoSkill 只使用 10% 训练集、运行 1.5 个 epoch,就把准确率从 26.6% 提高到 38.7%,绝对提升 12.1 个百分点。这个增幅比 OfficeQA 更大,说明失败驱动的技能发现并不局限于结构化文档场景。
论文提到的代表性技能是 search-persistence-protocol。这个技能不是给代理更多搜索工具,而是约束搜索行为:遇到歧义词先做术语扩展,再执行多来源交叉验证,再检查枚举是否完整,最后才允许下结论。换句话说,EvoSkill 学到的不是“去哪搜”,而是“什么时候还不能停”。对开放网页任务来说,这种程序纪律往往比多一个提示词技巧更有用。
论文最强的一组证据来自零样本迁移。作者把在 SealQA 上演化出来的 search-persistence-protocol 直接迁移到 BrowseComp,不做任何修改,准确率从 43.5% 提高到 48.8%,绝对提升 5.3 个百分点。
这个结果说明技能并没有严格过拟合到 SealQA 的题目形式。它迁移的是一个更抽象的能力:在事实型检索问题上,坚持把搜索做完、把歧义拆开、把来源对齐,再决定答案。只要目标任务仍然需要这个能力,技能就能继续工作。
从研究角度看,这也是全文最重要的实验信号。它表明 EvoSkill 发现的对象不是只对单个基准有效的临时技巧,而是更接近“可搬运的工作流知识”。
EvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verification
Overview
当代理开始处理开放式专业任务后,困难往往不在于“会不会调用工具”,而在于“能否把一整套多步流程稳定执行出来”。一个工具通常只暴露单一函数接口,而一个技能(Skill)则需要把工作流说明、可执行脚本和领域参考材料打包成可复用资产。这也是为什么同样拥有工具访问权限,代理在复杂任务上的表现仍然会高度不稳定。
EvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verification 试图解决的就是这个问题。论文认为,人工编写技能不仅成本高,而且常常存在人机认知错位:人类专家觉得自然的说明结构,并不一定是代理在受限上下文和执行环境里最容易利用的形式。相比上一篇更偏向“从失败样本中发现技能”的 EvoSkill,这篇工作把对象进一步收紧到“多文件技能包”的自动生成与迭代修复。
EvoSkills 的核心设计是共演化。系统不只让一个技能生成器反复改技能,还同时维护一个代理验证器(Surrogate Verifier),后者在看不到隐藏标准测试内容的前提下,自主生成代理测试断言、输出诊断并逐步提高测试强度。技能生成器和代理验证器在同一闭环里交替推进,使系统既能获得密集反馈,又不至于直接泄露真实测试细节。
Motivation
这篇论文的出发点非常明确。SkillsBench 的评测已经显示,人工整理的技能并不稳定:有些领域提升明显,有些领域几乎没有增益,甚至会让结果变差。论文把这种现象解释为人机认知错位,也就是技能文档的组织方式更适合人类阅读,不一定适合代理执行。
第二个问题是表示粒度。已有自演化方法大多围绕工具、函数 API 或提示词模板展开,而技能包本身是跨文件的组合对象,既包含 SKILL.md 这样的流程说明,也包含脚本、参考资料和可调用函数。针对单函数设计的自演化方法很难直接迁移到这种结构。
第三个问题是反馈来源。真实环境里通常拿不到完整的 ground-truth test(真实标准测试)内容,代理最多只能得到一个通过或失败的信号。如果只有这种稀疏反馈,系统很难判断错误到底来自技能文档缺漏、脚本 bug,还是测试覆盖范围不够。EvoSkills 的回答就是把“生成技能”和“生成代理测试”一起优化。
Problem Formulation
论文把任务环境形式化为一个部分可观测马尔可夫决策过程(POMDP):
这里 $X$ 是底层状态空间,例如完整文件系统和进程状态;$A$ 是代理动作,包括终端命令和文件编辑;$T(x’ \mid x,a)$ 是确定性状态转移;$O$ 是观测空间;$\Omega(o \mid x,a)$ 把后继状态映射到部分观测;$R(x_T)\in[0,1]$ 是终止时对输出文件的隐藏评分。由于代理看不到完整状态,它只能基于历史 $h_t=(o_1,a_1,\ldots,a_{t-1},o_t)$ 行动。
技能 $S$ 作为条件输入影响代理策略:
在这个定义下,论文把技能质量写成终止奖励的期望:
最终目标是找到最优技能:
但这个目标不能直接优化,因为真实评分 $R$ 只会返回一个不透明的通过或失败结果。为此,论文引入代理验证器生成的断言集合 $V={e_1,\ldots,e_{|V|}}$,并定义代理奖励:
这一步等于把“隐藏评分”替换成“可诊断的断言平均通过率”。EvoSkills 真正要解决的,就是如何让 $\tilde{R}$ 尽量逼近隐藏的 $R$,同时又不泄露真实测试内容。
Methodology
Method Overview
EvoSkills 由两个主角组成:技能生成器(Skill Generator)和代理验证器(Surrogate Verifier)。技能生成器负责生成和修改技能包,代理验证器负责根据任务说明和当前输出构造断言、执行验证并返回结构化错误信息。
整个循环可以概括成三步。第一步,技能生成器产出一个技能版本 $S^{(i)}$,并在环境 $E$ 中执行,得到输出工件 $x^{(i)}$。第二步,代理验证器用当前测试套件 $V^{(j)}$ 去评估这些工件,计算代理奖励 $\tilde{R}(x^{(i)},V^{(j)})$。第三步,若代理测试失败,则直接把失败诊断反馈给技能生成器;若代理测试全部通过,但真实标准测试仍然失败,则只返回一个不透明的通过/失败位(pass/fail),并要求代理验证器自己升级测试强度。
论文把这种结构称为 co-evolutionary verification(共演化验证)。它的重点不在多加一个评判器(judge),而在两个对象各自承担不同职责:技能生成器学习如何修技能,代理验证器学习如何更接近隐藏测试。
Skill Generator
技能生成器的难点在于,多文件技能包几乎不可能一次写对。为了解决这个问题,论文让生成器维护一个持续累积的上下文 $C$。初始上下文由任务说明 $I$ 和一个通用元技能 $S_{\text{meta}}$ 组成,这个元技能本质上是在教代理“如何创建技能”。
每一次迭代后,若代理验证器发现失败,它就会输出一个结构化诊断 $F^{(i,j)}$,其中包含失败断言、根因分析和具体修改建议。技能生成器把这些诊断追加回上下文:
这里的 $\oplus$ 表示把反馈拼接进上下文。于是,技能修复不再依赖模糊的自我反思,而是基于一组失败断言逐轮定向修改。论文算法中还设置了上下文占用阈值 $\beta=0.7$,防止持续累积的反馈把上下文窗口耗尽。
Surrogate Verifier
代理验证器承担的是更微妙的工作。真实标准测试 $R$ 只会告诉系统“过了”还是“没过”,不会说明为什么。因此系统需要一个替代评分器来提供稠密反馈,但这个评分器又不能简单复用技能生成器本身,否则容易出现自证正确的偏差。
论文的做法是把代理验证器放到完全独立的 LLM 会话里。它只看任务说明 $I$、当前输出 $x^{(i)}$ 和自己上一轮的测试脚本 $V^{(j)}$,看不到技能生成器的思考过程、技能内容和代码草稿。作者把这称为 information isolation(信息隔离)。
在这种约束下,代理验证器会生成一个由确定性断言组成的测试套件,并在失败时额外给出诊断。形式上,它的更新规则写成:
这个更新不是每轮都触发。只有当当前技能已经通过代理测试,但真实标准测试仍然失败时,系统才判定“代理测试太弱”,从而要求代理验证器继续升级断言覆盖面和难度。
Alternating Optimization
论文把整个循环整理成两个交替目标。第一个是技能修复:
第二个是测试升级:
这里 $\Phi(S,E)$ 表示把技能 $S$ 在环境 $E$ 中执行得到输出,$\hat{x}^{(i)}$ 则是把同一个技能放到新的干净环境中重新执行后得到的结果。干净重执行的目的,是防止技能在当前环境中偶然依赖中间状态或缓存。
如果把这套机制展开,逻辑会很清楚:
- 代理验证器失败时,说明当前技能有明显缺口,此时固定测试套件,优先修技能。
- 代理验证器通过但真实测试失败时,说明问题不一定在技能,也可能在代理测试太松,此时固定技能,优先加强测试。
- 真实测试永远只暴露最小信息量,也就是一个 pass/fail 位,防止系统直接朝着隐藏测试过拟合。
这也是论文与普通 self-reflection(自我反思)方法的最大区别。后者通常只改答案或改提示词,而 EvoSkills 同时在改“技能包”和“验证器”。
Why Multi-File Skills Matter
论文一再强调,技能不是提示词模板,也不是单函数工具。一个合格技能包至少需要覆盖三层对象:
SKILL.md中的工作流说明和检查表。scripts/中可直接导入的函数或程序。- 可能存在的参考文件、样例或结构化说明。
这种多文件结构的意义在于,代理不必每次都从自然语言中重新实现逻辑。论文附录里的案例研究很典型:在人类整理的技能里,许多关键领域规则只是埋在长文档里的几句话;而自演化后的技能会把它们固化成函数、参数约束和明确的调用顺序。换句话说,EvoSkills 不是把说明写得更长,而是把说明压成代理更容易执行的形状。
Experiments
实验基于 SkillsBench,包含 87 个任务、11 个专业领域,并为每个任务提供确定性验证器。论文用 pass rate(通过率)作为主指标,也就是任务是否完整通过全部隐藏测试。
主要比较对象包括:无技能基线、SkillsBench 自生成技能、链式推理引导的自生成技能、Anthropic 的 skill-creator、SkillsBench 提供的人类整理技能,以及 EvoSkills。主实验使用 Claude Opus 4.6 + Claude-Code,另一个自演化主干是 GPT-5.2 + Codex。每个主要方法跑 5 次独立实验,跨模型迁移实验跑 3 次。
在 Claude Opus 4.6 + Claude-Code 上,EvoSkills 的通过率达到 71.1%,相对无技能基线 30.6% 提升 40.5 个百分点,也明显高于人类整理技能的 53.5%。相比之下,SkillsBench 的单次自生成技能是 32.0%,链式推理版是 30.7%,Anthropic 的 skill-creator 是 34.1%。这组结果说明,性能提升并不是来自“让模型先写点技能”这件事,而是来自后续的共演化验证闭环。
论文还给出 GPT-5.2 自演化结果,达到 69.8%,与 Claude Opus 4.6 非常接近。也就是说,这套框架并没有绑定某一个特定前沿模型。
消融实验直接揭示了代理验证器的作用。去掉代理验证器后,通过率从 71.1% 降到 41.1%;保留背景知识但不做技能演化时,通过率只有 48.6%。这意味着“知道更多背景”本身不够,真正有效的是把知识变成结构化技能包,并用外部验证器不断纠错。
论文还分析了演化过程本身。第 0 轮也就是没有验证闭环的一次性生成,表现大致和无技能基线接近;到第 2 轮提升到 44%,第 3 轮达到 63%,已经超过人类整理技能,第 5 轮收敛到 75%。平均来看,每个任务需要 4.1 次验证循环,其中只有 2.4 次会真正升级到真实标准测试,这说明代理验证器承担了大量中间筛查工作。
跨模型迁移是这篇论文最强的一组证据。用 Claude Opus 4.6 演化出来的技能,直接迁移到 6 个额外模型上,全部带来 35 到 44 个百分点的提升:GPT-5.2 从 29.6% 提高到 65.0%,Claude Sonnet 4.5 从 20.0% 提高到 63.1%,Claude Haiku 4.5 从 10.4% 提高到 54.5%,Qwen3 Coder 从 8.4% 提高到 50.8%,DeepSeek V3 从 13.0% 提高到 48.8%,Mistral Large 3 从 4.9% 提高到 43.1%。
领域分析同样重要。EvoSkills 在 11 个领域中的 9 个超过人类整理技能,尤其在 Finance、Cybersecurity 这类需要程序纪律和多步校验的任务上优势更大。论文特别指出 Natural Science 领域里,人类整理技能甚至会拖后腿,而自演化技能却显著提升结果,这正是人机认知错位的直接证据。
AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution
Overview
如果把前两篇文章放在一起看,会发现一个共同前提:系统默认已经处在“任务执行”场景里,问题是如何发现技能、如何验证技能、以及如何让技能更像一个可复用工作流。AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution 往前又退了一步,它关注的不是某个 benchmark 上的任务通过率,而是更日常也更长期的问题:用户在多轮互动中不断重复表达稳定偏好,但这些偏好通常只被当作对话上下文,而不会沉淀成可复用能力。
AutoSkill 的核心主张是把交互经验从“记忆”提升为“技能”。系统不是简单地保存历史对话片段,也不是修改底层模型参数,而是从对话和交互轨迹中抽取出显式技能卡片,用统一的 SKILL.md 结构维护它们,并在未来请求里按需检索和注入。这样做的目标,是把短期对话中的偏好、写作约束、流程习惯和纠错经验,变成可长期保留、可编辑、可合并、可迁移的外部能力层。
这篇论文和前两篇最不同的地方在于,它强调的是 training-free(训练无关)与 model-agnostic(模型无关)部署。整个系统被设计成一个可插拔层,挂在现有 LLM 或服务前面即可运行,不需要微调模型,也不要求代理必须工作在复杂工具环境中。
Motivation
现有长期记忆方法大多把历史经验当作“需要被检索的文本”,例如用户偏好、过去对话、事实片段或摘要。这样的设计能改善上下文恢复能力,但它并不会自动把经验整理成行为规则。结果就是,用户每次还要重新说明同样的写作要求、语气要求或者流程禁忌。
另一条路线是自演化或参数更新。它们可以通过自反思、偏好优化或自训练逐步改变模型行为,但这类方法往往成本高,而且不适合频繁、细粒度、强个性化的在线调整。尤其当用户偏好本身就是可变又需要人工监督的对象时,把所有变化都沉入参数里,既不透明,也不易控制。
AutoSkill 想做的是中间层。它既不像记忆系统那样只存文本,也不像模型更新那样直接改参数,而是把重复出现的行为模式抽象为技能工件。这样一来,经验累积的单位不再是原始对话记录,而是可执行、可维护的行为知识。
Problem Formulation
论文把单个用户 $u$ 的完整对话历史定义为:
其中 $q_t$ 表示第 $t$ 轮用户输入,$r_t$ 表示模型回复。系统在每轮后维护一个用户级技能库 $B_u^t$。
每个技能被表示为一个七元组:
这里 $n$ 是技能名,$d$ 是描述,$p$ 是可执行指令提示,$\tau$ 是触发词集合,$\gamma$ 是标签集合,$\xi$ 是示例集合,$v$ 是版本号。这个定义很重要,因为它说明 AutoSkill 讨论的不是抽象 latent skill(隐式技能),而是一个带元数据、可直接落文件的外部对象。
论文还明确强调,系统是训练无关的:部署时不更新模型参数,只通过五个提示驱动模块工作。设提示集合为
对应的模块集合为
其中最后一个 $M_{\mathrm{emb}}$ 是嵌入模型,用于技能向量化和检索。这意味着系统优化发生在推理时组合层,而不是参数层。
Methodology
Two Coupled Loops
论文把系统拆成两个耦合回路。左边是 skill-enhanced response generation(技能增强回复生成):当前请求进入后,系统先改写查询,再从技能库里检索相关技能,最后把技能上下文注入回复模型。右边是 skill evolution(技能演化):当前轮交互结束后,系统尝试从用户侧输入里抽取可复用技能,并决定是新增、合并还是丢弃。
这个拆分非常关键。它把“用技能回答问题”和“从互动中长技能”分成两个不同时间尺度的过程。前者服务于当前回复,后者决定长期能力积累。
Query Rewriting and Retrieval
在回复阶段,系统先把当前输入 $q_t$ 和最近对话历史 $h_t$ 改写成一个更适合检索的独立查询:
论文给这个模块的要求很明确:如果当前轮是同一任务的延续,就保留旧任务锚点并只追加新约束;如果发生话题切换,就替换掉旧锚点;若输入只包含风格或格式约束,则要从最近历史里补全缺失任务锚点。这样做是为了把对话里的省略指代转成检索友好的查询。
随后,系统对每个技能同时计算 dense semantic score(稠密语义分数)和 BM25 lexical score(词项匹配分数):
由于两种分数不在同一尺度,论文先把它们归一化,再线性融合:
最后保留分数高于阈值 $\eta$ 的 top-$K$ 技能:
这一步的含义是,AutoSkill 不会盲目把整个技能库都塞进上下文,而是只注入少数高相关技能。它本质上是一个带阈值的混合检索系统,而不是简单的向量召回。
Skill-Conditioned Generation
被选中的技能会先被渲染成一个紧凑上下文块:
再与当前查询和近期历史一起送进回复模型:
这里的关键不是公式本身,而是系统策略。论文明确要求回复模型把技能当成“可能相关的外部行为上下文”,只有在直接匹配用户当前意图时才使用它;如果无关,就忽略技能正常作答。这样做是为了避免技能注入带来过度偏置。
Skill Extraction from User Interaction
AutoSkill 最有辨识度的设计,是技能抽取阶段只使用 user queries(用户输入),而不把模型回复当作抽取证据。若记截至第 $t$ 轮的用户输入序列为:
则技能候选由抽取模块生成:
输出形式为
其中新增的 $c$ 是置信度。论文这样设计的理由很直接:系统想学的是稳定用户需求,而不是模型自己刚说过什么。若把模型回复也当作技能证据,就容易把错误策略或偶然输出固化进技能库。
抽取提示还明确规定了几个筛选原则:只抽 durable constraints(持久约束)、reusable procedures(可复用流程)、task-specific policies(任务策略)和 recurring corrections(反复出现的纠正);一次性请求、泛化价值低的内容、助手臆造细节都不应该变成技能。
Retrieval-Assisted Skill Management
新抽到的候选技能并不会直接写入技能库。系统先把它和已有技能做局部比对,而不是全库推理。具体做法是先根据候选技能自己的名称、描述、触发器和指令重写出一个管理查询,再和已有技能计算管理阶段相似度:
取最相近的近邻集合 $N_t$,并找到最相近技能 $s_t^*$。随后由一个单独的 judge 模块做三分类决策:
这一步本质上是在做 repository hygiene(技能库卫生维护)。如果没有这个环节,系统会不断往库里堆重复技能;如果一味合并,又会把不同能力混在一起。
Versioned Merging
若决策是 merge,系统不会简单拼接文本,而是做版本化更新:
版本号通过一个 bump 操作增加:
对应的技能库更新规则可以写成分段形式:
这个规则解释了 AutoSkill 的“持续演化”到底是什么意思。系统不是不断产生新的 prompt fragment(提示碎片),而是让已有技能在同一 identity(能力身份)下累积修正,形成版本链。
Experiments
这篇论文的实验风格和前两篇明显不同。它没有把重点放在下游任务通过率,而是围绕 SkillBank 的规模、分布、版本演化和案例分析做经验研究。作者使用 WildChat-1M 数据集,只保留超过 8 轮的对话,再按照语言和模型家族切成四个子集:Chinese GPT-3.5、English GPT-3.5、Chinese GPT-4、English GPT-4。
在这四个子集上,系统共抽取出 1858 个技能。具体规模分别是:Chinese GPT-3.5 子集有 5912 段对话、134670 条消息、400 个技能;English GPT-3.5 子集有 10243 段对话、267681 条消息、631 个技能;Chinese GPT-4 子集有 1145 段对话、36834 条消息、224 个技能;English GPT-4 子集有 5211 段对话、157508 条消息、603 个技能。论文还指出 GPT-4 子集平均对话轮数更长,说明更长的真实互动更容易形成稳定技能。
从标签分布看,最常见的技能标签依次包括 python、javascript、excel、c++、creative writing、formatting、pandas、education、translation 和 matlab。按类别统计,Programming & Software Development 最多,有 482 个技能;Writing & Content Creation 为 363 个;Data & AI/ML 为 354 个;General / Mixed 为 356 个;Systems / DevOps / Config 为 194 个。这说明 AutoSkill 的技能抽取结果确实高度集中在高频生产型场景,但并不局限于编码,写作和沟通相关能力也占了相当比例。
论文还统计了平台相关技能元数据,发现 Twitter/X 和 Instagram 的相关技能最常见,其次是 YouTube,而 Douyin/TikTok、WeChat OA、LinkedIn、小红书和微博出现得相对少。这一点说明 AutoSkill 抽到的不是纯抽象偏好,而是会附着到真实平台运营与内容生产环境中的操作习惯。
更有意思的是版本号本身被当作演化证据。论文展示了一个英文技能 professional_text_rewrite,版本号已经达到 0.1.34,说明它在初始创建后经历了 34 轮增量优化;而一个中文技能“顶级心理咨询师”仍停留在 0.1.0。这两个例子揭示了 AutoSkill 的一个性质:技能演化速度并不一致,越是高频、重复、标准化的能力,就越容易反复触发合并和版本更新;越是小众、低频、偏情境性的技能,则可能长期停留在早期版本。
案例研究也很能说明它的抽象边界。中文案例“顶级心理咨询师”抽到的是一种支持性对话风格,要求温暖、专业、有同理心、尊重隐私、避免医疗诊断和药物建议。这类技能更多是在固化 interaction style(互动风格)和 safety boundary(安全边界)。而英文案例 professional_text_rewrite 则是高度程序化的写作技能:它要求重写英文文本、提升专业性和语法质量、严格保留事实和意图、禁止解释、禁止附加评论、禁止多版本输出。论文把这两个例子并列起来,是为了说明同一套技能表示既能承载柔性的行为偏好,也能承载刚性的任务规则。
如果从研究方法上评价,这些实验更接近“系统有效性与可行性展示”,而不是严格的 end-task benchmark(终端任务基准)比较。论文真正证明的是:在大规模真实交互数据中,AutoSkill 确实能稳定抽出多语言、多领域、可版本化的技能工件,并让这些工件呈现出持续演化而不是简单堆积的特征。
SKILLRL: Evolving Agents via Recursive Skill-Augmented Reinforcement Learning
Overview
如果说前两篇更关注“如何把技能做成外部资产”,AutoSkill 更关注“如何把长期交互沉淀成技能层”,那么 SKILLRL: Evolving Agents via Recursive Skill-Augmented Reinforcement Learning 讨论的是另一类问题:技能一旦存在,能否直接进入强化学习(Reinforcement Learning,RL)训练闭环,成为策略优化的一部分,而不只是推理时外挂上下文。
这篇论文的出发点是现有 memory-based agent(基于记忆的代理)大多仍在存原始轨迹。这样的记忆虽然看起来保留了经验,但轨迹通常很长、很吵、包含探索和回退动作,模型很难从中直接抽出高层可迁移规律。SKILLRL 的核心想法是先把经验蒸馏成技能,再让技能库和策略一起演化。
因此,这篇工作的关键词不是单独的“检索”或“技能包”,而是 recursive co-evolution(递归共演化)。技能库不再是静态外部知识源,而是随着 RL 训练不断吸收新失败案例、生成新技能、修正旧技能,和策略参数一起向前更新。
Motivation
论文针对的是一个很具体的缺口。记忆系统虽然能把过去的成功案例或失败案例带回当前上下文,但它们通常还停留在“压缩后的经历”层面,而不是“可执行原则”层面。模型看到的仍然是过去某次怎么做,而不是在更一般条件下应该遵守什么策略。
这会带来两个问题。第一,原始轨迹冗长且噪声高,真正有价值的决策点被包在大量环境交互细节里。第二,即便模型能看到这些轨迹,它也不一定知道如何把这些经验转成行动规则,更不用说把这些规则内化到新任务上。
SKILLRL 的回答是做三步抽象。先把成功与失败轨迹分别变成 demonstration(成功示范)和 failure lessons(失败教训);再把这些蒸馏结果组织成分层技能库 SKILLBANK;最后通过冷启动监督微调和 GRPO 训练,让模型真正学会“何时取技能、如何用技能”,并在训练过程中继续扩充技能库。
Problem Formulation
论文把代理和环境的交互写成标准序列决策问题。在时间步 $t$,代理观察到 $o_t \in O$,采取动作 $a_t \in A$,得到奖励 $r_t$ 和下一观测 $o_{t+1}$。一条完整轨迹记为:
任务由自然语言描述 $d$ 给定。带技能上下文的策略写成:
其中 $c$ 表示附加上下文,例如技能、示范或记忆。论文的目标是在上下文长度约束下最大化期望回报:
SKILLRL 采用 GRPO(Group Relative Policy Optimization,组相对策略优化)作为底层 RL 优化器。对同一个查询 $x$ 采样 $G$ 个响应后,GRPO 先得到奖励 ${R_1,\ldots,R_G}$,再构造组内标准化优势:
接着用 PPO 风格的 clipped objective 更新策略:
其中
这套公式本身并不新,新的部分在于 skill-augmented context(技能增强上下文)被直接放进策略条件里,并且这个技能上下文会在训练中继续变化。
Methodology
Experience-based Skill Distillation
论文第一步不是直接做 RL,而是先收集环境 rollout 产生的轨迹,并把成功轨迹 $T^+$ 与失败轨迹 $T^-$ 全部保留下来。与很多只留成功样本的方法不同,SKILLRL 认为失败轨迹同样重要,因为它暴露的是边界条件和典型错误模式。
随后,教师模型 $M_T$ 对两类轨迹做差异化蒸馏。成功轨迹被转成可复用技能:
失败轨迹则不直接塞进上下文,而是先被压成简洁的 failure lessons:
论文明确要求这些失败教训至少包含四部分:失败发生在哪里、错误动作或错误推理是什么、正确做法应该是什么、如何用更一般的规则避免类似错误。这样做的本质,是把“坏例子”从冗长历史改写成反事实技能。
Hierarchical SKILLBANK
蒸馏后的技能被组织成一个分层技能库 SKILLBANK。它分成两层:
- General Skills(通用技能)$S_g$:跨任务类型通用的探索、状态管理、目标跟踪原则。
- Task-Specific Skills(任务特定技能)$S_k$:某一任务类别里的专门流程、约束和常见故障规避规则。
完整技能库写成:
推理时,通用技能总是保留,而任务特定技能通过语义检索选出。论文把检索规则写成:
这里 $e_d$ 和 $e_s$ 分别是任务描述和技能的嵌入表示,$\delta$ 是相似度阈值。于是,真正用于行动决策的策略变成:
论文特别强调,技能蒸馏后相对原始轨迹可以达到 10 到 20 倍的 token 压缩,同时信息密度更高。这说明它要优化的不只是效果,还包括上下文预算。
Cold-Start SFT
一个看起来很朴素但其实很关键的问题是:即便给了技能,模型也未必天然知道怎么用。论文认为,直接把技能库喂给一个未经适配的基座模型,收益会很有限。
因此,在 RL 之前,SKILLRL 先做一个 cold-start SFT(冷启动监督微调)阶段。教师模型生成一批技能增强推理轨迹:
然后用交叉熵损失训练初始策略:
这一步的作用不是追求最终性能,而是先让模型学会一个技能使用范式:先检索,再解释,再执行。后面的 RL 才能在这个基础上继续强化。
Recursive Skill Evolution
SKILLRL 最核心的部分是递归技能演化。论文认为静态技能库不可能覆盖后续训练中所有新出现的失败模式,因此在每个验证周期后,系统会检查不同任务类别的成功率 $\operatorname{Acc}(C)$。只有当某个类别的成功率低于阈值时,才对该类别启动技能扩展。
具体做法是收集验证阶段失败轨迹 $T_{\mathrm{val}}^-$,并交给教师模型结合当前技能库继续产出新技能或修正建议:
随后直接更新技能库:
这里的关键不是公式,而是训练逻辑。失败轨迹不只是用于更新参数,还会生成新的外部技能;而新的技能又会立刻参与下一轮策略训练。于是参数更新和知识库更新形成一个正反馈循环。
RL with Skill-Augmented Context
在正式 RL 阶段,对每个任务描述 $d$,模型先检索技能,再采样 $G$ 条完整轨迹 ${\tau^{(1)},\ldots,\tau^{(G)}}$。每条轨迹得到二值成功奖励:
然后按照 GRPO 计算归一化优势:
最终的优化目标写成:
其中重要性比率是:
和普通 GRPO 相比,唯一但关键的差异是这里整个轨迹概率都条件化在检索到的技能上下文上。也就是说,技能不只是提示辅助,而是显式进入策略分布本身。
Experiments
实验覆盖两类环境。第一类是交互式代理环境,包括 ALFWorld 和 WebShop;第二类是搜索增强问答,共 7 个数据集,包括单跳的 NQ、TriviaQA、PopQA,以及多跳的 HotpotQA、2Wiki、MuSiQue 和 Bamboogle。基座模型用的是 Qwen2.5-7B-Instruct,技能蒸馏和 SFT 数据生成的教师模型用 OpenAI o3。
在 ALFWorld 和 WebShop 上,SKILLRL 明显超过所有对比方法。ALFWorld 总成功率达到 89.9%,WebShop 成功率达到 72.7%。直接对比其底层优化器 GRPO,ALFWorld 从 77.6% 提升到 89.9%,绝对提升 12.3 个百分点;WebShop 从 66.1% 提升到 72.7%。如果看更强的 memory-augmented RL 基线,SimpleMem+GRPO 在 ALFWorld 是 62.5%,在 WebShop 是 46.9%,仍明显低于 SKILLRL。论文还指出,在 PickTwo、Cool、Heat 这类多步状态跟踪任务上,提升更大,分别约为 23%、22% 和 15%。
这篇论文一个很醒目的结果是,小模型通过技能增强训练反超大闭源模型。带 SKILLRL 的 Qwen2.5-7B-Instruct 在 ALFWorld 上比 GPT-4o 高 41.9 个百分点,也比 Gemini-2.5-Pro 高 29.6 个百分点。这个结果并不意味着 7B 模型全面强于闭源大模型,而是说明在长程交互和技能复用场景里,“会不会从经验中抽象出高层策略”有时比纯参数规模更重要。
在搜索增强问答上,SKILLRL 也拿到最优平均分 47.1%,高于 Search-R1 的 38.5% 和 EvolveR 的 43.1%。其中最突出的点是多跳任务 Bamboogle,SKILLRL 达到 73.8%,相对 EvolveR 的 54.4% 高出 19.4 个百分点。论文用这个结果说明,分层技能对多步信息整合尤其有帮助,因为它提供的是稳定搜索策略,而不是单次检索痕迹。
消融实验进一步把主要贡献拆开。去掉分层结构后,ALFWorld 从 89.9% 降到 76.8%,WebShop 从 72.7% 降到 61.4%;用原始轨迹替代技能库时退化更大,ALFWorld 只剩 61.7%,WebShop 为 50.2%。去掉 cold-start SFT 之后,ALFWorld 掉到 65.2%,WebShop 掉到 46.5%,说明“教模型如何使用技能”本身是必要步骤。最后,如果保留静态技能但去掉动态演化,ALFWorld 从 89.9% 降到 84.4%,WebShop 从 72.7% 降到 70.3%,说明递归演化带来的提升没有前面几个模块那么夸张,但确实在持续提高性能上限。
论文还给出三个动态统计。第一,技能库从初始的 55 个技能增长到训练末期的 100 个,其中 general skills 从 12 增到 20,task-specific skills 从 43 增到 80,说明增长主力来自任务专门技能。第二,和基于原始轨迹的记忆方法相比,SKILLRL 的平均 prompt 长度下降约 10.3%,说明技能抽象确实缓解了上下文膨胀。第三,加入递归技能演化后,ALFWorld 上 60 个训练 step 就能超过 80% 成功率,而不带演化的版本要到约 90 个 step 才接近更低的峰值,这说明动态技能库同时改善了收敛速度和最终上限。
SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks
Overview
前面几篇文章大多在讨论“怎么造技能”或者“怎么让技能持续演化”,但如果没有统一评测基准,这些方法的增益其实很难比较。SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks 的意义就在这里:它把 Skill 本身当成 first-class artifact(一级评测对象),不再只问“模型能不能做任务”,而是明确问“给这个代理加上 Skill 之后,究竟提升了多少”。
这篇论文最重要的贡献不是提出新算法,而是把 Skills 的效用测量拆成可操作协议。每个任务都在三个条件下评测:无 Skills、提供人工整理 Skills、以及让模型自己先生成 Skills 再做题。这样得到的不是单一 pass rate,而是一个清晰的对照实验框架。
也因此,SkillsBench 在这组文章里扮演的是“测量仪器”而不是“技能方法”。它提供的是讨论 Skills 时最缺的一块地基:哪些 Skill 真的有用,哪些只是看起来合理,哪些领域收益大,哪些领域甚至会负增益。
Motivation
Skill 生态增长得很快,但长期缺一个尴尬却基本的问题:Skill 到底有没有帮助。很多论文默认“额外过程知识会提升代理”,很多产品也默认“给代理多一点指南总是好的”,但在没有 paired evaluation(配对评测)的情况下,这种判断往往混入了模型差异、任务差异和上下文长度差异。
此外,Skill 和其他 augmentation(增强)方式并不完全一样。系统提示词、few-shot 示例、RAG 检索、工具文档都可以往上下文里塞信息,但这些对象并不一定提供 procedural knowledge(过程性知识)。SkillsBench 想解决的,就是把 Skill 从“泛化上下文增益”里单独拿出来测。
论文还有一个更实际的动机:Skill 作者和使用者需要经验法则。到底是文档越全越好,还是模块越聚焦越好?是让模型自己写 Skill 就够了,还是必须人工整理?较小模型能不能靠 Skill 追平更大模型?没有系统性数据,这些问题都只能靠个别案例猜。
Problem Formulation
论文没有把问题写成复杂的学习目标,而是把评测协议本身形式化。设任务集合为:
每个任务 $t_i$ 都在三种条件下运行:
给定 agent-model configuration(代理-模型配置) $a$,任务 $t_i$ 在条件 $c$ 下单次运行得到二值奖励:
任务级 pass rate 可以理解为多次试验的平均:
配置级总体 pass rate 则是固定分母任务平均:
论文还显式报告 normalized gain(归一化增益):
这个指标的作用是把“已经很强的模型再涨一点”和“很弱的模型涨很多”放到同一比例坐标下比较,不过论文也提醒它会掩盖 absolute delta(绝对提升)差异,因此最终同时报告绝对提升和归一化增益。
Methodology
What Counts as a Skill
SkillsBench 先给 Skill 下了一个很实用的操作性定义。一个对象要被算作 Skill,至少要满足四个条件:
- 它包含 procedural content(过程性指导),而不是纯事实检索。
- 它适用于一类任务,而不是单个实例。
- 它有结构化组件,至少包含
SKILL.md,并可带脚本、模板、示例等资源。 - 它是可移植的,能作为文件系统资产在不同 harness 之间复用。
这个定义刻意把 system prompt、few-shot、RAG 检索和工具说明排除在外。理由不是这些对象没价值,而是它们不等同于 Skill。对于这篇基准论文,这个边界划分非常重要,因为没有边界就没有可重复的评测。
Benchmark Construction
基准建立在 Harbor / Terminal-Bench 风格的容器化任务框架上。每个任务都包含四部分:instruction.md 任务说明、带 skills/ 子目录的环境、参考解法、以及 deterministic verifier(确定性验证器)。验证完全依赖程序化断言,不使用 LLM-as-a-judge。
任务构建流程也比较严格。论文先从 105 位贡献者处收集了 322 个候选任务,再经过自动检查和人工复查,最终筛到 84 个任务、11 个领域。自动检查包括结构验证、oracle 必须 100% 通过、AI 检测、泄漏审计;人工复查则看数据真实性、任务真实性、oracle 质量、Skill 质量和 anti-cheating 设计。
这里一个需要明确说明的细节是:论文 v3 PDF 的摘要写“86 tasks”,但正文、图表和实验协议多处明确使用的是 84 个评测任务,例如 Figure 1、Figure 2、Table 10 和 main text 都按 84 计分。这说明该版本文本里存在一个未完全清理的数字不一致。后面的实验结果应以正文主协议的 84 个任务为准。
Skills Conditions and Evaluation Matrix
论文的核心设计是三条件对照:
- No Skills:环境里不提供任何 Skill。
- With Skills:提供人工整理过的完整
environment/skills/目录。 - Self-Generated Skills:不给现成 Skill,但提示模型先自己写 1 到 5 个 Skills,再用这些 Skills 解题。
实验覆盖 3 个商业 agent harness:Claude Code、Gemini CLI、Codex CLI;以及 7 个 frontier 模型配置:Claude Opus 4.5、Opus 4.6、Sonnet 4.5、Haiku 4.5、Gemini 3 Pro、Gemini 3 Flash、GPT-5.2。总共得到 7,308 条有效轨迹。
这样一个设计的好处是非常直接的。它既能测“Skill 有没有用”,也能测“模型自己能不能稳定写出有用 Skill”。而后者恰恰是很多自演化论文默认成立、但很少被基准验证的假设。
Leakage Prevention and Skill Quality Control
为了防止 Skill 直接泄漏答案,论文强制规定 Skill 不能包含任务特定文件名、路径、魔法常数、测试预期值或精确求解命令序列。Skill 必须提供 how-to guidance(怎么做),而不是 what-to-output(输出什么)。
这个设计对理解后面的结果很关键。因为 SkillsBench 评到的并不是“把答案藏进上下文”带来的提升,而是 procedural scaffolding(程序性脚手架)本身能否提升代理完成率。
Experiments
SkillsBench 的核心结果很清楚:人工整理 Skills 平均能把通过率拉高 16.2 个百分点,但这个增益远不均匀。按 abstract 和 Table 10 的汇总,7 个 agent-model 配置的平均 pass rate 从 24.3% 提升到 40.6%,平均绝对增益 +16.2pp。不同配置增益范围大约从 +13.6pp 到 +23.3pp,说明 Skill 的价值不是“恒定加成”,而是与模型和 harness 的组合强相关。
更关键的是 self-generated Skills 几乎没有带来正收益。Table 10 里,支持该条件的配置平均是 –1.3pp;只有 Claude Opus 4.6 出现了非常边缘的 +1.4pp,其余如 GPT-5.2、Sonnet 4.5、Haiku 4.5 都是负增益或零增益。这一点和前面 AutoSkill、EvoSkill、EvoSkills、SKILLRL 这些方法形成了很有张力的对照:如果没有额外机制,单靠“让模型先写 Skill 再做题”,通常并不能稳定提升结果。
从模型配置看,Skill 确实能部分替代模型规模。比如 Claude Haiku 4.5 无 Skills 时只有 11.0%,加人工整理 Skills 后到 27.7%;GPT-5.2 无 Skills 是 30.6%,加 Skills 后到 44.7%;Claude Opus 4.5 无 Skills 时 22.0%,加 Skills 后到 45.3%。论文因此提出一个非常实用的判断:在程序性任务上,小模型加高质量 Skills,有时可以逼近甚至超过没有 Skills 的更大模型。
从领域维度看,Skill 效果波动更明显。论文摘要给出的极值是 Software Engineering 只有 +4.5pp,而 Healthcare 高达 +51.9pp。这意味着 Skill 更像是对某些高程序性、高规范性领域特别有效,而不是对所有领域均匀生效。与此同时,16 个任务在加了 Skills 后反而出现负增益,这说明“多一份指导”并不自动等于“更好”。
论文还给出几个很有现实感的设计结论。第一,focused Skills with 2–3 modules(聚焦型 Skill,只有 2 到 3 个模块)优于 comprehensive documentation(大而全的综合文档)。虽然正文没有把这条拆成独立表格,但 abstract 和结论都反复强调这个发现。它和我们前面看过的几篇方法论文其实是呼应的:更好的 Skill 往往不是更长,而是更聚焦、更可执行。第二,Skill 生态本身质量分布很差。论文在附录的技能生态分析中统计了 47,150 个去重 Skill,平均质量分只有 6.2/12,而基准里选入的 Skill 平均质量约 10.1/12。这意味着 SkillsBench 测到的是一个偏乐观上界:真实世界里随手抓到的 Skill,实际效果很可能比基准结果更不稳定。
还有两个数值得注意。第一,Figure 2 的流程图里给出的是 +12.66pp with Skills,而 abstract 和主结果汇总给的是 +16.2pp。结合正文可推断,这大概率来自不同聚合方式或不同版本统计口径,论文没有在图注里完全解释。第二,摘要写 86 tasks,但主评测用 84 tasks。这些不一致不影响主结论,但说明论文在汇总层面仍留有编辑痕迹。
如果把这篇放回整组文章里看,它最重要的价值其实不是某个单独数字,而是提供了一个非常明确的经验边界:高质量、人工整理、聚焦型 Skills 确实能显著提升代理;而“让模型自己现场写 Skill”在没有额外演化、验证或训练机制时,基本不可靠。
References
[1] Kavin Gopi, Arda Kaz, Aneesh Prasad, Hoa Nguyen, Subhojyoti Ghosh, Xuan Gao, Karthik Narasimhan, Sewoong Oh, and Tu Vu. “EvoSkill: A New Paradigm for Self-Evolving AI Agents” arXiv preprint arXiv:2603.02766 (2026).
[2] Sentient AI. “EvoSkill” GitHub repository.
[3] The Mosaic Research Team. “Introducing OfficeQA: A Benchmark for End-to-End Grounded Reasoning” Databricks Blog (2025).
[4] Thinh Pham, Nguyen Nguyen, Pratibha Zunjare, Weiyuan Chen, Yu-Min Tseng, and Tu Vu. “SealQA: Raising the Bar for Reasoning in Search-Augmented Language Models” arXiv preprint arXiv:2506.01062 (2025).
[5] Jason Wei, Zhiqing Sun, Spencer Papay, Scott McKinney, Jeffrey Han, Isa Fulford, Hyung Won Chung, Alex Tachard Passos, William Fedus, and Amelia Glaese. “BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents” arXiv preprint arXiv:2504.12516 (2025).
[6] Agent Skills. “Agent Skills Specification” specification site (2025).
[7] Hanrong Zhang, Shicheng Fan, Henry Peng Zou, Yankai Chen, Zhenting Wang, Jiayu Zhou, Chengze Li, Wei-Chieh Huang, Yifei Yao, Kening Zheng, Xue Liu, Xiaoxiao Li, and Philip S. Yu. “EvoSkills: Self-Evolving Agent Skills via Co-Evolutionary Verification” arXiv preprint arXiv:2604.01687 (2026).
[8] Xiangyi Li, Wenbo Chen, Yimin Liu, Shenghan Zheng, Xiaokun Chen, Yifeng He, Yubo Li, Bingran You, Haotian Shen, Jiankai Sun, et al. “SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks” arXiv preprint arXiv:2602.12670 (2026).
[9] Anthropic. “Agent Skills Overview” official documentation.
[10] Yutao Yang, Junsong Li, Qianjun Pan, Bihao Zhan, Yuxuan Cai, Lin Du, Jie Zhou, Kai Chen, Qin Chen, Xin Li, Bo Zhang, and Liang He. “AutoSkill: Experience-Driven Lifelong Learning via Skill Self-Evolution” arXiv preprint arXiv:2603.01145 (2026).
[11] ECNU-ICALK. “AutoSkill” GitHub repository.
[12] AllenAI. “WildChat-1M” dataset page.
[13] Peng Xia, Jianwen Chen, Hanyang Wang, Jiaqi Liu, Kaide Zeng, Yu Wang, Siwei Han, Yiyang Zhou, Xujiang Zhao, Haifeng Chen, Zeyu Zheng, Cihang Xie, and Huaxiu Yao. “SKILLRL: Evolving Agents via Recursive Skill-Augmented Reinforcement Learning” arXiv preprint arXiv:2602.08234 (2026).
[14] aiming-lab. “SkillRL” GitHub repository.
[15] Mohit Shridhar, Jesse Thomason, Daniel Gordon, Yonatan Bisk, Winson Han, Roozbeh Mottaghi, Luke Zettlemoyer, and Dieter Fox. “ALFWorld” benchmark site.
[16] Shunyu Yao, Howard Chen, John Yang, and Karthik Narasimhan. “WebShop” benchmark site.
[17] Xiangyi Li, Yimin Liu, Wenbo Chen, Shenghan Zheng, Xiaokun Chen, Yifeng He, Yubo Li, Bingran You, Haotian Shen, Jiankai Sun, Shuyi Wang, and collaborators. “SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks” arXiv preprint arXiv:2602.12670 (2026).
[18] SkillsBench. “skillsbench.ai” project site.
[19] Mike A. Merrill, Alexander G. Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich, Lin Shi, Jeong Yeon Shin, Thomas Walshe, E. Kelly Buchanan, and collaborators. “Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces” arXiv preprint arXiv:2601.11868 (2026).