当 Agent 只有十几个 Skill，把名称和描述全部放进上下文还能工作。候选数量增长到几万甚至更多时，这种方式会同时耗尽上下文、增加延迟，并让模型在大量相似描述中选错能力。
清华大学与字节跳动团队把这个问题定义为 Skill Retrieval Augmentation：Skill 不再默认出现在上下文里，而是存放在外部能力库中，系统根据当前任务动态检索、加载并执行。
这听起来像 RAG，但检索对象已经从“回答问题的资料”变成“改变 Agent 行为的可执行能力”。评测方法也必须随之改变。
Skill Retrieval Augmentation 由检索、选择性加载和实际执行三段组成
#Skill 检索不是文档检索
传统 RAG 主要寻找可以支撑回答的事实证据。Skill 除了描述，还可能包含适用条件、操作步骤、脚本、工具和资源。它不只告诉 Agent 知道什么，还告诉 Agent 何时、如何采取行动。
因此，语义最相近的 Skill 不一定最有用。两个 Skill 都可能与“分析财务报表”高度相关，但一个依赖当前环境没有安装的工具，另一个使用过时接口；一个适合生成摘要，另一个才真正完成用户要求。
Skill 检索最终要为下游效用负责，而不是只追求文本相似度。
#三段式评测：找到、加载、执行
论文把完整流程拆成三段。
第一段是检索：系统能否从大规模候选库中找出与用户任务相关的 Skill。
第二段是加载：Agent 能否判断候选里哪些真的有用，以及当前任务是否根本不需要外部 Skill。它还要决定加载完整正文、压缩版本还是其中一部分。
第三段是执行：相关 Skill 已进入工作上下文后，Agent 能否正确遵循程序、调用资源，并让最终任务结果变好。
这三段必须分别计分。否则最终任务失败时，无法判断是没找到、找到却没加载，还是加载以后没有执行好。
#SRA-Bench 如何构造
SRA-Bench 包含 5,400 个能力密集型任务和 636 个专家修订的 Gold Skill。这些 Skill 被混入 25,626 个从公开生态收集的干扰项，形成 26,262 个候选 Skill 的大库，其中真正相关的只占约 2.4%。
任务来自六类现有基准，覆盖定理应用、逻辑推理、工具工作流、医学计算、竞赛数学和代码库使用。研究者先从数据中的结构化标注识别可复用能力，再由模型起草 Skill、专家修正适用条件、步骤与边界。
Gold Skill 不能直接包含题目答案。即使检索正确，Agent 仍必须理解当前问题、抽取变量并执行程序。公开收集的 Skill 则提供更接近真实市场的长尾噪声与相似候选。
#最大问题不是没搜到，而是不知道要不要用
实验确认，检索并注入相关 Skill 可以提升强模型的任务表现。但更重要的发现出现在加载阶段。
不同模型的 Skill 加载率差异很大，而且与模型规模没有简单关系。更反常的是，无论检索结果中是否真的包含 Gold Skill，Agent 都会以近似概率尝试加载；面对本来就能独立解决的任务，它也没有明显减少外部 Skill 调用。
换句话说，当前 Agent 缺少两种判断：
- 相关性感知：候选 Skill 是否真的匹配当前任务
- 需要性感知：基础模型是否已经足以解决任务
如果这两项能力不足，提高召回率只会向 Agent 提供更多候选，增加上下文占用和错误执行机会。
即使正确 Skill 始终存在，硬负样本增加也会让完整 Skill 注入迅速退化
扩大检索 Top-K 时，渐进披露比一次性注入全部 Skill 内容更加稳定
#评测必须加入负样本与拒绝调用
一个只包含“每道题都有正确 Skill”的测试集，会奖励永远调用 Skill 的策略。真实系统必须包含三类样本：需要某个 Skill、候选中没有合适 Skill，以及完全不需要 Skill。
检索层可以测 Recall、NDCG 和相似 Skill 的排序；加载层应测正确采用率、错误采用率与拒绝调用；执行层再比较有无 Skill 的任务成功率、成本和错误类型。
还要加入相似但过时、依赖不满足、权限过大和方法不适用的困难负样本。这样才能判断系统找的是“看起来相关”的能力，还是“在当前约束下真正有用”的能力。
#这项研究仍是受控切片
SRA-Bench 的 Gold Skill 从现有基准结构中抽象而来，任务集中在可客观评分的推理、计算和代码问题。它还没有完整覆盖 GUI、多轮协作、长时间运行和不断变化的外部环境。
但它建立了一个重要的产品边界：大规模 Skill 系统不能把检索当作前置搜索框。Skill 发现、是否加载与实际执行是三个不同能力，任何一段失效，都可能让一个高质量 Skill 在生产中变成无用甚至有害的上下文。