两个技能主题相同仍可能要求冲突
论文研究一种主题相关性看不到的检索失败。两个技能可能服务同一大类目的，却依赖不同的资源、前置条件或输出接口。当查询指定了某项具体要求时，可能只有其中一个真正满足它，另一个在主题上仍然看似匹配。作者把这种情况称为同能力风险暴露检索。
论文给出的具体例子是一个要求返回“地图和距离字典”两项内容的查询。一个映射技能能算出两者，却只返回地图，它在主题上匹配，但违反了所要求的返回接口。换成一个只要求单项接口的查询，同一个技能就成了兼容选择。因此兼容性取决于查询，而不只取决于技能的能力标签。
这一框架之所以重要，是因为检索列表可能同时包含兼容技能和与查询不匹配的同类技能。基准的设计让这一对技能可以被检查：每个单元把一条查询要求、一个满足该要求的技能，以及一个违反该要求的同能力技能关联起来，并提供支持这一区分的证据。
召回率、HSR 与 CleanHit 回答不同问题
论文把单一相关性分数会混在一起的三类结果分开。Recall@K 问的是有用技能是否出现在前 K 个列表中。有害同类率（HSR@K）问的是被标记的冲突同类技能是否出现在同一列表中。CleanHit@K 要求两个条件同时成立：有用技能在列表中，且被标记的同类技能不在列表中。
这三个指标的分母和含义不同，论文将它们分开处理。Recall@3 高并不能说明冲突同类技能是否也排得很靠前。HSR@3 衡量的是被标注同类技能的暴露，而不是某个技能库中所有不兼容技能的普遍程度。CleanHit@3 是三者中最严格的，因为有用命中若伴随该同类技能出现就不计入。
这一区分是理解结果的关键。一个检索器可以在召回率上表现很强，却仍然把包含“错误但相似”选项的列表交给下游选择阶段。
890 个单元覆盖三种查询协议
SameCapRisk-Bench 包含 890 个单元和 1,314 个查询案例，覆盖五种机制和十二种冲突类型。这些单元按三种查询协议组织。单查询契约包含 466 个源自源任务的单元，每个单元有一条查询和一个与具体要求冲突的技能。源角色配对包含 387 个受控单元和 774 条查询，其中两个格式良好的技能在所要求的证据角色改变时互换有用与冲突的角色。输出接口配对包含 37 个作者构造的单元和 74 条查询，不同的可观察输出要求会反转同样两个技能中哪一个合适。
三种协议使用的候选池也不同。源角色查询在 774 个候选的池中排序，另外两种协议共用一个独立的 7,615 个候选的公开池。由于协议在任务来源、构造方式和候选池上不同，论文分别报告它们的分数，而不是合并成一个数字。
在预留 55 个单查询单元和 12 个接口配对用于开发后，剩下 823 个单元和 1,235 条查询用于留出主评估。标签证据随要求类型而异：论文统计了 160 个数学或算法证明、37 个接口契约检查、37 个工具/后端或数值结果对比、387 个静态源角色比较、241 个源契约或本地操作审查，以及 28 个代码修改案例。
源任务契约更频繁地暴露同类技能
最突出的结果是协议之间的差距。在源任务契约上，四个公开技能检索器的冲突同类技能 HSR@3 为 0.737–0.881。在受控源角色查询上，同一指标降到 0.099–0.12。源角色配对中技能保持不变，只有所要求的证据角色改变，从而反转哪个技能是有用的。
这一对比说明为什么单一汇总分数不足以刻画这种行为。在 1,235 条留出查询的固定混合上，四个检索器的 Recall@3 为 0.903–0.944，而 HSR@3 仍为 0.344–0.393。汇总数字位于两种协议极值之间，掩盖了暴露集中在源任务场景这一事实。
论文还报告了冲突同类技能排到什么位置。对这四个检索器而言，它在 24.8–29.2% 的源任务查询中排第一。因此检索到两个技能并不等于把它们排对，而排序错误足够频繁，会影响下一阶段收到的内容。
两个技能都被检索到时排序错误依然存在
另一项比较单独考察两个被标记技能的相对顺序。全部七种神经方法在同样的 543 条主查询上都检索到两者，其中包括 309 个单查询案例。在这些单查询案例上，有用技能排第一的比例为 0.521 到 0.696，因此即使最好的点估计也仍有约 30% 排反。
重排序并不能统一修正这一点。在该子集上，BGE 重排序的有用技能排第一比例低于 BGE 稠密排序，为 0.521 对 0.563。该子集覆盖 75.2% 的单查询案例，但只覆盖 24.3% 的源角色案例，因此它回答的是两个候选都可用时的排序问题，不能替代全划分的检索分数。
作者的解释是：找回有用技能、排对两个代表技能、返回不含被标记冲突的列表，是三个不同的问题。基准的设计是把它们分别报告，而不是让其中一个代替另一个。
更长的重排序输入改善第一名选择
论文还考察了重排序器实际收到什么。截断长技能可能删掉两个技能契约不同的段落，于是排序器可能根本看不到区分它们的文本。主 BGE 稠密设置使用 512 个文档 token，另一次 4,096 token 的运行用来衡量对输入长度的敏感性。
在相同的 BGE 前 20 个候选、模型权重、分词器、FP32 打分和并列规则下，把重排序器的输入预算从 512 提高到 4,096 token，使源任务中同类技能排第一的错误减少 8.27 个百分点。只有批大小从 16 改为 1 以适应内存。更长的输入没有改变全部 774 个源角色列表。
这一收益比初看要窄。在单查询契约上，CleanHit@3 变化为 +0.0073，其中 15 次提升、12 次下降，95% 分组重采样区间为 [−0.0164, 0.0303]。输出接口的变化为 −0.02，区间为 [−0.08, 0.04]。两个区间都包含零。因此更好的第一名选择可以与冲突同类技能是否仍留在列表中几乎不变同时存在，这也是论文在主比较中保留原始 512 token 设置的原因。
基准衡量的是暴露而非智能体行为
结论针对检索阶段：一个固定候选列表是否包含有用技能及其被标记的、与查询不兼容的同类技能。它们并不确定智能体会选择哪个技能，也不确定工具或技能执行时会发生什么。这一范围来自标签本身，标签依据的是局部查询—技能契约证据，而不是整技能执行测试。
泛化能力受对比构造方式的限制。一项仅看候选的诊断在 466 个单查询单元上仅凭技能措辞就达到 59.66% 的准确率，说明存在随冲突类型而异的残余标签线索。独立的人工标注者间一致性尚未测量。各协议在来源、候选池、文本长度和构造方式上也不同；源角色案例只覆盖十个声明分组，输出接口案例则是一小组派生配对。
一项跨模型族审计为标签提供了一定支持。DeepSeek-V4-Pro 和 GLM-5.3 在 128 条原始顺序查询中的 124 条上一致，κ = 0.94；在 96 个单元中的 88 个上，两个模型在两种顺序下都为每条查询选择了记录的有用技能。对剩余单元的审查发现了构造缺陷，五个单元在单独的数据修订中得到更正；检索表格使用更正后的文本。
优先看源任务契约而非汇总分数
对任何评估技能检索器的人来说，论文的优先事项很明确：把源任务契约与受控源角色查询分开报告。1,235 条留出查询上的汇总 HSR@3 为 0.344–0.393，既低估了最严重处的暴露（源任务契约上的 0.737–0.881），也高估了角色变化使区分变得容易处的暴露（0.099–0.12）。
第二个优先事项是把 CleanHit 而非 Recall 当作列表是否干净的衡量。对 BGE-M3 把 K 从 3 提高到 20，Recall 从 0.811 升到 0.937，但 HSR 从 0.329 升到 0.833。更长的列表能找回有用技能，却不一定让列表更干净，因此召回率看起来更好的检索器可能只是暴露了更多冲突同类技能。
重排序预算的结果提供了第三个更窄的杠杆。把输入从 512 扩展到 4,096 token 使源任务中同类技能排第一的错误减少 8.27 个百分点，但 CleanHit 的区间包含零。修正第一名选择与把同类技能从列表中移除是两个不同目标，论文的证据对前者的支持比后者更明确。
本文引用的文献
Right Family, Wrong Skill: Evaluating Risk Exposure in Agent Skill Retrieval
四个公开技能检索器的混合 Recall@3 为 0.903–0.944，但 HSR@3 为 0.344–0.393；在源任务契约上 HSR@3 为 0.737–0.881，而在受控源角色查询上为 0.099–0.12。