论文链接：arxiv.org/abs/2606.26669 代码仓库：暂未开源（论文中未提及公开代码仓库） 发表时间：2026年6月（arXiv v1: 2026-06-25） 发表机构：微软研究院（Microsoft Research）、北京外国语大学（Beijing Foreign Studies University） 合著标注：这是企业研究院与高校学生的产学研合著研究。第一作者 Zhongxin Guo 与第二作者 Danrui Qi（北京外国语大学）深度参与，通讯层面由微软研究院的 Peng Cheng（高级研究员）和 Yongqiang Xiong（首席研究员）指导。这种"高校学生 + 企业研究院"的合作模式在 Agent 研究领域日益普遍——学生贡献理论框架与创新思路，企业提供算力、真实场景和工程经验。

一、论文背景

1.1 Agent 为什么需要"技能"？

先说清楚三个核心概念：Agent、Harness 和 Skill。

Agent（智能体） 是以大语言模型（LLM）为"大脑"、能够通过多轮"思考—行动—观察"循环来完成复杂任务的系统。比如你在 ChatGPT 里让它"帮我查一下最近的航班并订最便宜的"，它就会一步步调用搜索工具、比价工具、预订工具——这就是一个 Agent。

Harness（框架/外壳） 是包裹在 LLM 外层的软件基础设施。可以把它理解为 Agent 的"骨架"：它负责管理工具调用的格式、维护对话历史、处理错误恢复、决定何时终止等。常见的 Harness 有 LangChain、AutoGPT、OpenAI 的 Agents SDK 等。Harness 决定了 Agent 怎么运行，而 LLM 决定了 Agent 怎么思考。

Skill（技能） 则是 Agent 的"肌肉记忆"。一个技能是一段可重用的、参数化的操作程序——类似于人类学会"开门"之后，不管是开卧室门、车门还是冰箱门，都能自动复用同一个动作模式，而不需要每次都从头思考。

1.2 当前 Agent 面临的"重复造轮子"困境

当前的 Agent 有一个非常低效的问题：每次执行相似任务都从零开始。

举个例子：假设 Agent 已经成功完成了"在抽屉1里找钥匙"这个任务，执行轨迹是 go_to(drawer1) → open(drawer1) → take(key)。现在你再让它"在抽屉3里找遥控器"，它并不会复用之前的经验，而是重新走一遍推理流程：先推理"遥控器可能在哪"，再决定"要去哪"，再决定"到了之后怎么做"……

这带来三个严重问题：

  1. 推理成本高昂：每次都要调用 LLM 进行多轮推理，消耗大量 Token
  2. 执行轨迹冗长：同样的事情反复做，执行步骤（Turns）数量膨胀
  3. 泛化脆弱：面对新任务时容易犯错，因为缺乏积累的经验

1.3 已有方法的局限

学术界已经注意到了这个问题，提出了两大类解决方案：

第一类：经验重用（Experience Reuse）

以 AWM（Agent Workflow Memory） 和 Reflexion 为代表。这些方法让 Agent 把成功经验以自然语言形式存入记忆库，下次遇到类似任务时取出来作为参考。

AWM（ICML 2025）从 Agent 的完成轨迹中归纳"工作流配方"（task recipes），以文本形式存储。但它有个致命缺陷：自然语言存储的经验不可验证——你没法在部署前确认这段文字描述的操作是否真的能跑通。

第二类：技能归纳（Skill Induction）

以 Voyager、ASI（Agent Skill Induction） 和 SkillWeaver 为代表。这些方法更进一步，把经验提取为可执行的代码技能。

Voyager（2023）是先驱性工作，让 Agent 在 Minecraft 中不断探索、编写 JavaScript 函数作为技能并存入技能库。

ASI（2025）在 Voyager 基础上改进，让 Web Agent 自动归纳程序化技能并在在线交互中验证和使用。

但这类方法有一个共同的根本问题：它们基于单条轨迹提取技能。什么是"单条轨迹"？就是说，Agent 成功完成了一次任务，就从这一次的成功中提取一个技能。这会导致：

  • 技能冗余：同一个"搜索并打开容器"的模式，在不同的任务中可能被提取为 10 个不同的技能
  • 技能碎片化：提取出的技能过于具体，无法泛化到新任务
  • 覆盖面低：大量的技能但每个只匹配极少场景

论文给出了一个触目惊心的数据：在 ALFWorld 上，ASI 归纳出了 110 个技能，但平均每次调用只覆盖 0.2 个原始步骤，错误率高达 75.3%。这意味着大量技能基本是"废技能"。

1.4 问题的核心：缺少对"过程性"的结构化理解

根本问题在于：之前的方法没有意识到——相似任务之间共享的不是某个具体的动作序列，而是过程性的控制流结构。

回到"找东西"的例子。不管是在抽屉里找钥匙、在柜子里找书、还是在架子上找杯子，成功轨迹背后都有一个共同的控制流模式：

重复执行：
    去某个位置
    如果这个位置有可打开的容器，就打开它
    检查目标物品是否在这里
直到找到目标物品
然后：拿取目标物品

这是一个带有**循环（repeat-until）和条件分支（if-then）**的参数化控制流。如果能从多条成功轨迹中把这个共同结构"蒸馏"出来，就能得到一个真正可重用的、高覆盖的技能。

这就是 SKILL-DISCO 论文要解决的核心问题。

二、论文定位和关联工作

2.1 研究脉络：从"记住经验"到"编译技能"

SKILL-DISCO 处于 LLM Agent 经验积累研究的最前沿，其研究脉络可以这样梳理：

第一阶段：自我反思（2023）
  Reflexion → 文字反思，不提取可执行结构
      ↓
第二阶段：工作流记忆（2024-2025）
  AWM → 文本工作流归纳，不可验证
      ↓
第三阶段：单轨迹技能归纳（2023-2025）
  Voyager → Minecraft 代码技能，单轨迹
  ASI → Web Agent 程序技能，单轨迹
  SkillWeaver → 网页技能合成，单轨迹
      ↓
第四阶段：多轨迹结构化技能编译（本文）
  SKILL-DISCO → 多轨迹蒸馏 + 编译验证

2.2 关键关联工作

工作关系说明
Voyager (2023)前驱首次提出 Agent 自动技能库概念，但基于单轨迹，且面向 Minecraft 开放世界
ASI (2025)直接基线最接近的工作：也做程序化技能归纳。但基于单轨迹，SKILL-DISCO 的直接对比对象
AWM (2025)直接基线工作流记忆方法，以自然语言存储。SKILL-DICO 的直接对比对象
CodeAct (2024)基础设施提出用可执行 Python 代码统一 Agent 动作空间，SKILL-DISCO 的技能编译依赖代码动作
ReAct (2023)基础设施推理与行动交替的经典范式，SKILL-DISCO 的实验基线之一
LATM (2023)关联方向LLM 作为工具制造者，让 LLM 自建工具。与技能合成方向一致但关注点不同
Trace2Skill并行工作同样关注轨迹到技能的转化，但方法路径不同

2.3 SKILL-DISCO 的定位

SKILL-DISCO 在这条研究链上的独特定位可以用三个关键词概括：

  1. 语料级（Corpus-level）：不是从单条轨迹提取，而是从一批成功轨迹中通过聚类发现共享结构
  2. 可验证（Verifiable）：技能在编译阶段经过保留集验证，确保部署后能正确运行
  3. 形式化（Formalized）：引入有限状态机（FSM）和参数化有限状态机（PFSM）对问题和技能进行严格数学定义

这三个特性使它超越所有前作：ASI 做单轨迹归纳但不可验证；AWM 做多轨迹归纳但不可验证；Voyager 做单轨迹归纳且面向特定游戏。SKILL-DISCO 是第一个同时实现"多轨迹 + 可验证 + 形式化"的框架。

三、问题定义

3.1 从直觉到形式化

要理解 SKILL-DISCO 如何定义问题，我们需要先理解一个关键洞察：

相似任务的成功轨迹，本质上是在同一个未知"状态转换图"上的不同路径。

这句话有点抽象，让我们用 ALFWorld（文本家庭任务环境）来解释。

在 ALFWorld 中，Agent 要完成"找一本书并拿起来"的任务。Agent 的环境有一组状态（站在哪个位置、哪些容器是开着的）和一组动作（移动到、打开、拿取）。每次执行一个动作，环境就从当前状态转换到新状态。

这里的环境本身就是一个有限状态机（FSM）——状态和动作都是有限的，动作导致确定性的状态转换。虽然 Agent 不知道完整的状态转换图是什么样（它只知道当前观察到的状态），但它的每条成功轨迹都可以看作是在这张未知图上走的一条路径。

不同的任务实例（找书 vs 找杯子 vs 找钥匙）对应不同的起点和终点，但它们走的是同一张状态转换图上的不同路径。

3.2 FSM 定义的场景

论文给出严格的数学定义：

论文给出严格的数学定义：

$$\mathcal{M}=(\mathcal{S},\mathcal{A},\delta,\mathcal{S}_{0},\mathcal{S}_{\mathrm{goal}})$$

其中 $\mathcal{S}$ 是有限状态集，$\mathcal{A}$ 是有限动作集，$\delta:\mathcal{S}\times\mathcal{A}\rightarrow\mathcal{S}$ 是确定性状态转换函数，$\mathcal{S}_{0}\subseteq\mathcal{S}$ 是初始状态集，$\mathcal{S}_{\mathrm{goal}}\subseteq\mathcal{S}$ 是目标状态集。对应的转移图 $G^{*}=(V^{*},E^{*})$ 中，$V^{*}=\mathcal{S}$，边集 $E^{*}=\{(s,a,s')\mid\delta(s,a)=s'\}$。

通俗讲：只要一个任务环境的"规则"是固定的——状态有限、动作有限、动作的效果确定——它就是 FSM 定义的。ALFWorld 和 WebArena 都满足这个条件。

3.3 过程技能 = 参数化控制流子图

在 FSM 的视角下，论文把过程技能（Procedural Skill）定义为参数化的 FSM 子图（PFSM subgraph）。

什么是"参数化"？回到找东西的例子。技能里的"去某个位置"中的"某个位置"就是参数——它可以是 drawer1、shelf2、bed 中的任何一个。技能本身是一个控制流模板，参数是这个模板中的"占位符"，每次调用时填入具体的值。

论文定义了理想技能集应满足三个属性：

  1. 覆盖性（Coverage）：每个技能都由多条成功轨迹支持——不是偶然现象
  2. 效用性（Utility）：技能捕获的控制流结构确实有助于到达目标状态
  3. 紧凑性（Compactness）：技能既不过于具体（只匹配一条轨迹），也不过于通用（什么轨迹都匹配）

3.4 核心问题的抽象

论文最终将问题抽象为：

过程技能发现问题：给定一组成功轨迹 $\mathcal{T}^{+}=\{\tau_{1},\tau_{2},\ldots,\tau_{N}\}$ 和一个将每条轨迹映射到参数化轨迹图的提升函数 $\phi:\tau_{i}\mapsto\widetilde{G}_{i}$（$\widetilde{G}_{i}$ 是参数化控制流图），目标是发现一组过程技能 $\mathcal{K}=\{K_{1},K_{2},\ldots,K_{m}\}$，其中每个技能 $K_{j}$ 是一个参数化控制流子图，在某个参数绑定下能匹配 $\{\widetilde{G}_{i}\}_{i=1}^{N}$ 的某个子集，记为 $K_{j}\preceq\widetilde{G}_{i}$。

每个聚类的可重用性评分定义为：

$$r_{k}\approx\frac{1}{N}\sum_{i=1}^{N}\mathbb{I}[K_{k}\preceq\widetilde{G}_{i}]$$

其中 $\mathbb{I}[\cdot]$ 是指示函数——如果技能 $K_k$ 能匹配到提升后的轨迹图 $\widetilde{G}_i$ 则取 1，否则取 0。整个分式表示：有多少比例的成功轨迹包含这个技能模式。评分越高，说明这个技能越通用。

这个抽象的关键在于：它不要求预先知道环境的 FSM（现实中 Agent 通常不知道完整的状态转换图），而是从观察到的成功行为中反向推断共享的过程结构。这是从"行为"到"知识"的蒸馏。

四、问题解法：Skill-DisCo 框架

SKILL-DISCO（Skill Distillation and Compilation）是一个两阶段、五步骤的流水线。我们逐步拆解。

4.1 总体架构

输入：成功轨迹集合 T⁺ = {τ₁, τ₂, ..., τₙ}
                    ↓
    ╔══════════════════════════════╗
    ║      第一阶段：蒸馏           ║
    ║  步骤1：轨迹规范化             ║
    ║  步骤2：子目标级算子提取       ║
    ║  步骤3：过程技能合并           ║
    ╚══════════════════════════════╝
                    ↓
    ╔══════════════════════════════╗
    ║      第二阶段：编译           ║
    ║  步骤4：技能规范定义           ║
    ║  步骤5：合成与验证             ║
    ╚══════════════════════════════╝
                    ↓
输出：可执行技能库 K = {K₁, K₂, ..., Kₘ}

4.2 第一阶段：蒸馏（Distillation）

蒸馏阶段的目标是从一堆"原始成功轨迹"中提取出"通用的过程模式"。它包含三个步骤。

步骤 1：轨迹规范化（Trace Normalization）

原始的 Agent 轨迹是这样的：

观察：你在卧室中间。你看到一个床、一个书桌。
行动：go to drawer 1
观察：抽屉1是关着的。
行动：open drawer 1
观察：你打开了抽屉1。抽屉1是空的。
行动：go to drawer 2
……

这种"观察-行动-观察"交替的文本格式，虽然人能读懂，但很难发现跨轨迹的共同模式。所以第一步是把每条原始轨迹转换成结构化、可执行的中间表示（规范化程序）。

规范化程序包含三个关键要素：

  1. 原始环境调用：把"观察"和"行动"配对，还原成对环境的函数调用（比如 open("drawer1")）
  2. 符号变量：把任务特定的实体（“drawer1”、“book”、“mug”）抽象为符号变量（比如 location、target_object）
  3. 代码级控制流：识别出轨迹中的重复模式（如反复去不同位置搜索），用 for/while/if 等控制流结构表示

经过规范化，原来冗长的文本轨迹变成了一段紧凑的、带循环和分支的伪代码程序。

步骤 2：子目标级算子提取（Subgoal-Level Operator Extraction）

规范化后的程序可能还是很长，包含很多细碎的步骤。第二步是把它分解为子目标级别的算子（Operator）。

什么是"子目标级算子"？在 ALFWorld 中，“搜索一个位置并检查目标"就是一个子目标；在 WebArena 中，“打开提交表单并填写字段"是一个子目标。每个算子代表一段完成某个子目标的操作序列。

每个算子包含：

  • 动作标识符：这个算子做什么（如 search_location）
  • 自然语言摘要：用一句话描述算子功能
  • 原始算子序列：底层的原子操作列表
  • 代码片段：对应的可执行代码

关键过滤规则：丢弃长度为 1 的碎片。只保留包含 2 步以上操作的算子——因为只有多步操作才可能包含有意义的控制流结构。

步骤 3：过程技能合并（Procedural Skill Merging）

这是蒸馏阶段的核心创新步骤。前面两步处理的都是单条轨迹内的信息，这一步要跨轨迹发现共同模式。

具体做法：对所有轨迹提取出的子目标级算子进行语义聚类。如果多个算子具有相同的参数化执行结构（只是参数值不同），就把它们归为一类，合并为一个过程技能。

例如：

来源轨迹具体操作参数化结构
轨迹 τ₁go_to(drawer1) → open(drawer1) → check(book)go_to(L) → if openable(L): open(L) → check(T)
轨迹 τ₂go_to(shelf1) → go_to(shelf2) → open(shelf2) → check(mug)同上
轨迹 τ₃go_to(bed) → go_to(desk1) → check(book)同上

三条轨迹的操作细节不同，但抽象后的控制流结构完全一致——它们被合并为一个技能 systematic_search_locations。

每个聚类的可重用性评分即上文公式中的 $r_k$，它等于被该聚类技能覆盖的成功轨迹占总轨迹的比例。评分越高，说明这个技能越通用。

经过这三个步骤，蒸馏阶段产出一组紧凑的 PFSM 子图——每个子图代表一个可重用的过程技能。

4.3 第二阶段：编译（Compilation）

蒸馏阶段产出的是"抽象的模式”，还不能直接运行。编译阶段要把这些模式变成可调用、可执行、可验证的 Python 函数。

步骤 4：技能规范定义（Skill Specification）

首先为每个技能写一份"合同”（contract），包含：

  1. 签名：技能名称、参数类型、返回类型——就像 Python 函数签名
  2. 描述：机器可读的文档字符串，告诉 LLM 什么时候该调用这个技能
  3. 行为要求：
    • 前置条件（Precondition）：调用前必须满足什么条件（如"目标物品存在于环境中"）
    • 后置条件（Postcondition）：调用后保证什么状态（如"目标物品已被放入库存"）
    • 声明的副作用：技能会改变环境中的什么（如"打开了搜索过的所有容器"）
  4. 元数据：抽象级别、预期节省的动作数、置信度评分

这份规范既是对 LLM 的使用指南（LLM 读描述来决定何时调用），也是对验证器的检查清单（验证器检查前后置条件是否满足）。

步骤 5：合成与验证（Synthesis and Verification）

最后一步是让 LLM 根据技能规范生成可执行的 Python 代码，然后在保留任务集（holdout set）上验证。

验证检查三件事：

  1. 运行时正确性：代码能不能跑通，不报错？
  2. 后置条件满足度：执行完后，声明的后置条件是否真的满足了？
  3. 动作节省：使用技能后，Agent 的执行步骤是否确实减少了？

如果验证失败，就重新合成（最多 R 次重试）。只有通过所有验证的技能才会进入最终的技能库。

这个"合成—验证"循环是 SKILL-DISCO 区别于所有前作的关键：它保证了技能库中的每个技能都是"真能用的"，而不是"看起来能用的"。

4.4 一个完整的技能示例

论文附录给出了一个 ALFWorld 技能 systematic_search_locations 的完整代码：

def systematic_search_locations(
    target_object: str,
    candidate_locations: list[str],
    env: Environment
) -> str | None:
    """
    系统化搜索位置列表，打开可打开的容器，
    返回找到的目标物品或 None。
    """
    for location in candidate_locations:
        env.go_to(location)
        if env.can_open(location):
            env.open(location)
        found = env.check_target(location, target_object)
        if found:
            return env.take(target_object)
    return None

这个技能把原来需要 7-8 步的操作（去→开→检查→没找到→去下一个→开→检查→……→找到→拿取）压缩为一次函数调用。Agent 只需要说"调用 systematic_search_locations，目标参数是 book，位置列表是所有容器"，技能就会自动完成全部搜索流程。

五、必要知识反推

如果让一个完全不懂这个领域的人从头完成这项研究，他需要掌握哪些知识？让我们从"发现问题"到"解决问题"逐步反推。

5.1 发现问题阶段需要的知识

  1. LLM Agent 的工作机制：必须深入理解 Agent 如何通过"推理—行动—观察"循环来完成任务，以及 ReAct、CodeAct 等范式的具体运作方式。只有这样，才能注意到"Agent 反复解决相似任务"这个效率问题。

  2. 技能归纳领域的前沿工作：必须熟悉 Voyager、ASI、AWM、SkillWeaver 等工作的方法和局限性。只有了解它们的不足（单轨迹、不可验证、冗余碎片化），才能提出更好的方案。

  3. 形式化方法与自动机理论：必须掌握有限状态机（FSM）的数学定义和性质，才能将"Agent 任务环境"抽象为 FSM，将"过程技能"抽象为 PFSM 子图。这不是装饰性的数学——它为整个框架提供了严格的基础。

  4. 程序分析与编译原理：必须理解控制流图（CFG）、数据流分析、程序规范化等概念，才能设计"轨迹规范化"和"算子提取"步骤。轨迹本质上是一段程序的执行日志，规范化就是反向工程出源码。

  5. 聚类与模式发现：必须掌握序列对齐、图同构检测、语义相似度聚类等方法，才能在步骤 3 中跨轨迹发现共同的过程模式。

5.2 解决问题阶段需要的知识

  1. LLM 代码生成能力：必须了解当前 LLM（GPT-4o 等）的代码生成质量和局限性，才能设计"合成—验证"循环，并合理设置重试次数。

  2. 软件测试与形式化验证：必须理解前置条件、后置条件、契约式设计（Design by Contract）的思想，才能为技能定义可验证的行为规范。

  3. Agent 评测方法学：必须熟悉 ALFWorld、WebArena 等基准的设计和评估协议（成功率、平均轮次、Token 成本），才能设计有说服力的实验。

5.3 知识融合的关键

上述知识不是孤立堆砌的——论文的精妙之处在于将它们有机融合：

  • 用自动机理论（知识 3）为问题建模 → 得到 FSM/PFSM 形式化
  • 用程序分析（知识 4）处理轨迹 → 得到规范化程序和算子
  • 用聚类方法（知识 5）跨轨迹发现模式 → 得到 PFSM 子图
  • 用LLM 代码生成（知识 6）+ 形式化验证（知识 7）实现编译 → 得到可执行可验证技能
  • 用评测方法学（知识 8）验证效果 → 在 ALFWorld/WebArena 上证明有效

这个融合过程中最关键的洞察是：把"轨迹聚类"问题转化为"程序结构匹配"问题。传统方法试图在文本层面或语义层面发现共同模式，但文本太模糊、语义太主观。SKILL-DISCO 把轨迹先编译成代码，然后在代码的控制流结构层面做匹配——这是结构化的、精确的、可验证的。这个"视角转换"是整篇论文最核心的创新。

六、论文中可以提取的通用性灵感

灵感 1：从"单实例学习"到"语料级模式发现"

跨实例的结构化聚类比单实例的归纳产生更通用的知识。

ASI 从每条轨迹单独提取技能，结果产生 110 个冗余碎片。SKILL-DISCO 从轨迹集合中聚类，只产出 5 个高覆盖技能。这个原则在任何"从经验中学习"的场景中都适用：不要急着从单次经验中总结规律，先积累足够多的经验，然后找它们之间的共同结构。无论是代码重构（从多次重复代码中提取公共函数）、产品设计（从多个用户反馈中提炼共性需求），还是科学实验（从多次实验结果中归纳普适定律），这个原则都成立。

灵感 2：“可验证"是知识复用的前提

没有经过验证的知识，在部署时可能比无知更危险。

ASI 的技能有 75.3% 的错误率——意味着 Agent 每调用 4 次技能，有 3 次会导致任务失败。这种"有毒的知识"不仅没有帮助，反而会拖累表现。SKILL-DISCO 通过"合成—验证"循环，将错误率降至 0%。在工程实践中，这个原则同样重要：任何自动化提取的规则、模板或配置，都应该在投入使用前经过验证。

灵感 3：形式化约束带来更好的解决方案

对问题适用范围的精确界定，比对通用问题的模糊求解更有效。

SKILL-DISCO 没有试图解决"所有 Agent 任务的技能提取"这个过于宽泛的问题，而是明确限定在"FSM 定义的场景"中。这个看似"保守"的限定，反而带来了巨大的优势：它让问题变得可形式化、可分析、可验证。这启发我们：面对一个复杂问题，先找到它的"可形式化子集”，在这个子集上做出坚实的成果，比试图一口吞下整个问题更务实。

灵感 4：抽象层次的选择决定知识质量

太具体 = 过拟合，太通用 = 无信息量。

理想的技能应该在"恰好覆盖多条轨迹的共同结构"这个抽象层次上。太具体（如 open_drawer1_then_go_to_drawer2）只能匹配一个场景；太通用（如 do_something_then_check）什么场景都匹配但没有实际价值。可重用性评分 $r_k$ 正是用来衡量这个"恰到好处"的程度。这个"抽象层次选择"的困境在机器学习（偏差-方差权衡）、知识管理（知识颗粒度设计）中无处不在。

灵感 5：“编译"思维——从声明到实现

先声明"做什么”（规范），再实现"怎么做"（代码），最后验证"做对了吗"（测试）。

SKILL-DISCO 的编译阶段完美体现了软件工程中"契约式设计"（Design by Contract）的思想：先写规范（前置条件、后置条件、副作用），再合成实现，再验证。这个三步走的方法论可以推广到任何"自动化生成"场景——无论是自动生成 API、自动生成测试用例，还是自动生成数据处理流水线。

灵感 6：知识迁移的"超能力"——参数化

参数化是知识跨场景迁移的核心机制。

SKILL-DISCO 的技能可以跨模型迁移——GPT-4o 归纳的技能让 Qwen3.5-9B 的成功率提升了 80.8%。为什么？因为技能是参数化的控制流，不绑定于任何特定模型的推理风格。参数化让知识从"某个模型的某个具体答案"变成了"一套通用的操作模板"。这个原则对 AI 系统设计意义深远：好的知识表示应该是模型无关的、参数化的、结构化的，而不是自然语言的、模型特定的、非结构化的。

灵感 7：弱者从经验中获益更大

经验积累对能力较弱的模型帮助更大。

实验数据显示：GPT-4o（已经很强的模型）从技能中获得的提升是 +3.1%，而 Qwen3.5-4B（较弱的模型）获得的提升是 +48.8%。这意味着技能库可以作为一种"能力均衡器"——让弱模型通过复用强模型积累的经验来缩小差距。这个发现对 AI 的民主化意义重大：小团队、小模型可以通过共享技能库来获得接近大模型的表现。

总结

SKILL-DISCO 的核心贡献可以浓缩为一句话：

从 Agent 的成功经验中，蒸馏出结构化的过程模式，编译成可验证的可执行技能，让 Agent 像"有了肌肉记忆"一样高效地完成相似任务。

它超越了前作的三个关键维度：

维度ASI / VoyagerAWMSKILL-DISCO
归纳来源单条轨迹多条轨迹多条轨迹（语料级）
知识形式可执行代码自然语言可执行代码（验证过的）
可验证性在线试错不可验证离线验证，0% 错误率
技能数量110+（冗余）N/A5（紧凑）
跨模型迁移未验证未验证验证有效

这项工作给我们的最大启示是：经验积累不应该是"记住更多"，而应该是"理解更深"。从 110 个碎片化技能到 5 个结构化技能，数量减少了 95%，但效果更好——因为真正的知识不在于多，而在于精炼和可复用。