SkillX：让 Agent 学会"传帮带"，自动构建可复用的技能知识库
你有没有遇到过这种情况——给 Agent 部署了一套复杂的 API 调用任务，它磕磕绊绊总算跑通了。然后换一个差不多的任务，它又从零开始摸索，犯一模一样的错。
更糟糕的是，你让多个 Agent 各自跑同一类任务，它们彼此不通气，每个都在独立"重新发明轮子"。这不就是公司里新人没有知识库、全靠自己踩坑的翻版吗？
今天聊的这篇论文 SkillX，瞄准的就是这个痛点：能不能让 Agent 自动把成功经验提炼成可复用的技能，存到一个技能库里，然后其他 Agent 拿来就用？
核心摘要
SkillX 提出了一套全自动的技能知识库构建框架，核心思路是把 Agent 的执行轨迹分层蒸馏为三级技能（规划技能、功能技能、原子技能），然后通过迭代精炼和探索性扩展不断丰富这个技能库。关键效果：在 Qwen3-32B 上，BFCL-v3 的 Avg@4 从 53.67 涨到 63.67，AppWorld 从 27.68 涨到 35.12。更有意思的是，弱模型可以直接用强模型提炼出的技能库，实现"能力迁移"。
坦率讲，这不是什么底层理论突破，但作为一套把"Agent 经验复用"做得比较完整的工程框架，确实有不少值得细看的设计。
论文信息
- 标题：SkillX: Automatically Constructing Skill Knowledge Bases for Agents
- 作者：Chenxi Wang, Zhuoyun Yu, Xin Xie, Wuguannan Yao, Runnan Fang, Shuofei Qiao, Kexin Cao, Guozhou Zheng, Xiang Qi, Peng Zhang, Shumin Deng
- 机构：浙江大学 & 蚂蚁集团联合实验室（Zhejiang University - Ant Group Joint Laboratory of Knowledge Graph）
- 日期：2026年4月6日
- 链接：arXiv:2604.04804
问题出在哪？为什么 Agent 需要技能库
现有的 Agent 自进化方案有个共同问题：每个 Agent 都在孤立学习。
拿 Voyager、ExpeL、AWM 这些前辈来说，它们的做法大致是让 Agent 跑任务、积累经验、下次用上。听起来没毛病，但实际操作中有三个硬伤：
重复探索。Agent A 在任务 1 里摸索出了"先认证再调用 API"的流程，Agent B 遇到类似任务，又从头摸索一遍。经验完全不共享。
经验质量参差不齐。直接从执行轨迹里提取的"经验"往往很粗糙——包含大量无用的试错步骤、冗余的 API 调用、甚至错误的探索路径。这些噪声混在里面，存下来也是浪费。
迁移性差。一个模型提炼的经验，换个模型基本用不了。因为经验的表述跟原模型的推理风格深度绑定。
说到这个，Claude 的 Skills 机制其实也在做类似的事——把经验封装成可复用的技能。但 Claude Skills 的做法是长上下文渐进式披露，需要复杂的沙盒系统和多轮交互。
图1：左边是 Claude Skills 的方案——长上下文渐进披露、依赖复杂沙盒、需要多轮交互。右边是 SkillX 的方案——多层级技能以条目形式存储、轻量检索模块、一次性注入 system prompt 即可，天然支持跨模型迁移。
SkillX 的核心洞察是：把技能做成轻量、结构化、可检索的条目，而不是绑在特定模型上下文里的长文本。这样任何模型都能"查字典"式地使用技能库。
方法拆解：SkillX 到底怎么做的
先看全局架构图，然后逐模块拆。
图2：SkillX 的完整流程——左侧是三级技能的设计（规划、功能、原子），右上是技能提取流程，右下是技能精炼（过滤+合并），上方是探索性扩展模块。整个系统形成一个迭代循环：提取 -> 精炼 -> 扩展 -> 再提取。
三级技能设计：从粗到细
这是 SkillX 最有辨识度的设计。它把 Agent 的经验拆成三个层级：
| 层级 | 名称 | 做什么 | 类比 |
|---|---|---|---|
| L1 | 规划技能（Planning Skills） | 高层任务分解策略，有序的步骤序列 | 工作手册里的"操作流程" |
| L2 | 功能技能（Functional Skills） | 可复用的工具调用子程序，包含名称、文档、代码内容 | 封装好的函数/API wrapper |
| L3 | 原子技能（Atomic Skills） | 单个工具的使用规范和约束 | 工具的"使用说明书" |
举个具体例子：假设任务是"查询 Spotify 上最受推荐的歌手"。
- 规划技能：Step 1 认证 Spotify -> Step 2 获取个性化推荐 -> Step 3 返回最受推荐的歌手名
- 功能技能：
spotify_authenticate_with_stored_credentials—— 描述如何获取密码、登录、拿 access token - 原子技能：
list_all_APIs_in_an_app—— 说明apis.api_docs.show_api_descriptions的参数、输出格式和注意事项
我觉得这个分层设计挺精巧的。规划技能给 Agent 提供"做事的大方向"，功能技能给出"怎么做的具体方案"，原子技能补充"工具本身的使用细节"。三层配合，覆盖了从战略到执行的完整链路。
技能提取：从轨迹中蒸馏经验
提取流程是这样的：
- 采样训练任务，让 Agent 执行（每个任务跑 4 次 rollout）
- 从成功轨迹中，先检索已有的规划技能和功能/原子技能
- 规划技能提取：把执行轨迹压缩——去掉试错、回溯等噪声，只保留有效步骤，改写成伪计划
- 功能技能提取：对规划中的每个子任务，通过迭代 prompting 提取可复用的工具调用模式
- 原子技能提取：从轨迹中蒸馏出工具级别的使用规范——调用模式、典型参数配置、常见失败模式
关键点在于"压缩"这个动作。原始轨迹里有大量噪声（Agent 试了这个不行、又试那个），直接存下来的话技能库会被垃圾淹没。SkillX 的做法是只保留成功路径上的关键节点。
技能精炼：合并同类项 + 过滤垃圾
提取出来的技能不能直接用，还需要精炼。这一步分两部分：
技能合并（Skills Merge）： - 用 Qwen3-Embedding-8B 对技能做向量化，余弦相似度阈值 0.45 - 把语义相似的技能聚类 - 对同一簇内的技能做聚合——取各个更新方向的合成 \(\delta_{agg} = \sum \delta_i\) - 如果合并后的技能太复杂，就拆成多个子技能
技能过滤（Skills Filter）： - 通用过滤：检查技能是否有多余依赖、模块化是否够好 - 工具特定过滤：拿环境的 API schema 做校验，干掉那些引用了不存在的工具或参数的"幻觉技能"
这个两阶段过滤挺实在的。我之前在做类似经验库的时候就发现，LLM 提取的"经验"里经常有一些看起来合理、但实际上引用了不存在的 API 的东西。有个 schema 校验兜底，能滤掉不少坑。
探索性扩展：主动找新技能
光从已有任务里提取还不够。SkillX 还有一个经验引导的探索模块：
- 分析现有执行轨迹，识别出哪些工具"用得少"或"总失败"
- 针对这些薄弱环节，合成新的探索任务
- Agent 去执行这些探索任务（temperature=1.0，鼓励探索）
- 从探索轨迹中提取新的技能，再走一遍精炼流程
跟随机探索比，这种经验引导的策略能发现更多真正新颖的技能。从论文中的分析图来看，经验引导探索比随机探索多扩展了 112 个技能，同时在 Avg@4 和 Pass@4 上分别多涨了 4.61 和 5.56 个点。
实验分析：数据说话
主实验（Table 1）
论文在三个 benchmark 上做了测试，先看 Qwen3-32B 作为 base model 的结果：
| 方法 | BFCL-v3 Avg@4 | BFCL-v3 Pass@4 | AppWorld Avg@4 | AppWorld Pass@4 |
|---|---|---|---|---|
| No Memory | 53.67 | 73.33 | 27.68 | 47.62 |
| A-Mem | 53.67 | 73.00 | 26.79 | 50.59 |
| AWM (self) | 55.67 | 76.00 | 30.80 | 55.95 |
| AWM (GLM-extract) | 56.67 | 76.33 | 34.45 | 56.25 |
| ExpeL (self) | 57.33 | 77.67 | 32.87 | 58.93 |
| ExpeL (GLM-extract) | 59.33 | 78.83 | 32.94 | 58.78 |
| SkillX | 63.67 | 82.00 | 35.12 | 58.93 |
BFCL-v3 上从 53.67 到 63.67，涨了 10 个点——这个幅度在 function calling 任务上算很能打了。AppWorld 的提升更明显，Avg@4 从 27.68 到 35.12。
在 \(\tau^2\)-Bench 上，三个领域也都有提升：
| 领域 | Qwen3-32B (No Mem) | Qwen3-32B (SkillX) | 提升 |
|---|---|---|---|
| Retail | 53.75% | 66.87% | +13.12 |
| Airline | 38.75% | 47.50% | +8.75 |
| Telecom | 36.25% | 43.75% | +7.50 |
Retail 涨了 13 个点，这个数比较亮眼。
跨模型迁移（Table 2）
更有意思的是跨模型迁移实验。用 GLM-4.6 提取的技能库，直接给 DeepSeek-V3.2 和 GPT-4.1 用：
| 模型 | 提取方式 | BFCL-v3 Avg@4 | AppWorld Avg@4 |
|---|---|---|---|
| DeepSeek-V3.2 | No Memory | 64.33 | 61.90 |
| DeepSeek-V3.2 | GLM-Extract | 67.17 | 64.28 |
| DeepSeek-V3.2 | Self-Extract | 67.83 | 65.48 |
| GPT-4.1 | No Memory | 49.66 | 66.37 |
| GPT-4.1 | GLM-Extract | 60.00 | 66.82 |
| GPT-4.1 | Self-Extract | 50.67 | 68.60 |
这里有个有意思的现象：GPT-4.1 用 GLM 提取的技能库，BFCL-v3 从 49.66 直接蹦到 60.00，涨了 10 多个点。但自己提取的反而只到 50.67。
我的理解是，GPT-4.1 的 self-extract 可能在 BFCL-v3 这个特定环境下提取出的技能质量不如 GLM-4.6。这说明技能提取能力和任务执行能力不完全正相关——有些模型虽然执行不如你强，但总结经验可能比你到位。
消融实验（Table 3）
消融部分用 GLM-4.6 做的，关键对比是有无探索性扩展（Vanilla vs Expand）：
| 变体 | BFCL-v3 Avg@4 | AppWorld Avg@4 | AppWorld Pass@4 |
|---|---|---|---|
| No Memory | 76.67 | 60.27 | 83.33 |
| Vanilla-Iter1 | 78.50 | 62.35 | 83.33 |
| Vanilla-Iter2 | 79.50 | 64.29 | 85.12 |
| Vanilla-Iter3 | 78.83 | 61.46 | 85.71 |
| Expand-Iter1 | 78.50 | 64.58 | 83.93 |
| Expand-Iter2 | 78.83 | 64.88 | 87.50 |
| Expand-Iter3 | 78.83 | 64.88 | 88.69 |
两个发现值得注意：
发现一：Vanilla（纯精炼，不扩展）在 Iter3 的 AppWorld Avg@4 掉到了 61.46，反而低于 Iter2 的 64.29。这说明不引入新技能的话，纯粹反复精炼可能过拟合——技能库越来越"窄"，覆盖不了新场景。
发现二：加上探索性扩展后（Expand），AppWorld Pass@4 从 83.33 稳步涨到 88.69，没有出现掉点。这说明主动探索确实在扩大技能库的覆盖范围。
多层级技能的贡献分析
图3：六组子图分别展示了（a）多层级技能的性能贡献、（b）执行效率、（c）迭代精炼分析、（d）扩展策略对比、（e）平均执行步数、（f）平均输入 token 数。
从图 3(a) 可以看出，功能技能（Functional Skills）对性能的贡献最大，规划技能排第二。单独只用规划技能的效果反而较弱——这也合理，光有"做什么"的计划没有"怎么做"的具体方案，Agent 还是得自己摸索。
图 3(e) 显示 SkillX 在 AppWorld 上的平均执行步数（约 2968 步）远低于无记忆版本（约 3108 步）和其他 baseline（AWM 约 4062 步）。执行效率上的优势很明显——Agent 不需要反复试错了，直接查技能库就知道怎么调 API。
Case Study：技能库实际是怎么帮上忙的
图4：AppWorld 的一个实际案例——任务是"根据室友的建议更新 Spotify 播放列表"。没有技能库时，Agent 在 API 调用顺序上翻车（错误的 API call sequence），也搞不定跨 App 集成（Spotify + 手机短信），得分 0.0。有了 SkillX 技能库后，Agent 直接检索到"Spotify 认证"、"播放列表检索模式"和"跨 App 消息集成"三个技能，顺利完成任务，得分 1.0。
这个 case study 挺直观的。没有技能库的 Agent 犯的错是很典型的——不知道 Spotify API 的正确调用序列，也不知道怎么从手机消息 App 里拿数据。这些都是"踩过一次坑就会了"的经验，恰好是技能库最擅长解决的问题。
我的判断：这篇论文到底怎么样
亮点：
-
三级技能设计确实比之前的工作更完整。AWM 和 ExpeL 基本只做一层经验提取，SkillX 从规划到执行拆了三层，每层有不同的粒度和用途。这个分层设计让技能库的可检索性和可复用性都上了一个台阶。
-
跨模型迁移是个真正有用的特性。用强模型提取技能、弱模型使用——这个范式在实际部署中很有价值。你可以用 GPT-4 级别的模型做一次性的技能提取，然后让成本更低的模型去跑实际任务。
-
探索性扩展的思路不错。不是被动等任务来了才学，而是主动去探索薄弱环节。从消融实验来看，这个模块确实在防止技能库"过拟合"上起了作用。
我觉得有问题的地方：
-
Benchmark 的代表性值得商榷。BFCL-v3 是 function calling，AppWorld 是 API 组合，\(\tau^2\)-Bench 是对话场景——这三个都是"工具调用密集型"的任务。SkillX 的三级技能设计天然适合这类场景。但如果换成推理密集型任务（比如数学、代码生成），这套框架还能不能 work？论文没回答这个问题。
-
技能库的规模和维护成本没讲清楚。随着任务越来越多，技能库会不断膨胀。虽然有合并和过滤机制，但长期运行下来，检索的召回质量会不会下降？0.45 的余弦相似度阈值是怎么选的？这些工程层面的细节对落地很关键，但论文几乎没讨论。
-
GPT-4.1 的实验结果有点反常。Self-Extract 在 BFCL-v3 上只有 50.67，比 GLM-Extract 的 60.00 差了将近 10 个点。论文没给出解释。我怀疑可能是 GPT-4.1 在这个环境下的技能提取 prompt 没有调好，或者 GPT-4.1 的输出格式跟 SkillX 的解析器不太兼容。
-
跟 Claude Skills 的对比有点不太公平。图 1 把 Claude Skills 说成"需要复杂沙盒、多轮交互"，但这其实是 Claude 平台为了安全性和可控性做的设计选择，不能单纯算作缺点。而且 Claude Skills 在实际产品中是经过大量用户验证的，SkillX 目前还停留在学术 benchmark 阶段。
对工程实践的启发：
如果你在做 Agent 系统，SkillX 的三级技能设计思路是可以借鉴的——特别是"功能技能"这一层，就是把常用的 API 调用模式封装成可检索的 snippet。这个在 API 密集型场景下投入产出比很高。
另一个值得试试的是"经验引导的探索"。与其等用户报 bug 才知道哪个工具不好用，不如主动分析执行日志，找出失败率高的工具，针对性地做数据补充。
相关工作的位置感
在 Agent 经验复用这个方向上，几个重要的前置工作：
| 方法 | 核心做法 | 局限 |
|---|---|---|
| Voyager (2023) | 用代码形式存储技能，Minecraft 场景验证 | 场景单一，技能不可跨环境迁移 |
| ExpeL (2024, ICLR) | 从成功/失败轨迹中提取经验 | 单层经验，不区分粒度 |
| AWM (2025, ICML) | Agent Workflow Memory，提取工作流 | 经验提取与推理绑定，迁移性有限 |
| A-Mem | 类人记忆机制 | 从实验结果看提升有限 |
| SkillX (这篇) | 三级技能 + 迭代精炼 + 主动探索 | 工具调用场景外的泛化存疑 |
SkillX 在这条线上的位置，我觉得是"工程整合型创新"——它没有提出什么全新的概念，但把"分层技能设计 + 迭代精炼 + 主动探索"这几个想法组合得比较完整，实验也做得够扎实。
总结
SkillX 给 Agent 经验复用提供了一个比较完整的解决方案。三级技能设计是这篇论文最值钱的部分——它把"经验"从一个模糊的概念变成了结构化、可检索、可迁移的具体条目。跨模型迁移和主动探索扩展也是实用的工程设计。
但这套方案目前更像是"工具调用场景的专用方案"，能不能推广到更通用的 Agent 任务场景，是个悬而未决的问题。另外技能库的长期维护策略——当技能数量上万之后怎么管理——也是落地时不得不面对的挑战。
如果你在做 Agent 系统，特别是涉及大量 API 调用的场景，这篇论文的设计思路值得参考。三级技能的抽象层次选得不错，迭代精炼的流程也比较成熟。但如果期望看到通用 Agent 能力的重大突破，可能会有点失望——这更多是一个扎实的工程贡献。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我