How Well Do Agentic Skills Work in the Wild: Benchmarking LLM Skill Usage in Realistic Settings

Paper: arXiv:2604.04323 Code: UCSB-NLP-Chang/Skill-Usage Code reference: main @ 03446d16 (2026-04-08)

1. Motivation (研究动机)

现有 agentic skills 评测过于理想化

这篇论文讨论的 agentic skills 指一类可复用、面向特定领域或任务的知识工件，通常以 SKILL.md、示例脚本、参考资料等形式提供给 LLM agent。它们在 Claude Code / Codex 类 agent 工作流里很常见：当 agent 知道某个任务需要某个 API、数据格式、CLI 约定或工程流程时，读取 skill 可以显著减少摸索成本。

问题在于，已有 skill benchmark 往往默认“正确的 skill 已经被人工挑好，并且直接放进 agent 上下文”。这对应论文里的 Curated + forced load 或接近 Curated 的环境：skill 是窄任务定制的，agent 不需要在大库中检索，也不需要判断哪些 skill 是噪声。这会高估 skills 在真实部署中的收益。

真实场景里有三层更难的瓶颈

论文把真实使用中的困难拆成三层：

Skill selection：即使 curated skills 已经在环境里，agent 也必须自己识别“应该加载哪些”。如果只看 skill 名称/描述，agent 可能不加载真正关键的 skill。
Skill retrieval：真实部署不会只给当前任务准备 2–3 个技能，而是要从一个大库里检索。本文构造了 34,198 个真实开源 skills 的集合，检索错误会让关键 skill 根本不进入候选集。
Skill adaptation：最现实的情况是没有任何人工为当前任务写好的 curated skill；agent 只能从通用 skill 里抽取部分有用知识，并适配到当前任务。

这三个瓶颈分别对应“会不会用”、“找不找得到”、“找到了是否能改造成可用知识”。论文的核心动机就是：skill 本身有用，并不等于 agent 在真实环境中能稳定享受这种收益。

为什么值得研究

如果 agentic skills 的收益只在人工挑选、强制加载的理想条件下成立，它们就很难扩展到真实 agent 平台：每个任务都靠人写/选 skill，成本会随任务规模线性膨胀。相反，如果能理解 skill utility 在 selection / retrieval / adaptation 下如何退化，就可以更有针对性地设计 skill search、metadata、refinement、agent harness 和评测协议。

本文的价值不在于提出一个单一新模型，而在于把“skills 在野外到底还能不能工作”做成可复现实验：用 34k skill collection、SkillsBench、Terminal-Bench 2.0、三个主流 agent harness，逐层测出退化曲线，并验证 refinement 能否补回损失。

更具体地说，这个问题直接关系到 agent 平台的可扩展性。如果每个新任务都必须由人类提前写好、放好、强制加载 skill，那么 skill 系统只是 prompt engineering 的局部优化；只有当 agent 能在大规模 skill pool 中自己检索、筛选、组合，并在任务反馈中修正 skill 时，它才可能成为长期记忆/工具使用基础设施。本文因此把“是否有 skill”拆成多个可测变量，而不是把所有失败都归因于模型能力不足。

2. Idea (核心思想)

核心 insight

本文最关键的 insight 是：agentic skills 的有效性不是一个静态属性，而是由 skill quality、retrieval quality、agent loading behavior 和 task-specific adaptation 共同决定的系统属性。在真实条件逐步加入后，skills 的 pass-rate 增益会系统性变脆弱，最现实设置下甚至接近 no-skill baseline。

主要创新

作者把 skill evaluation 从“给定 curated skills 后看 agent 会不会解题”改成一个逐级现实化的评测框架：先构建 34,198 个真实 skills 的大规模检索池，再比较 Direct / Agentic retrieval，随后在 SkillsBench 中依次加入 autonomous selection、distractors、retrieval、non-curated skills，最后用 query-agnostic 与 query-specific refinement 检验能否恢复性能。

和现有评测的根本差异

和 SkillsBench 原始设置相比，本文不再只问“人工写好的 skill 是否有用”，而是问“agent 能否在大规模真实 skill 库中找到、选择、组合并适配有用 skill”。和一般 RAG benchmark 相比，这里的被检索对象不是文档段落，而是可执行/可阅读的 agent skill 文件夹；成功也不是检索 recall 本身，而是最终任务 pass rate 与实际 skill loading rate。

这也解释了为什么本文同时报告 Recall@k、Pass、Load 与 coverage score：Recall@k 只衡量“候选里有没有正确 skill”，Load 衡量 agent 是否真的读/用它，Pass 衡量最终任务是否成功，coverage score 则解释 refinement 为什么有时有效、有时失效。四个指标连在一起，才能定位失败是在 search、selection、execution 还是 adaptation。

3. Method (方法)

3.1 Overall framework：从 skill pool 到 realistic benchmark

Figure 1 解读：左侧是 SkillsBench 中 USGS flooding days 任务的例子：三个 curated skills 分别提供 API 调用方式、flood threshold 数据源 URL、以及 flood detection 代码片段，说明高质量 task-specific skill 为什么能直接降低任务难度。右侧给出从 curated skills 到 retrieval-from-large-pool 的退化趋势：evaluation 越接近真实部署，pass rate 越低。这个图把全文问题压缩成一句话：技能本身可能非常有价值，但 agent 不一定能在真实条件下找到并正确使用它们。

整体流程可以拆成四步：

构建 skill collection：从 skillhub.club 与 skills.sh 两个聚合平台抓取开源 skill metadata，再回到原始 GitHub 仓库下载完整 skill 文件夹，包括 SKILL.md 与 helper files；只保留 MIT / Apache 2.0 许可，去掉空 name/description 的坏格式 skill，并按文件内容去重，得到 34,198 个真实 skills。
建立 skill search engine：每个 skill 建两种索引：metadata（name + description）与 full content（SKILL.md）。dense side 使用 Qwen/Qwen3-Embedding-4B，sparse side 使用 BM25。
定义 progressively realistic settings：在 SkillsBench 上从最理想的 force-loaded curated skills，一步步加入 autonomous loading、distractors、top-5 retrieval、移除 curated skills。
做 refinement：分别测试 query-agnostic refinement（不看目标任务，离线改每个 skill）与 query-specific refinement（先在目标任务中试用 retrieved skills，再合成/refine task-specific skills）。

直觉上，本文不是把 skill 当成一个“开关”，而是把它当成一个需要被搜索、读取、判断、组合、验证的中间资源。任何一环失败，最终 pass rate 都会接近 no-skill。

3.2 Skill search engine

Skill index 包含两个视角：

Metadata index：把 skill 的 name 与 description 拼接，用于快速判断 skill 主题是否匹配任务。
Content index：使用完整 SKILL.md，捕捉 metadata 中没有写出的 API、步骤、坑点和示例代码。

语义检索用 Qwen3-Embedding-4B；关键词检索用 BM25。代码中的 search_server/http_server.py 暴露 /keyword、/semantic、/hybrid、/detail/{skill_id} 四类端点；--include-content 开启后，semantic search 会把 metadata embedding 与 content embedding 做加权融合，README 中默认 content_weight=0.05。

一个简化的检索目标可以写成： $Recall@ k = \frac{∣ G _{t} \cap R _{t}^{(k)} ∣}{∣ G _{t} ∣},$ 其中 $G_{t}$ 是 SkillsBench 为任务 $t$ 人工标注的 ground-truth curated skills， $R_{t}^{(k)}$ 是检索出的前 $k$ 个 skill。对于 hybrid search，可以把 BM25 排名与 semantic 排名看作两个 ranked lists，用 reciprocal-rank-style fusion 合并： $S (s ∣ q) = λ_{kw} \cdot \frac{1}{r _{kw} ( s ) + 1} + λ_{sem} \cdot \frac{1}{r _{sem} ( s ) + 1} .$ 实际代码中 http_server.hybrid_search() 先分别取 BM25 与 semantic 的 top_k * 2 结果，再按 skill id 聚合两侧 rank-based scores，最后返回融合排序后的 top-k。

3.3 Retrieval methods：Direct vs Agentic

论文比较两大类检索：

Direct semantic search：直接把 task description 当 query，在 metadata dense index 上取 top-k。
Agentic search：给 agent 一个 find-skills skill 与 search API，让它多轮构造 query、查看候选、评估相关性，并最终把 skill ids 写入 found_skills.json。四个变体分别是 keyword-only、semantic-only、hybrid w/o content、hybrid w/ content。

Table 1 的 exact results：

Method	Recall@3	Recall@5	Recall@10
Direct (semantic)	38.1	47.0	52.3
Agentic (keyword)	24.1	26.6	27.5
Agentic (semantic)	56.8	63.1	66.5
Agentic (hybrid) w/o content	57.7	63.5	66.7
Agentic (hybrid) w/ content	57.3	65.5	68.3

这里最重要的结论是：同样使用 semantic search，agentic search 的 Recall@3 比 direct search 高 18.7 points（56.8 vs. 38.1）。这说明检索 skill 不只是 embedding nearest neighbor；agent 能通过多次查询把任务描述拆成 API、数据、工具、领域概念等不同搜索面。content index 在高 $k$ 上进一步提升 Recall@5/10（63.5→65.5、66.7→68.3），所以后续实验默认使用 agentic hybrid search w/ content。

3.4 Progressive evaluation settings

Figure 2 解读：Panel (a) 是 SkillsBench 上的 pass rate；Panel (b) 是 skill usage，solid bars 表示任意 skill 被加载的轨迹比例，hatched bars 表示所有 curated skills 都被加载的比例。横轴从 FL（force-loaded）到 NS（no skill）逐步变现实。Claude 在 curated skills 强制加载时达到 55.4%，但 autonomous curated setting 降到 51.2%，加 distractors 后降到 43.5%，检索 curated pool 时降到 40.1%，移除 curated skills 后只剩 38.4%，距离 no-skill 35.4% 只高 3.0 points。这个图说明性能退化并不是单点故障，而是 selection、retrieval、adaptation 层层叠加。

六个 SkillsBench 条件从理想到现实依次为：

Setting	含义	主要新增难点
Curated + forced load (FL)	原 curated skills 放入环境，并明确要求 agent 全部加载	上界；绕过 selection/retrieval/adaptation
Curated (CS)	原 SkillsBench 设置；skills 可用，但 agent 自己决定是否加载	skill selection
Curated + distractors (CD)	curated skills 仍可用，但加入从 34k pool 检索来的 distractors，总数保持 5	在噪声中识别 curated skills
Retrieved w/ curated (Rw)	从包含 curated skills 的 34k pool 中检索 top-5	skill retrieval
Retrieved w/o curated (Ro)	从不含 curated skills 的 34k pool 中检索 top-5	skill adaptation
No skills (NS)	不提供 skills	baseline

图中关键精确数字包括：Claude 的 pass rate 从 55.4% → 51.2% → 43.5% → 40.1% → 38.4% → 35.4%；Kimi 的 curated setting 为 38.9%，force-loaded 为 38.5%，retrieved w/ curated 为 33.5%，retrieved w/o curated 为 19.8%，no-skill 为 21.8%；Qwen 的前三个条件为 41.2% → 31.6% → 33.7%，retrieved w/ curated 为 26.7%，retrieved w/o curated 为 19.7%，no-skill 为 20.5%。

论文特别强调 loading 行为：Claude 在 curated setting 只有 49% trajectories 加载了所有 curated skills，加 distractors 后降到 31%；retrieved w/ curated 时任意 skill loading rate 是 44%，而 curated setting 是 62%；retrieved w/o curated 时 Claude 只有 16% trajectories 加载任意 skill。Kimi 在 curated setting 的 loading rate 更高（86%，Claude 为 62%），但 pass rate 并没有同步更高（38.9% vs. force-loaded 38.5%），说明“加载 skill”与“有效利用 skill 内容”不是一回事。

论文提出两类 refinement，用来减少 progressive setting 中暴露出的 selection/retrieval/adaptation gap。

Query-agnostic refinement 的目标是离线提升 skill collection 的整体质量。理想上应该改写全部 34k skills，但成本太高，所以实验中只对每个任务检索出的 skills 做近似。每个 skill 独立处理，不知道目标任务，也不知道其它 retrieved skills。流程借助 Anthropic skill-creator meta-skill：模型为当前 skill 生成 synthetic test queries，分别运行带 skill 与不带 skill 的 agent，比较输出，自评 skill 是否有帮助，再迭代改写 skill。优点是 inference-time 便宜；缺点是无法知道当前任务到底需要什么，也不能把多个 skills 的知识合成一个 task-specific guide。

Query-specific refinement 直接在目标任务 Docker 环境里运行。agent 读取 /root/task_instruction.md 和 /root/retrieved_skills/ 下的所有 retrieved skills，先尝试解题，记录哪些 skill 片段有用/误导/缺失，然后基于探索经验和 skill-creator 指南写出 refined skills。它不访问 ground-truth verifier，只能自评 trajectory correctness。论文和代码都限制为 single iteration。这种方法贵，因为每个任务都要额外跑一轮探索；但它能跨 skill 合成信息，并删除与任务无关的噪声。

Figure 3 解读：这是 Terminal-Bench 2.0 tensor parallelism 任务中的 query-specific refinement 例子。无 refinement 时，agent 检索到 torch-tensor-parallel 和 pytorch-research 两个部分相关 skills，但实际只加载前者；它懂 weight sharding，却缺少可微 collective wrappers，因此在 world_size > 1 时实现错误。refinement 后，agent 把第一个 skill 的 tensor parallelism 知识与第二个 skill 的 custom autograd.Function 模式合成一个新 skill，最终通过测试。这个例子说明 query-specific refinement 的价值不只是“改写更清楚”，而是 组合多个弱相关 skills 中互补的知识。

3.6 关键流程伪代码（基于 released code）

检索端点的核心逻辑可概括为：

def hybrid_search(query, top_k=10, keyword_weight=0.5, semantic_weight=0.5):
    bm25_hits = bm25.search(query, top_k=top_k * 2)
    semantic_hits = semantic.search(query, top_k=top_k * 2)
 
    scores = {}
    payload = {}
    for rank, hit in enumerate(bm25_hits):
        sid = hit["skill_id"]
        scores[sid] = scores.get(sid, 0.0) + keyword_weight / (rank + 1)
        payload[sid] = hit
    for rank, hit in enumerate(semantic_hits):
        sid = hit["skill_id"]
        scores[sid] = scores.get(sid, 0.0) + semantic_weight / (rank + 1)
        payload[sid] = hit
 
    return sorted(payload.values(), key=lambda h: scores[h["skill_id"]], reverse=True)[:top_k]

Agentic retrieval 在 scripts/retrieve_skills.py 中被实现成一个 Harbor task：

def retrieve_skills_for_task(task_dir, find_skills_skill, agent):
    temp_task = make_harbor_task(task_dir)
    copy_instruction(temp_task, "Read task_instruction.md and find relevant skills")
    copy_skill(temp_task, find_skills_skill, rewrite_localhost="host.docker.internal")
    run_agent_in_harbor(temp_task, agent=agent)
 
    found = read_json(temp_task / "found_skills.json")
    return found  # sorted skill ids, most relevant first

把检索结果注入任务环境的逻辑在 scripts/select_top_k_skills.py：

def select_top_k_skills(task_dir, found_skills, skill_collection, k=5):
    top_names = normalize_skill_ids(found_skills)[:k]
    clear_existing_environment_skills(task_dir)
    for name in top_names:
        src = skill_collection / name
        dst = task_dir / "environment" / "skills" / name
        copytree(src, dst)
    return top_names

Query-specific refinement 的 released code 会替换任务 instruction，让 agent 先探索任务再写 refined skills：

def query_specific_refine(task_dir, retrieved_skills, skill_creator, agent):
    temp_task = copy_task_with_environment(task_dir)
    mount(temp_task, "/root/retrieved_skills", retrieved_skills)
    mount(temp_task, "/root/agent_skills/skill-creator", skill_creator)
    write_instruction(temp_task, QUERY_SPECIFIC_PROMPT)
 
    run_agent_in_task_docker(temp_task, agent=agent)
    refined = read_dir(temp_task / "refined_skills")
    replace_environment_skills(task_dir, refined)
    return refined

Query-agnostic refinement 则按 unique skill 去重后逐个处理，并把结果缓存/分发回所有任务：

def query_agnostic_refine(all_tasks, skill_creator, agent):
    unique = find_unique_skills(all_tasks)  # deduplicate by skill name
    cache = {}
    for skill_name, skill_dir in unique.items():
        temp_task = make_skill_improvement_task(skill_name, skill_dir, skill_creator)
        run_agent_in_harbor(temp_task, agent=agent)
        cache[skill_name] = read_dir(temp_task / "refined_skill")
 
    for task in all_tasks:
        for skill_name in skills_used_by(task):
            if skill_name in cache:
                replace_skill(task, skill_name, cache[skill_name])
    return cache

结果统计中，pass rate 直接来自 benchmark verifier 的三次运行均值；skill usage 由 scripts/check_skill_usage.py 检测 trajectory 中的 Skill tool call 与对 skill 相关路径的 Read 调用。

3.7 Code-to-paper mapping

Code reference: main @ 03446d16 (2026-04-08) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
34k skill collection / task mappings	`data/task_skill_mapping.json`, `data/task_queries.json`, README HF dataset commands	ground-truth curated skill mapping; per-task search queries
Skill search server	`search_server/http_server.py`	`keyword_search`, `semantic_search`, `hybrid_search`, `get_detail`
Semantic index	`search_server/semantic_search.py`	`SemanticSearch`, `DEFAULT_EMBEDDING_MODEL = "Qwen/Qwen3-Embedding-4B"`
BM25 index	`search_server/bm25_search.py`	`BM25Search`
Agentic skill retrieval	`scripts/retrieve_skills.py`	`get_instruction_prompt`, `create_temp_task_dir`, `generate_harbor_config`, `collect_results`
Top-k skill injection	`scripts/select_top_k_skills.py`	`main` reads `found_skills.json` and copies top-k skill folders
Terminal-Bench Docker rewrite	`scripts/rewrite_dockerfile.py`	converts prebuilt-image tasks so skills can be copied into Docker build context
SkillsBench Claude config	`experiments/configs/skillsbench/claude.yaml`	`n_attempts: 3`, `timeout_multiplier: 1.5`, `model_name=claude-opus-4-6`
TerminalBench Qwen config	`experiments/configs/terminalbench/qwen.yaml`	`n_attempts: 3`, `timeout_multiplier: 2.0`, `model_name=Qwen/Qwen3.5-397B-A17B-FP8`
Query-specific refinement	`scripts/query_specific_refinement.py`	`create_temp_task_dir`, `collect_results`; uses `/root/retrieved_skills/` and `skill-creator`
Query-agnostic refinement	`scripts/query_agnostic_refinement.py`	`find_unique_skills`, `create_temp_skill_dir`, `collect_results`
Retrieval metrics	`scripts/eval_retrieval.py`	`recall_at_k`, `evaluate`
Pass-rate aggregation	`scripts/calculate_results.py`	aggregates Harbor job rewards
Skill loading analysis	`scripts/check_skill_usage.py`	detects Skill tool calls and skill-file reads
Coverage judge	`scripts/judge_skill_coverage.py`	LLM judge prompt and 1–5 coverage scoring
Actual evaluation configs	`experiments/configs/skillsbench/.yaml`, `experiments/configs/terminalbench/.yaml`	model/harness, `n_attempts`, timeout multipliers, concurrency

论文公式与 released code 实现差异：本文主要是 benchmark/evaluation pipeline，没有训练 loss 与 model implementation；released code 的实验配置与论文描述基本对齐。需要注意的是，论文正文说 “top-5 retrieved skills”，README/脚本也默认 select_top_k_skills.py 5；实际模型/timeout/retry 数字应以 experiments/configs/{skillsbench,terminalbench}/*.yaml 为准，而不是 Harbor 或 README 的泛化默认值。

4. Experimental Setup (实验设置)

Benchmarks and datasets

SkillsBench：论文使用 84 个任务，排除了 3 个有已知环境或 verifier 问题的任务：mhc-layer-impl、scheduling-email-assistant、fix-visual-stability。repo 中 data/task_skill_mapping.json 与 data/task_queries.json 各有 87 个条目；实际 evaluation config 在 experiments/configs/skillsbench/*.yaml 中显式排除上述 3 个任务。
Terminal-Bench 2.0：使用全部 89 个任务，覆盖 system administration、file manipulation、programming challenges 等命令行环境任务。它不是为 skills 设计的，因此没有 human-curated skills；实验从 34k collection 中检索 top-5 skills。
Skill collection：34,198 个真实开源 skills，来自 skillhub.club 与 skills.sh；过滤 MIT / Apache 2.0 许可，去除坏 metadata，并按内容去重。

Models and agent harnesses

Model	Agent harness	Released config evidence
Claude Opus 4.6	Claude Code	`experiments/configs/*/claude.yaml`: `model_name=claude-opus-4-6`, `version=2.1.19`
Kimi K2.5	Terminus-2	`experiments/configs/*/kimi.yaml`: `model_name=openai/moonshotai/Kimi-K2.5`, `api_base=http://localhost:30000/v1`, `max_input_tokens=253952`
Qwen3.5-397B-A17B-FP8	Qwen-Code	`experiments/configs/*/qwen.yaml`: `model_name=Qwen/Qwen3.5-397B-A17B-FP8`, `version=0.12.3`, local SGLang OpenAI-compatible endpoint

论文未详细说明本地 SGLang 服务的 GPU 型号、GPU 数量或吞吐配置；released YAML 只给出 endpoint、model name 与 agent harness 参数。

Evaluation protocol and hyperparameters

每个 task/condition/model 跑 3 次，released configs 中显式为 n_attempts: 3。
Harbor orchestrator 本地并发为 n_concurrent_trials: 8。
SkillsBench timeout multiplier 对三个模型均为 1.5；对应 YAML 字段是 timeout_multiplier: 1.5。
Terminal-Bench 2.0 timeout multiplier：Claude 为 1.0；Kimi 与 Qwen 为 2.0，对应 timeout_multiplier: 2.0，用于补偿本地 serving 速度较慢。
任务均在 Harbor 提供的 isolated Docker containers 中运行，并使用 benchmark 自动 verifier 评估。
Skills retrieval 默认取 top-5 skills；Terminal-Bench 2.0 需要 scripts/rewrite_dockerfile.py 把 skills 复制进任务 Docker build context。

Baselines and compared methods

No skills：不给任何 skill。
Curated + forced load：强制加载所有 curated skills，作为 curated skill utility 的上界。
Curated / Curated + distractors：skills 可见但由 agent 自己决定加载；后者加入 distractors。
Retrieved (w/ curated) / Retrieved (w/o curated)：从 34k skill pool 检索 top-5，分别包含或移除 curated skills。
Retrieval baselines：Direct semantic、Agentic keyword、Agentic semantic、Agentic hybrid w/o content、Agentic hybrid w/ content。
Refinement baselines：Query-specific refinement、Query-agnostic refinement。

Metrics

Pass rate (Pass, %)：三次运行中通过自动 verifier 的平均比例。
Load rate (Load, %)：trajectory 中加载任意 skill 的比例；Figure 2 还额外报告“所有 curated skills 都被加载”的比例。
Recall@k：检索出的 top-k skills 覆盖 ground-truth curated skills 的比例。
Coverage score：GPT-5.4 judge 对初始 retrieved skill set 的 1–5 相关性/覆盖度评分；越高表示 retrieved skills 越能覆盖任务需求。

5. Experimental Results (实验结果)

5.1 Retrieval quality：agentic semantic/hybrid 明显优于 direct search

Table 1 显示 agentic retrieval 是必要的。Direct semantic Recall@5 只有 47.0，而 Agentic semantic 达 63.1；Agentic hybrid w/ content 达到最高 Recall@5/10（65.5 / 68.3）。Keyword-only 很差（Recall@5 26.6），说明 skill 检索依赖语义匹配；metadata 之外的 full SKILL.md content 对更大的 k 有帮助。

5.2 SkillsBench 上的收益逐层退化

在 Figure 2 中，Claude 的退化最清楚：55.4% force-loaded → 51.2% curated → 43.5% curated+distractors → 40.1% retrieved w/ curated → 38.4% retrieved w/o curated → 35.4% no-skill。也就是说，移除人工强制加载和人工 curated access 后，大部分 skill benefit 被 selection/retrieval/adaptation gap 消耗掉。

Kimi 与 Qwen 还显示了更强的负迁移风险：Kimi 在 retrieved w/o curated 下 19.8%，低于 no-skill 21.8%；Qwen 是 19.7%，低于 no-skill 20.5%。这说明低相关 retrieved skills 不只是“没帮助”，还可能让 agent 浪费上下文和行动预算，甚至被错误指导误导。

Benchmark / Setting	Method	Claude Pass / Load	Kimi Pass / Load	Qwen Pass / Load
SkillsBench	Curated skills	51.2 / 62.2	38.9 / 86.1	31.6 / 73.8
SkillsBench	No skills	35.4 / 0.0	21.8 / 0.0	20.5 / 0.0
SkillsBench w/ curated	Retrieved	40.1 / 44.4	33.5 / 69.7	26.7 / 65.5
SkillsBench w/ curated	+ Query-specific	48.2 / 72.2	26.7 / 95.2	30.8 / 75.0
SkillsBench w/ curated	+ Query-agnostic	42.0 / 32.9	— / —	26.2 / 68.3
SkillsBench w/o curated	Retrieved	38.4 / 16.3	19.8 / 37.7	19.7 / 54.8
SkillsBench w/o curated	+ Query-specific	37.9 / 61.1	23.1 / 90.9	21.5 / 69.4
SkillsBench w/o curated	+ Query-agnostic	37.4 / 12.3	— / —	24.6 / 53.2
Terminal-Bench 2.0	No skills	57.7 / 0.0	46.6 / 0.0	44.7 / 0.0
Terminal-Bench 2.0	Retrieved	61.4 / 40.8	50.6 / 79.0	44.2 / 31.1
Terminal-Bench 2.0	+ Query-specific	65.5 / 74.9	56.2 / 93.6	49.1 / 42.3
Terminal-Bench 2.0	+ Query-agnostic	63.3 / 33.7	— / —	44.9 / 38.4

Query-specific refinement 在 Table 2 的 9 个可比较场景中提升了 7 个。典型例子是 SkillsBench w/ curated retrieval：Claude 从 40.1% 到 48.2%，接近 curated setting 的 51.2%；Qwen 从 26.7% 到 30.8%。在 Terminal-Bench 2.0 上，query-specific 对三个模型都提升：Claude +4.1、Kimi +5.6、Qwen +4.9，说明这种策略不限于专门为 skills 设计的 benchmark。

Query-agnostic refinement 的收益更小且不稳定：例如 Claude 在 SkillsBench w/ curated 只从 40.1% 到 42.0%，Terminal-Bench 2.0 从 61.4% 到 63.3%。这符合方法假设：离线清理 skill 能改善格式与局部说明，但不知道目标任务，因此无法决定哪些内容该保留、删除或跨 skill 合成。

作者用 GPT-5.4 judge 给初始 retrieved skills 打 1–5 coverage score；Table 3 的精确数值如下：

Setting	Claude	Kimi	Qwen
SB: w/ curated	4.01	3.83	3.85
SB: w/o curated	3.49	3.31	3.39
TB: Retrieved	4.02	3.96	4.08

Query-specific refinement 在 coverage ≥3.83 的设置（SB w/ curated、Terminal-Bench）更有效；在 SB w/o curated 中，coverage ≤3.49，收益明显变弱甚至为负。这个结果说明 refinement 更像 amplifier，不是凭空生成知识的 generator：如果 retrieved skills 已经含有部分正确知识，探索与合成能放大它；如果初始 skill set 根本缺少相关知识，agent 很难从空白中发明可靠方法。

5.5 Limitations and takeaways

论文没有把 query-specific refinement 描述成免费解法：它需要每个任务额外跑一轮探索，inference-time 成本高；还依赖 agent 自评，而自评错误会导致 Kimi 在 SkillsBench w/ curated 从 33.5% 降到 26.7%。此外，本文没有报告本地 serving 的 GPU 细节，也没有证明 34k skill pool 覆盖所有真实任务域。

整体结论是：agentic skills 在理想设置中确实有用，但真实部署下收益脆弱。要让 skills 在野外工作，单纯“收集更多 skills”不够；必须同时改进 skill metadata、agentic retrieval、skill loading policy、以及 task-aware refinement。本文的 benchmark 价值在于把这些失败模式拆开测量，并给出 query-specific refinement 作为一个可行但昂贵的补救方向。

从工程角度看，最可操作的 takeaway 有三点：第一，skill metadata 不能只写泛泛描述，因为 agent 是否加载 skill 很大程度依赖 name/description 的可检索性；第二，retrieval top-k 的候选质量决定 refinement 上限，coverage 低于约 3.5 时 query-specific exploration 也很难补救；第三，评测 agentic skills 时必须同时记录“是否检索到”“是否加载”“是否通过 verifier”，否则很容易把 retrieval failure、loading failure 和 execution failure 混在一起。

Paper Notes

探索

How Well Do Agentic Skills Work in the Wild: Benchmarking LLM Skill Usage in Realistic Settings

How Well Do Agentic Skills Work in the Wild: Benchmarking LLM Skill Usage in Realistic Settings

1. Motivation (研究动机)

现有 agentic skills 评测过于理想化

真实场景里有三层更难的瓶颈

为什么值得研究

2. Idea (核心思想)

核心 insight

主要创新

和现有评测的根本差异

3. Method (方法)

3.1 Overall framework：从 skill pool 到 realistic benchmark

3.2 Skill search engine

3.3 Retrieval methods：Direct vs Agentic

3.4 Progressive evaluation settings

3.5 Query-agnostic vs Query-specific refinement

3.6 关键流程伪代码（基于 released code）

3.7 Code-to-paper mapping

4. Experimental Setup (实验设置)

Benchmarks and datasets

Models and agent harnesses

Evaluation protocol and hyperparameters

Baselines and compared methods

Metrics

5. Experimental Results (实验结果)

5.1 Retrieval quality：agentic semantic/hybrid 明显优于 direct search

5.2 SkillsBench 上的收益逐层退化

5.3 Refinement results：query-specific 通常有效，query-agnostic 更弱

5.4 Refinement 依赖初始检索质量

5.5 Limitations and takeaways

目录