SkillX: Automatically Constructing Skill Knowledge Bases for Agents

Paper: arXiv:2604.04804 Code: zjunlp/SkillX Code reference: main @ 0137cb8c (2026-04-30)

1. Motivation (研究动机)

SkillX 要解决的不是“让单个 agent 多跑几次就更强”这么简单，而是经验学习在 tool-use agent 中缺少一种可复用、可转移、可检索、可直接执行的中间表示。现有 agent 在每个新任务上通常仍从零开始推理，或者只把历史轨迹、反思文本、workflow 片段塞回上下文；这会带来三类结构性问题：第一，isolated learning，不同 agent 反复探索相似工具组合，重复付出交互成本；第二，weak generalization of experience，训练任务少、环境复杂时，从少量轨迹抽出的经验很容易过拟合某个 user profile、工具参数或错误路径；第三，model capability bottleneck，如果经验只来自弱模型自己的 trial-and-error，那么被抽取出来的经验上限也被弱模型的探索能力限制。

论文把这些问题具体落在长程、交互式、工具密集的环境上：AppWorld 中一个任务可能跨多个应用和上百个 API；BFCL-v3 要求多轮 function calling 与前置条件检查；${\tau }^2$-Bench 则在航空、零售、电信等用户对话域中不断改变上下文。对这类任务，原始 trajectory 太长、太嘈杂；纯 reflection/insight 太抽象，不能告诉模型应该调用哪个工具、按什么顺序调用、哪些参数约束不能违反；workflow 又经常只覆盖中高层步骤，缺少低层 API 使用细节。

Figure 1 解读：作者用 Claude Skills 与 SkillX 做对照。Claude-style skill 偏长上下文和逐步 disclosure，需要复杂 sandbox / 文件系统 / 多轮交互来逐步暴露技能；SkillX 则把经验预先拆成可检索的多层 item，一次性注入 system prompt。这个图强调了论文的核心动机：如果希望 skill library 能在不同 base model、不同 benchmark 中迁移，skill 表示必须比完整轨迹更轻、更结构化，也必须比单段自然语言经验更贴近工具执行。

因此，SkillX 的目标是自动构建一个 plug-and-play skill knowledge base：先用强 agent（论文实验中为 GLM-4.6）从训练任务中抽取技能库，再把这个库插到更弱或不同的 base agent 上，让它们在不重新训练参数的情况下获得更好的任务成功率和执行效率。这个问题值得研究，是因为它把 agent learning 从“每个 agent 独立积累经验”改成“强 agent 预构建可共享经验基础设施”，有机会降低重复探索、减少 token/step 消耗，并让弱模型继承强模型在工具使用上的隐式知识。

2. Idea (核心思想)

SkillX 的核心洞察是：可迁移经验不应该保存为整段轨迹或单层 workflow，而应该按工具任务的粒度拆成 planning / functional / atomic 三层 skill。Planning skill 负责高层子任务组织，functional skill 负责可复用的工具组合子例程，atomic skill 负责单个工具的参数、约束、常见失败和调用模式；三者合起来既比 trajectory 短，又比 reflection 更可执行。

关键创新有三点：第一，Multi-Level Skills Design 把成功轨迹蒸馏成 $S_{\text{plan}}\oplus S_{\text{func}}\oplus S_{\text{atomic}}$ 的层级知识库；第二，Iterative Skills Refinement 用 merge、filter、add/modify/keep 迭代更新库，避免冗余技能和 hallucinated tools；第三，Exploratory Skills Expansion 不只依赖 seed training tasks，而是根据已用工具、失败工具、未覆盖工具引导探索，再合成新任务继续抽取技能。

与 A-Mem、AWM、ExpeL 的根本差别在于经验表示的可执行粒度。A-Mem 更像结构化 episodic memory，AWM 偏 workflow pattern，ExpeL 复用成功/失败轨迹和反思；SkillX 则把经验拆成“计划结构 + 工具组合 + 单工具约束”，并在 inference 时按任务先检索 planning skill，再把 pseudo-plan 作为 query 检索 functional/atomic skills。也就是说，它不是单纯更换 retrieval 方法，而是在存什么、怎么改写 query、怎么注入 prompt 三个层面都改变了经验复用形式。

3. Method (方法)

3.1 Overall framework：自动构建并使用 SkillKB

Figure 2 解读：整体流程分为四块。左侧是 Multi-Level Skills Design，展示 planning / functional / atomic 三层 skill 的语义分工；右侧上方是 Skills Expansion，通过 experience-guided exploration 生成探索任务和合成任务；右侧中部是 Rollout and Skills Extraction，用 agent 在训练任务上采样轨迹并从成功轨迹中抽技能；右侧下方是 Skills Refinement，用 skill filtering、skill merging、modify/add/keep 更新技能库。中间的 SkillX library 在每轮之后被带回下一轮 rollout，使 agent 在构建库时也能利用已有库。

形式化地，SkillX 把技能库写成： $\mathcal{D}=S_{\text{plan}}\oplus S_{\text{func}}\oplus S_{\text{atomic}}.$ 给定环境 $\mathcal{E}=(\mathcal{S},\mathcal{A},\mathcal{P})$，agent 在时间步 $t$ 根据上下文 $c_t=(o_1,{\hat{a}}_1,\dots ,o_{t-1},{\hat{a}}_{t-1},o_t)$ 采样动作： ${\hat{a}}_t\sim \pi (\cdot \mid c_t),{\hat{a}}_t\in \hat{\mathcal{A}}.$ 无技能时，任务 $q$ 的轨迹来自 $\tau \sim \pi (\cdot \mid q)$；有技能库和检索器 $\rho$ 后，先取 ${\mathcal{S}}_q=\rho (q)$，再让 agent 条件化生成： ${\tau }^{\prime }\sim \pi (\cdot \mid {\mathcal{S}}_q,q).$ 目标是让 skill-conditioned agent 的期望成功率超过无技能 agent： ${\mathbb{E}}_{q\in \mathcal{Q},{\tau }^{\prime }\sim \pi (\cdot \mid {\mathcal{S}}_q,q)}R({\tau }^{\prime },q)>{\mathbb{E}}_{q\in \mathcal{Q},\tau \sim \pi (\cdot \mid q)}R(\tau ,q).$ 直觉上，SkillX 有效的原因是它把“经验”从不可控的长轨迹压缩成三种检索单位：planning skill 降低搜索空间，functional skill 给出可复用工具组合，atomic skill 修补原始 tool schema 没写清楚的边界条件。弱模型最容易在长程任务中反复试错或漏掉前置条件；SkillX 把这些常见失败前置到 prompt 中，相当于把强模型已经探索出的工具使用路线变成可共享先验。

3.2 Multi-Level Skills Design：三层技能粒度

• Atomic skill $s_{\text{atomic}}$：绑定单个工具 $t\in \mathcal{T}$，是工具 schema 的执行增强版，包含参数约束、典型调用模式、失败模式和注意事项。它的输入是轨迹中与某个 tool 相关的调用片段，输出是单工具可复用说明。若删除这一层，模型只能依赖原始 API schema，容易 hallucinate 不存在的参数、忽略 prerequisite 或误用返回值。
• Functional skill $s_{\text{func}}$：绑定子任务 $q_{\text{subtask},i}$，可看成由多个工具组成的 macro-operation。论文假设任务 $q$ 可分解为 $\{q_{\text{subtask},1},\dots ,q_{\text{subtask},n}\}$，functional skill 对应完成某个子任务所需的工具集合 ${\mathcal{T}}_{\text{func}}\subseteq \mathcal{T}$。若删除这一层，agent 仍知道每个工具怎么用，但缺少“为了达成某个业务目标应该把哪些工具串起来”的过程知识。
• Planning skill $s_{\text{plan}}$：对齐子任务组织结构，例如顺序、依赖、分支。它不直接给出全部 tool calls，而是告诉 agent 先做什么、后做什么、哪些前置条件必须满足。若删除这一层，retrieval 会更依赖原始 query 相似度，在 user profile 或上下文变化大时容易找错经验。

3.3 Rollout and Skills Extraction：从成功轨迹中抽三层技能

给定训练任务 $q$，SkillX 先进行大小为 $m$ 的 rollout，复用 agent 的 inference 过程收集轨迹；然后用 skill extractor $f$ 从轨迹抽取候选技能。论文重点不是从所有轨迹中抽，而是从成功轨迹压缩出可泛化模式，并显式过滤探索、回溯、trial-and-error 这类对复用有害的步骤。若环境反馈太长，作者会先总结反馈，减少抽取时的噪声。

Planning skill extraction 把成功轨迹压缩成有序高层步骤；functional skill extraction 以 planning skill 为指导，对每个 subtask 抽取一个包含 name、document、content 的技能，其中 document 描述输入、输出、使用说明，content 描述完成该子任务的工具调用模式；atomic skill extraction 则针对单个工具总结调用模式、常用参数、约束和失败模式。released code 中 core/skill.py 和 core/skill_schema.py 进一步统一了字段：name、document、content、tools、metadata/skill_type。

def extract_multilevel_skills(trajectory_item, llm, skill_library):
    user_task = trajectory_item["user_task"]
    trajectory = trajectory_item["successful_trajectory"]
 
    plan = PlanExtractor(llm).extract({
        "user_task": user_task,
        "task_history": trajectory,
    })["plan"]
 
    functional_skills = []
    for step in parse_plan_steps(plan):
        if "api" not in step.lower():
            continue
        skills = FunctionalSkillExtractor(llm).extract({
            "user_task": user_task,
            "successful_trajectory": trajectory,
            "plan": step,
            "exp_metadata": {"skills": skill_library.get_all_skills()},
        })
        functional_skills.extend(skills)
 
    used_tools = collect_tools_from_trajectory(trajectory)
    covered_tools = collect_tools_from_skills(functional_skills)
    atomic_skills = []
    for tool_name in used_tools - covered_tools:
        atomic_skills.extend(AtomicSkillExtractor(llm).extract({
            "user_task": user_task,
            "successful_trajectory": trajectory,
            "specific_tool": tool_name,
            "exp_metadata": {"skills": skill_library.get_skills_by_tool(tool_name)},
        }))
 
    return {"plan": plan, "functional": functional_skills, "atomic": atomic_skills}

3.4 Iterative Skills Refinement：merge、filter、update

第 $k$ 轮从当前技能库 ${\mathcal{D}}^{(k)}$ 开始，对训练任务采样轨迹： ${\tau }^{(k)}\sim \pi (\cdot \mid {\rho }_{{\mathcal{D}}^{(k)}}(q),q),q\in {\mathcal{Q}}_{\mathrm{train}}.$ 设 ${\mathcal{K}}^{(k)}=\{{\tau }_1^{(k)},\dots ,{\tau }_{N_k}^{(k)}\}$，每条轨迹通过抽取器产生候选技能 ${\mathcal{S}}_i^{(k)}=f({\tau }_i^{(k)})$，候选集合为： ${\mathcal{S}}^{(k)}={\bigcup }_{i=1}^{N_k}{\mathcal{S}}_i^{(k)}.$ SkillX 用 refinement operator $\varphi$ 做 merge 和 filter，再更新库： ${\mathcal{D}}^{(k+1)}\triangleq {\mathcal{D}}^{(k)}\cup \varphi \left({\mathcal{S}}^{(k)}\right)={\mathcal{D}}^{(k)}\cup \varphi \left({\bigcup }_{i=1}^{N_k}{\mathcal{S}}_i^{(k)}\right).$ 优化目标是选择使测试任务期望成功率最高的迭代轮次： ${\max }_k{\mathbb{E}}_{q\sim {\mathcal{Q}}_{\mathrm{test}}}\left[{\mathbb{E}}_{\tau \sim \pi (\cdot \mid {\rho }_{{\mathcal{D}}^{(k)}}(q),q)}\right[R(\tau ,q)\left]\right].$ Skills Merge 的思想是：对某个 skill $s$，先用 embedding 取语义相似邻居 $\mathcal{Z}(s)=\{1,\dots ,z\}$；每个邻居给出一个候选更新方向 ${\delta }_i$，有 $s_i^{\prime }=s+{\delta }_i$；再把方向聚合为 ${\delta }_{\text{agg}}={\sum }_{i\in \mathcal{Z}(s)}{\delta }_i$，得到 $s^{+}=s+{\delta }_{\text{agg}}$。如果合并后的 skill 太复杂，提示词会要求进一步 decompose 成更小的模块。

Skills Filter 是两阶段：General Filter 删除不可移植、过度封装、依赖额外 Python package、参数过度具体或 functional-style 的技能；Tool-specific Filter 用环境工具 schema 验证工具名、参数和结构，拒绝不存在工具、无效参数或 schema-incompatible arguments。之后 Skill Library Update 对每个技能执行 add、modify 或 keep。

async def refine_skill_library(skill_library, extracted_skills, llm, embeddings):
    # Stage 1: quality/schema filtering before merge, matching pipeline.py default filter_timing="pre_merge".
    filtered = await TwoStageFilterPipeline(llm).filter(extracted_skills)
 
    # Stage 2: semantic clustering with DBSCAN; code default eps=0.10 means cosine similarity ≈ 0.90.
    texts = prepare_skills_for_clustering(filtered)
    cluster_ids = await DBSCANClustering(eps=0.10, metric="cosine").cluster_async(texts)
 
    merged = []
    for _, indices in cluster_ids.items():
        group = [filtered[i] for i in indices]
        if len(group) == 1:
            merged.append(group[0])
        else:
            merged_skill = await SkillMerger(llm, max_group_size=15).merge(group)
            merged.append(merged_skill or group[0])
 
    # Stage 3: normalize fields and merge into the persistent SkillLibrary.
    skill_objects = [Skill.from_dict(complete_required_fields(x)) for x in merged]
    skill_library.merge(skill_objects, epoch=skill_library.current_epoch + 1)
    return skill_library

论文公式与 released code 实现差异：论文把 filter 写成统一的 two-stage quality control，但 filtering/pipeline.py 在 main@0137cb8c 中让 atomic skills 绕过 Stage 1 General Filter，只在结构准备后进入 Stage 2 Tool Schema Filter；因此 atomic skill 的“质量过滤”在代码里更偏 schema-validity，而不是完整的 general quality check。另一个差异是论文实验使用 GLM-4.6、最多 3 轮 refinement 和 expansion，而 pipeline.py::run_pipeline 的默认值是 model="gpt-4.1-2025-04-14"、num_epochs=1、enable_expansion=False，复现实验时必须显式覆盖这些默认值。

3.5 Exploratory Skills Expansion：经验引导探索覆盖稀缺工具

仅靠 seed training set 会漏掉大工具空间中的大量 API。SkillX 因此采用 experience-guided exploration：统计已有 rollout 中哪些工具稳定成功、哪些工具失败率高、哪些工具从未被调用；探索时避免反复探索 stable APIs，优先覆盖 risky APIs 和 uncovered APIs。探索轨迹会被总结成新的合成任务 ${\mathcal{Q}}_{\mathrm{syn}}$，再重新走 extraction/refinement pipeline。相比 random exploration，这种策略减少重复发现，能在少量训练样本下扩展技能覆盖。

async def expand_with_experience_guidance(seed_task, trajectories, existing_skills, llm, available_tools):
    tracker = ExperienceTracker()
    tracker.set_available_apis(available_tools)
    tracker.load_from_trajectories(trajectories)
    tracker.load_from_skills(existing_skills)
 
    guidance = tracker.get_exploration_guidance()
    # guidance contains stable APIs, risky APIs, and unexplored APIs.
    exploration = await ExperienceGuidedExplorationStrategy(llm).explore({
        "task_id": seed_task["task_id"],
        "user_task": seed_task["user_task"],
        "available_tools": available_tools,
        "experience_guidance": guidance,
    })
 
    new_objectives = []
    for traj in exploration:
        objectives = await ExperienceGuidedExplorationStrategy(llm).summarize(seed_task, traj)
        new_objectives.extend(deduplicate_against_existing_tasks(objectives))
    return tasks_to_training_trajectories(new_objectives)

3.6 SkillX Usage：plan-first retrieval 与 prompt 注入

在解决新任务 $q$ 时，SkillX 不直接用 raw query 检索所有经验。它先检索相似 planning skills $\mathcal{P}(q)=\rho (q)$，再让 LLM 基于当前任务和参考计划生成 pseudo-plan： $\tilde{p}(q)={\mathrm{LLM}}_{\text{rewrite}}(q,\mathcal{P}(q)).$ 为了避免 pseudo-plan 的 speculative 内容污染执行，论文说明 pseudo-plan 不直接注入最终 system prompt，而是作为中间检索 query。设 $\tilde{p}(q)=\{{\text{step}}_1,\dots ,{\text{step}}_p\}$，对每个 step 检索 skill： ${\mathcal{S}}_i=\rho ({\text{step}}_i),{\mathcal{S}}^{\prime }=\mathrm{dedup}\left({\bigcup }_{i=1}^p{\mathcal{S}}_i\right),$ 再由 LLM selector 保留与任务和 pseudo-plan 都相关的最终集合： ${\mathcal{S}}_q=LLM\_select(q,\tilde{p}(q),{\mathcal{S}}^{\prime }).$

async def prepare_skill_augmented_prompt(task, base_prompt, skill_library, llm, available_tools):
    retriever = SkillRetriever(
        skill_library=skill_library,
        embedding_service=EmbeddingService(model="Qwen3-Embedding-8B"),
        similarity_threshold=0.45,
    )
 
    retrieved_plans = await retriever.retrieve_plan(task, top_k=3)
    pseudo_plan = await PlanRewriter(llm).rewrite(task, retrieved_plans)
 
    raw_skills = await retriever.retrieve_skills_for_plan(
        plan=pseudo_plan or task,
        skills_per_step=4,
        tool_filter=set(available_tools),
    )
    raw_skills = semantic_deduplicate(raw_skills, threshold=0.95)
 
    if len(raw_skills) > 8:
        selected = await SkillSelfFilter(llm).filter(task, pseudo_plan or task, raw_skills)
    else:
        selected = raw_skills[:8]
 
    return format_system_prompt(base_prompt, selected)

论文公式与 released code 实现差异：inference/skill_usage.py 的 SkillUsageService.prepare_prompt 在 main@0137cb8c 中调用 self.rewriter.rewrite(task=task, retrieved_plan=plan)，但 PlanRewriter.rewrite 的签名是 rewrite(task, retrieved_plans: List[Dict], context=None, **kwargs)。这说明 pinned release 的 high-level usage service 与 paper 描述的 plan-list rewrite 路径存在接口不一致；上面的伪代码按论文意图和 PlanRewriter 实际签名写法整理，复现时需要修正该调用或绕过 SkillUsageService.prepare_prompt。

Code reference: main @ 0137cb8c (2026-04-30) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
SkillKB 三层表示	core/skill.py, core/skill_schema.py	Skill, FunctionalSkill, AtomicSkill, PlanSkill, SkillLibrary, UnifiedSkill
总 pipeline / 多轮构建	pipeline.py	IterativeSkillPipeline.run, _run_epoch, _cluster_and_merge, _expand, run_pipeline
Planning skill 抽取	extraction/plan_extractor.py	PlanExtractor.extract, PlanCombiner.combine_grouped_plans
Functional / Atomic skill 抽取	extraction/skill_extractor.py	FunctionalSkillExtractor.extract, AtomicSkillExtractor.extract, HybridSkillExtractor.detect_missing_tools
两阶段过滤	filtering/pipeline.py, filtering/base.py	TwoStageFilterPipeline.filter, GeneralFilter, ToolSchemaFilter
语义聚类与合并	clustering/dbscan.py, clustering/merger.py	DBSCANClustering.cluster_async, SkillMerger.merge, merge_clusters
Experience-guided expansion	expansion/strategies/experience_guided.py, expansion/task_manager.py	ExperienceTracker.get_exploration_guidance, ExperienceGuidedExplorationStrategy.explore, summarize, TaskSynthesisManager
Inference-time retrieval	inference/retriever.py, inference/plan_rewriter.py, inference/skill_usage.py	SkillRetriever.retrieve_plan, retrieve_skills_for_plan, PlanRewriter.rewrite, SkillUsageService.prepare_prompt
Benchmark schemas / configs	config/settings.py, config/schemas/	EmbeddingConfig, ClusteringConfig, ExtractionConfig, ToolSchemaRegistry

4. Experimental Setup (实验设置)

Benchmarks / Datasets

Benchmark	Training split / scale	Test split / metric scope	Task type
BFCL-v3	base multi-turn category randomly split into 50 training instances	150 test instances	多轮 function calling 与工具组合
AppWorld	90 training instances	Test Normal category	九类真实应用生态中的 API/coding agent 任务
${\tau }^2$-Bench	benchmark-defined training/test splits per sub-domain；论文未详细列出每个子域样本数	Retail / Airline / Telecom domains	用户-客服多轮对话 + tool-use

Baselines / Models

基础模型包括 Qwen3-32B、Kimi-K2-Instruct-0905、GLM-4.6，并在 further analysis 中额外评估 DeepSeek-V3.2 与 GPT-4.1。对比方法包括 No Memory、A-Mem、AWM、ExpeL 和 SkillX。论文区分两种经验来源：* 表示经验抽取模型与执行模型一致，‡ 表示用 GLM-4.6 抽取经验、原模型执行，重点检验强模型经验向弱模型迁移。

Metrics

• Avg@4：四次独立运行的平均成功率，用于 BFCL-v3 与 AppWorld。
• Pass@4：四次运行中至少一次成功的概率，用于 BFCL-v3 与 AppWorld。
• Pass^1 / domain pass rate：${\tau }^2$-Bench 按原 benchmark 设置运行四次后报告的通过率，论文表格按 Retail / Airline / Telecom 分列。
• Execution efficiency：Figure 3e / 3f 分析平均执行步数和平均输入 tokens，用来验证 SkillX 是否减少冗余探索；论文强调其不是总能达到最低 steps/tokens，但在成功率与效率上综合更优。

Training / construction config

实验中的 SkillX 构建使用 GLM-4.6 作为强 agent backbone。Appendix implementation 给出的关键配置是：experience extraction 阶段（reasoning + extraction）temperature 为 0.9；每个 training task 独立采样 4 条 trajectories；超过 1500 tokens 的环境反馈会被 summarizer 压缩；DBSCAN 以 cosine similarity 0.9 聚类技能，每个 cluster 最多截断到 15 个 skills；skill updates 最多 3 轮 iterative refinement；skill expansion 阶段 exploration temperature 为 1.0，并且每个 training task 探索 1 次。

Skill usage 阶段用 FAISS HNSW 建语义向量库，embedding 为 Qwen3-Embedding-8B。检索先取 Top-100 nearest skills，再保留 cosine similarity 至少 0.45 且距离 best match 不超过 0.08 的候选；近重复去重阈值为 pairwise cosine similarity > 0.95；最后用 MMR 返回最多 8 个 skills，relevance-diversity 权重为 0.75。released code 中相应默认值可在 config/settings.py 看到：EmbeddingConfig.model="Qwen3-Embedding-8B"、index_type="FAISS-HNSW"、similarity_threshold=0.45、ClusteringConfig.eps=0.10、min_samples=1、ExtractionConfig.batch_size=10、max_concurrent=5、max_retries=5、filter_threshold=0.999。论文未详细说明 GPU/硬件、optimizer、learning rate；这更像 API/model-based agent pipeline，而不是参数训练实验。

5. Experimental Results (实验结果)

Main benchmark results

Model	Method	BFCL Avg@4	BFCL Pass@4	AppWorld Avg@4	AppWorld Pass@4	${\tau }^2$ Retail	${\tau }^2$ Airline	${\tau }^2$ Telecom
Qwen3-32B	No Memory*	53.67	73.33	27.68	47.62	53.75	38.75	36.25
Qwen3-32B	best baseline before SkillX	59.33	78.83	34.45	58.93	58.12	43.75	41.25
Qwen3-32B	SkillX‡	63.67	82.00	35.12	58.93	66.87	47.50	43.75
Kimi-K2-Instruct-0905	No Memory*	65.17	78.00	46.88	70.24	75.62	51.25	78.12
Kimi-K2-Instruct-0905	best baseline before SkillX	66.33	79.67	52.98	78.87	77.50	56.25	79.37
Kimi-K2-Instruct-0905	SkillX‡	66.83	81.33	56.40	81.55	78.12	58.75	82.50
GLM-4.6	No Memory*	76.67	83.33	60.27	83.33	76.25	70.00	70.63
GLM-4.6	best baseline before SkillX	78.83	85.33	64.14	85.12	77.50	72.50	71.25
GLM-4.6	SkillX*	79.50	86.00	64.88	88.69	82.50	76.25	71.88

主结论是 SkillX 在三类模型、三类 benchmark 上几乎都给出最优结果。对 Qwen3-32B 这种弱一些的 base agent，SkillX‡ 相比 No Memory* 在 BFCL Avg@4 从 53.67 到 63.67，提升正好 10.00；在 ${\tau }^2$ Retail 从 53.75 到 66.87，提升 13.12。Kimi-K2 的提升集中在 AppWorld：Avg@4 从 46.88 到 56.40，Pass@4 从 70.24 到 81.55。GLM-4.6 本身已经很强，Pass@4 增益较小，但 SkillX* 仍在 AppWorld Pass@4 达到 88.69，在 ${\tau }^2$ Retail / Airline 达到 82.50 / 76.25。

Figure 3 解读：Figure 3a/3b 分析不同 skill level 对 AppWorld 的影响。Planning skills 普遍减少执行步数，弱模型尤其受益；functional skills 对性能提升贡献最大，因为它们直接提供工具组合过程；atomic skills 补充关键 API 约束，缺失时性能明显下降。Figure 3c 展示 iterative refinement 多轮更新在 train/test 上继续提升，但也暗示训练数据少时 text-only optimization 可能过拟合，需要选择合适轮数。Figure 3d 比较 random exploration 与 experience-guided expansion，后者能发现更多 novel skills，并带来性能增益。Figure 3e/3f 显示 SkillX 通常减少平均执行步数和输入 token，但论文也承认最低 steps/tokens 并不总等于最高成功率，最终优势来自成功率与效率的折中。

Other base models

Model	Method	BFCL Avg@4	BFCL Pass@4	AppWorld Avg@4	AppWorld Pass@4
DeepSeek-V3.2	No Memory	64.33	81.33	61.90	84.08
DeepSeek-V3.2	SkillX GLM-Extract	67.17	83.33	64.28	86.90
DeepSeek-V3.2	SkillX Self-Extract	67.83	84.67	65.48	88.39
GPT-4.1	No Memory	49.66	58.39	66.37	82.74
GPT-4.1	SkillX GLM-Extract	60.00	69.33	66.82	84.52
GPT-4.1	SkillX Self-Extract	50.67	56.67	68.60	82.14

这个表说明 SkillX 不只对弱模型有效。DeepSeek-V3.2 在自抽取和 GLM 抽取下都有提升；GPT-4.1 在 BFCL 上用 GLM-Extract 提升非常大（Avg@4 49.66 → 60.00，Pass@4 58.39 → 69.33），但 Self-Extract 在 BFCL Pass@4 反而低于 No Memory（56.67 vs 58.39），说明“经验来源更强”不一定是唯一因素，经验表示、抽取质量和 benchmark/tool schema 匹配同样关键。

Ablation study

Method	BFCL Avg@4	BFCL Pass@4	AppWorld Avg@4	AppWorld Pass@4
No Memory	76.67	83.33	60.27	83.33
Vanilla-Iter1	78.50	85.33	62.35	83.33
Vanilla-Iter2	79.50	86.00	64.29	85.12
Vanilla-Iter3	78.83	84.67	61.46	85.71
Expand-Iter1	78.50	85.33	64.58	83.93
Expand-Iter2	78.83	85.33	64.88	87.50
Expand-Iter3	78.83	84.67	64.88	88.69

Vanilla-Iter1 只用 multi-level skills design，已经超过 No Memory；Vanilla-Iter2/3 加入 refinement；Expand-Iter1 加入 skill expansion；Expand-Iter2/3 同时包含 multi-level design、refinement、expansion。BFCL 上最佳是 Vanilla-Iter2（79.50 / 86.00），AppWorld 上最佳 Avg@4 是 Expand-Iter2/3（64.88），最佳 Pass@4 是 Expand-Iter3（88.69）。这支持两个细节判断：一是三层表示本身就是主要收益来源；二是 refinement/expansion 的收益依赖 benchmark，过多 iteration 可能不总是单调提升。

论文没有在 ${\tau }^2$-Bench 上做 refinement/expansion ablation，理由是该 benchmark 的工具 schema 数量和依赖结构相对简单，训练集已经覆盖很多任务模式；对更偏用户对话、非 function-call 的设置，tool-schema-centered skills 是否是最佳经验学习形式仍是开放问题。

Case studies

Figure 4 解读：AppWorld 例子要求根据室友建议更新 Spotify playlist。无技能 agent 卡在 playlist retrieval / pagination / cross-app 信息整合，reward 为 0；SkillX 检索到 Spotify 认证、playlist 获取、phone message cross-app retrieval 等技能后，一次性完成相关 API 调用，reward 为 1。这个例子体现 functional skill 的价值：它不是告诉模型“要更新歌单”这种抽象 insight，而是给出跨 app tool chain。

Figure 5 解读：BFCL 例子要求把 gallons 转成 liters、启动发动机、检查胎压并发 Twitter。无技能 agent 直接调用 engine start，漏掉 lock doors / press brake pedal 等 prerequisite，最终失败；SkillX 的 skill library 提供 vehicle engine start sequence、twitter posting 等原子/功能技能，使 agent 按 lock doors → press brake pedal → start engine → check tire pressure → post tweet 的顺序执行。这里 atomic skill 的作用很明显：原始工具名无法保证模型知道前置状态机。

Figure 6 解读：${\tau }^2$-Bench 航空案例中，用户先订机票又切换到延误补偿。无技能 agent 无法在 topic shift 后正确检索 reservation、验证 flight delay 并生成补偿 voucher；SkillX 检索到 request flight booking、delay compensation workflow、certificate/status checking 等技能后，能在多轮对话中保持任务状态并完成补偿。这个例子说明 planning skill 对用户交互场景尤其重要，因为它给出了“先定位 reservation，再确认延误，再执行 compensation”的顺序。

Limitations / caveats

作者明确列出两个限制。第一是 Cross-environment transfer：SkillX 最自然适用于工具 schema 较稳定的环境，因为抽取出的 skill 与特定 tool schema 绑定；如果换到完全不同工具生态，直接复用会变难。第二是 User-interactive settings：当前研究主要覆盖 tool-using agent environments；对于没有 function call 或工具 schema 很弱的纯对话场景，是否应继续用 tool-centered skill 表示还不确定。

另外，从 released code 看，SkillX 目前更像 research framework / skill KB construction toolkit，而不是一键复现实验脚本：论文实验中的 GLM-4.6、3 轮 refinement、exploration 温度、每任务 4 trajectories 等关键数值主要来自 paper Appendix；代码默认配置并不自动等于论文实验配置。因此，复现时应以 paper Appendix + 显式 pipeline 参数为准，而不能只运行 config/settings.py defaults。