Agent的技能库看起来很美好，但真用起来呢？这篇论文给出了残酷的答案
你有没有碰到过这种情况：给Agent配了一堆精心设计的skill（技能/工具），demo里跑得贼溜，结果一到真实场景就拉胯？
我之前在做Agent系统的时候，也遇到过类似的困惑——手动给Agent挑好技能，效果确实不错；但让它自己从几万个技能里挑，那简直是灾难。这篇来自UCSB的论文，终于把这个问题掰开揉碎讲清楚了。
核心摘要
这篇论文做了一件很"扎心"的事：它系统性地测试了LLM Agent在"理想化"到"真实"的不同条件下使用技能的表现。结论让人冷静——随着场景越接近真实，技能带来的增益持续衰减，最终接近于"不用技能"的baseline。比如Claude Opus 4.6的pass rate从55.4%（手动喂好技能并强制加载）一路掉到38.4%（自主检索、没有定制技能），而不用技能的baseline是35.4%。也就是说，费了半天劲检索到的技能，只多了3个点。不过好消息是，如果在推理时做一步"技能精炼"（query-specific refinement），Claude在Terminal-Bench 2.0上从57.7%提升到65.5%，涨了近8个点。
定位上，这是一篇诊断性研究——不是提出新方法，而是把"Agent技能到底好不好用"这个问题的答案从模糊变成了清晰。
论文信息
- 标题: How Well Do Agentic Skills Work in the Wild: Benchmarking LLM Skill Usage in Realistic Settings
- 作者: Yujian Liu, Jiabao Ji, Li An, Tommi Jaakkola, Yang Zhang, Shiyu Chang
- 机构: UC Santa Barbara
- 链接: arXiv:2604.04323
- 日期: 2026年4月
问题动机：理想化benchmark可能在骗你
先聊聊背景。近来Agent社区有个热门方向：给LLM Agent配"技能库"（skill library）。一个skill就是一段可以复用的代码/知识片段，Agent在执行任务时可以加载它来辅助。之前SkillsBench这个benchmark已经验证了：当你手工挑好task-specific的技能直接塞给Agent，效果确实涨了不少。
但问题是，这个设置太理想了。
真实场景是什么样的？你的技能库里可能有3万多个来源各异的技能，Agent需要自己搞清楚哪些有用、检索出来、选择加载、然后正确使用。中间任何一步出问题，技能就等于白给。
这篇论文的核心追问就是：从"手工喂好"到"自主检索"这条路上，性能到底掉了多少？掉在哪？能补回来吗？
图1：SkillsBench中的一个洪水检测任务示例。上方是任务描述，下方是三个为该任务手工定制的技能（usgs-data-download、nws-flood-thresholds、flood-detection），每个技能都包含具体的API调用方法和代码片段。这就是"理想化"设置——技能完美匹配任务需求，现实中几乎不可能。
方法核心：逐层剥洋葱式的评估框架
这篇论文最漂亮的设计，是构建了一个渐进式评估框架——从最理想到最真实，一共6个层级：
| 层级 | 设置 | 说明 |
|---|---|---|
| FL | 强制加载定制技能 | 上界：技能手选+强制加载 |
| CS | 定制技能可选 | Agent自己决定加不加载 |
| CD | 定制技能 + 干扰技能 | 选择难度加大 |
| Rw | 检索（含定制技能） | 需要从3.4万个技能中检索 |
| Ro | 检索（不含定制技能） | 技能库里没有task-specific的技能 |
| NS | 不用技能 | Baseline |
这个设计太聪明了——每往下走一级，就多引入一个真实世界的挑战（选择、检索、适配），可以精确定位性能到底掉在哪一步。
3.4万技能库怎么来的？
作者从GitHub上抓了一批有MIT或Apache 2.0开源许可的仓库，从中提取出34,198个真实的、格式化的skill，去重后作为检索池。这些不是为benchmark定制的——就是真实世界中散落的各种代码片段和工具脚本。
检索方案
论文测了多种检索方案，最终发现Agentic Hybrid Search效果最好——让Agent自己迭代地构建查询、用混合（关键词+语义）检索、评估候选技能，而不是简单的一次性语义匹配。
| 检索方法 | Recall@3 | Recall@5 | Recall@10 |
|---|---|---|---|
| 直接语义检索 | 38.1% | 47.0% | 52.3% |
| Agentic 关键词 | 24.1% | 26.6% | 27.5% |
| Agentic 语义 | 56.8% | 63.1% | 66.5% |
| Agentic 混合（不含内容） | 57.7% | 63.5% | 66.7% |
| Agentic 混合（含内容） | 57.3% | 65.5% | 68.3% |
直接语义检索在Recall@5才47%，也就是说一半的相关技能都找不到。Agentic方案把这个数拉到65.5%，但仍然有三分之一的技能漏掉了。这个数据其实很能说明问题——检索本身就是一个巨大的瓶颈。
实验结果：逐级衰减的残酷真相
看到下面这张图的时候，我第一反应是"果然如此"，但衰减幅度还是让我有点吃惊。
图2：三个模型（Claude Opus 4.6、Kimi K2.5、Qwen3.5-397B）在SkillsBench不同设置下的pass rate。从左到右代表条件越来越接近真实。注意Kimi和Qwen在"检索无定制技能"（Ro）时，表现甚至低于不用技能（NS）的baseline。
关键数据放在一起看：
| 模型 | FL（强制加载） | CS（定制可选） | CD（+干扰） | Rw（检索+定制） | Ro（检索-定制） | NS（无技能） |
|---|---|---|---|---|---|---|
| Claude Opus 4.6 | 55.4 | 51.2 | 43.5 | 40.1 | 38.4 | 35.4 |
| Kimi K2.5 | 38.5 | 38.9 | 33.7 | 33.5 | 19.8 | 21.8 |
| Qwen3.5-397B | 41.2 | 31.6 | 33.7 | 26.7 | 19.7 | 20.5 |
几个让人停下来想的点：
Claude是唯一一个始终能从技能中获益的模型。 即使在最真实的Ro设置下，38.4%还是比baseline 35.4%高了3个点。虽然不多，但至少没帮倒忙。
Kimi和Qwen就没这么好运了。 Kimi在Ro设置下只有19.8%，比不用技能的21.8%还低了2个点。Qwen也类似，19.7% vs 20.5%。检索来的不相关技能反而干扰了模型的正常发挥。
这个发现挺有工程价值的——如果你的模型不够强，盲目给它塞技能可能适得其反。不相关的技能不只是"没用"，它们是"有害的噪声"。
图3：左图（a）是包含强制加载设置的完整pass rate对比，右图（b）展示了各设置下Agent实际加载技能的比例。注意Claude在CS设置下只有49%的轨迹加载了所有定制技能，加入干扰后降到31%。而Kimi虽然加载率高达86%，但任务表现反而不好——加载了但用不好。
右图（b）特别有意思。Claude加载技能的比例不高（CS设置49%），但选择性很强——它会判断哪些技能值得用，哪些不值得。Kimi则是来者不拒（86%加载率），但加载了一堆用不好的技能，反而拖了后腿。
这说明技能使用的关键不是"加载多少"，而是"判断力"。更强的模型更懂得取舍。
技能精炼：能救回来多少？
论文提出了两种精炼策略：
Query-Specific Refinement（查询级精炼）：针对具体任务，Agent先用检索到的技能试着做任务，评估哪些work哪些不work，然后把多个技能的有用部分合成一个精炼后的技能。这个过程在推理时执行，计算成本高但效果好。
Query-Agnostic Refinement（任务无关精炼）：离线处理，用合成的测试查询来改进每个技能本身的质量。成本低但效果有限。
| 设置 | Claude Pass Rate | Kimi Pass Rate | Qwen Pass Rate |
|---|---|---|---|
| 定制技能 | 51.2 | 38.9 | 31.6 |
| 无技能 | 35.4 | 21.8 | 20.5 |
| 检索（含定制） | 40.1 | 33.5 | 26.7 |
| + Query-specific | 48.2 (+8.1) | 26.7 (-6.8) | 30.8 (+4.1) |
| + Query-agnostic | 42.0 (+2.0) | -- | 26.2 (-0.5) |
| 检索（不含定制） | 38.4 | 19.8 | 19.7 |
| + Query-specific | 37.9 (-0.5) | 23.1 (+3.3) | 21.5 (+1.8) |
有几个发现值得聊：
Query-specific精炼对Claude在"有定制技能"时效果拔群，从40.1%直接拉到48.2%，涨了8.1个点。但条件是初始检索到的技能质量要够——论文用LLM-as-Judge评分发现，当coverage score >= 3.83时精炼才有效，低于3.49就救不回来了。
坦率讲，Kimi在这里翻车了。Query-specific精炼反而让它从33.5%掉到26.7%，跌了6.8个点。这可能是因为Kimi在精炼过程中引入了更多错误信息，越改越差。
当技能库里根本没有相关技能（Ro设置），精炼也无能为力。 Claude从38.4%微降到37.9%。这很合理——巧妇难为无米之炊，如果检索到的技能全都不靠谱，精炼只是在错误的基础上修修补补。
图4：一个PyTorch张量并行任务的精炼案例。精炼前，Agent加载了两个部分相关的技能（torch-tensor-parallel和pytorch-research），但它们各有缺失——一个缺autograd wrapper，一个没并行支持。Agent执行失败（world_size=2时出错）。精炼后，Agent把两个技能的精华融合成一个新技能（tensor-parallel-linear），同时支持weight sharding和differentiable all_gather/all_reduce，成功通过所有测试。
Terminal-Bench 2.0：跳出SkillsBench看泛化
SkillsBench是专门为技能评估设计的，那在更通用的benchmark上呢？论文在Terminal-Bench 2.0上做了验证，这是一个通用的终端操作任务benchmark。
| 模型 | 无技能 | 检索 | + Query-specific | + Query-agnostic |
|---|---|---|---|---|
| Claude Opus 4.6 | 57.7 | 61.4 | 65.5 | 63.3 |
| Kimi K2.5 | 46.6 | 50.6 | 56.2 | -- |
| Qwen3.5-397B | 44.7 | 44.2 | 49.1 | 44.9 |
这组数据让人舒服多了。在Terminal-Bench 2.0上，三个模型都从技能中获益了，而且query-specific精炼的效果更加稳定。Claude从57.7%提到65.5%，涨了7.8个点。
为什么Terminal-Bench 2.0的结果比SkillsBench好？论文给出的解释是：Terminal-Bench的任务覆盖面更广（通用终端操作），从3.4万个GitHub技能中更容易检索到有帮助的通用技能。而SkillsBench的任务比较专门化，需要非常精确匹配的定制技能。
这也间接说明了一件事——通用技能库对通用任务有帮助，但对高度专业化的任务，你还是需要定制技能。
我的判断：扎心但有价值
亮点
-
实验设计精巧。 渐进式评估框架是这篇论文最值钱的贡献——它不只是测了一个结果，而是拆解了"从理想到真实"的每一步性能损失来自哪里。这种诊断性的工作，比又造一个新方法有意义得多。
-
3.4万真实技能库。 不是自己编的toy skill，而是从GitHub真实仓库中提取的。这让结论有工程可信度。
-
技能精炼的分析很诚实。 没有只报好的数据，也展示了精炼失败的case（Kimi越精炼越差），并分析了精炼有效的前提条件（初始技能质量要够好）。
问题和局限
坦率讲，有几个地方我觉得可以再追问：
技能的格式是否是瓶颈？ 论文里的skill是一段代码+元数据描述。但真实工程中的"技能"形态更丰富——可能是API endpoint、可能是一个完整的工具链、可能是一段最佳实践文档。当前的评估可能低估了更灵活的技能表示形式的潜力。
检索的上限在哪？ 论文用的最好的检索方案Recall@10也只有68.3%，这意味着还有三成相关技能找不到。如果用更强的检索（比如结合代码理解的专用embedding），性能曲线会不会好看很多？论文没有探索这个方向。
Query-specific精炼的成本问题。 论文坦承这个方法在推理时需要额外的LLM调用来探索任务、评估技能、合成新技能。但具体的token开销和延迟增加没有报告。在实际生产环境中，这可能是个很大的障碍。
只测了coding任务。 SkillsBench和Terminal-Bench都是编程/终端操作类任务。在其他类型的Agent任务（网页操作、数据分析、多步推理）上，结论是否成立还不清楚。
工程启发
如果你正在做Agent技能系统，这篇论文给了几个很实在的提示：
- 不要高估技能的收益，尤其是当你的模型不是最强的那一档。先测一下"不用技能"的baseline，再决定要不要投入精力做技能系统。
- 技能检索比技能设计更重要。 有了好技能但检索不到，等于没有。
- 强模型更能从技能中获益，因为它们有更好的"判断力"来决定用不用、怎么用。弱模型反而会被不相关的技能干扰。
- Query-specific精炼是可行的，但前提是初始检索质量过关。如果检索到的技能完全不相关，精炼也救不了。
收尾
这篇论文最大的价值，不在于提出了什么新方法，而在于它用扎实的实验告诉你："Agent + 技能库"这个narrative没有看起来那么美好。在理想条件下的收益，到了真实场景会大幅缩水。
但这不是说技能系统没用——而是说我们需要把精力花在对的地方：更好的检索、更强的模型判断力、以及在推理时的技能适配。
还有一个更根本的问题这篇论文没有回答：如果Agent足够强，它还需要预定义的技能库吗？ 还是说，让Agent在需要时自己写工具就够了？这可能是接下来更值得探索的方向。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我