技能库变大以后：智能体为什么“找不到、分不清、放不下”？（深度版）

一、背景：从“渐进披露”到“技能库治理”

Anthropic 在 2025 年 10 月介绍 Agent Skills 时，把核心设计原则概括为渐进披露：启动时只把每个技能的名称和描述放进系统提示；智能体认为相关时，再读取完整的 SKILL.md；更细的附件按需打开 [1]。这让单个技能能承载的内容几乎不受上下文限制，也让“名称和描述”成为智能体决定是否使用技能的关键依据 [1]。

Anthropic 在文中也提醒，技能可能带来安全风险：恶意技能可能引入漏洞或诱导数据外泄，因此建议只从可信来源安装技能，并在使用前审查其中的代码依赖与外部网络连接 [1]。这意味着技能库的治理从一开始就不只是效率问题，也是安全与合规问题。

问题恰恰出在这里。渐进披露解决了“单个技能太大”的问题，却把“技能太多”的问题留给了模型：每多一个技能，系统提示里就多一段描述，模型就多一个需要排除的候选。10 月的研究把技能库的规模化问题拆成了四个环节：

1. 找：在大库里找到相关技能 [2][3][4]。
2. 分：在相似技能中挑出真正合适的那一个，并处理技能与记忆之间的冲突 [5][9]。
3. 留：判断技能是仍有用、已被模型内化，还是谁也帮不上，决定保留、退役还是删除 [6][7][8]。
4. 变：技能从哪里来，如何随代码库演化，能否“编译”成更稳定的程序 [10][11][12]。

二、找：路由崩塌与检索表示

2.1 隐式路由会“崩塌”

Lost in Implicit Routing（2026-10-13）[2] 做了一个干净的实验：保持 SkillsBench 的任务及其“标准技能”不变，只往库里添加无关技能。据论文数据，加入 1,000 个无关技能后，加载技能的召回率从 73.6% 降到 27.4%，一个技能都不加载的比例从 9.3% 升到 51.6%；而让模型从同一个库里做显式选择，召回率仍有 73.9% [2]。

作者排除了“模型加载了别的看似合理的技能”这一解释——这种情况太少，无法解释下降。关键证据有两条：只遮住无关技能的描述，加载行为就基本恢复；而在元数据完整的情况下，即使明确要求智能体先规划技能使用，召回率仍低于预选。作者据此认为存在两种干扰：描述带来的语义干扰，以及“选技能”与“做任务”相互竞争时的指令干扰 [2]。论文也评估了显式预选作为缓解手段的覆盖率与延迟权衡。

类比。一位新员工入职时拿到一本 10 页的操作手册，遇到问题会翻一翻；拿到一本 1,000 页、目录密密麻麻的手册，他很可能干脆凭经验硬做。不是手册里没有答案，而是“找答案”这件事本身挤占了做事的注意力。

2.2 按需浏览：SkillBrowser

SkillBrowser（2026-10-16）[3] 提出“选择性技能暴露”：既要在需要时提供相关的程序性内容，又要避免不必要的暴露干扰推理。渐进披露会把越来越多的元数据塞进上下文；静态检索只根据初始问题检索，可能与推理过程中才浮现的能力需求错位。SkillBrowser 用一个“元技能”管理流程：让智能体识别当前的能力需求、构造有针对性的查询、按需加载。据论文报告，在六个 SRA-Bench 子集和五个模型上，它的总体准确率优于静态检索与基于 LLM 的选择，并缓解了在“原本就能解出的实例”上的准确率下降；作者也坦承，收益依赖模型与任务，有用技能调用不足和额外延迟是主要局限 [3]。

2.3 检索表示的设计空间：SkillRep

如果要检索，就要回答“请求和技能怎么比”。用户请求和技能文档是为不同目的、用不同词语写的。SkillRep（2026-10-23）[4] 把检索器的表示设计拆成五个选择：编码器微调、查询侧扩展、文档侧扩展、背景投影、词汇通道，并把它们作为同一检索器的模块放在一起评估。据论文数据，使用 0.6B 编码器加 LLM 扩展，SkillRep 在 SRA-Bench 上的 MRR@10 比同规模最强检索器高 7.02 分（官方技能池）和 8.79 分（UniPool，作者从公开注册表构建的 111,247 个技能池），并在 SkillsBench 上表现更好 [4]。

更有意思的是它对“差距”的测量。作者用三个量刻画请求与技能之间的鸿沟：背景（不能区分技能的嵌入成分）、未说出的词汇（标准技能中请求没提到的内容）、稀释（把技能编码成单个向量时损失的信息）。结果显示，各模块的价值彼此依赖：例如微调会反转四个免训练模块的排序，让它们从互补变成重叠。缩小同一部分差距的模块相互竞争，缩小不同部分的模块相互补充 [4]。这对工程实践的提示是：不要把检索技巧简单叠加，先测清楚差距在哪一部分。

三、分：相似技能与来源冲突

3.1 算法拆解 ①：SKALOS 的“最弱证据”评分

直觉（示意）。库里有三个都叫“PDF 处理”的技能：一个能抽表格，一个能填表单，一个能合并文件。用户要“把表单数据填进 PDF 并合并成一份”。按文本相似度排序，三个都很像；真正需要的是同时具备“填表单”和“合并”两种能力的那个实现。SKALOS（2026-10-26）[5] 用能力图来比较技能，而不是只比较描述文本。

类比。招聘时要求“会 Python 且会 SQL”。一位候选人 Python 精通、SQL 只是听说过；另一位两项都熟练。按“平均分”可能前者更高，按“短板”看后者才符合要求。SKALOS 用的就是“看短板”的评分方式。

步骤 [5]：

1. 建图。为每个技能构建多层次能力图，对齐不同技能中等价的表述，同时保留技能特有的能力证据。
2. 抽需求。从查询中抽取所需能力列表。
3. 最弱证据评分。采用 Max–Min 半环：a ⊕ b = max(a, b)，a ⊗ b = min(a, b)。一条支持路径的得分取其最弱节点或关系（⊗ = min）；多条备选路径取最强者（⊕ = max）。同时检查所有需求是否在同一个实现内被共同支持。
4. 校准。用排序反馈调整不可靠的抽取证据，降低抽取错误的影响。

def witness_score(skill, requirements):
per_req = []
for r in requirements:
branches = skill.graph.paths_supporting(r)            # 同一实现内的支持路径
per_req.append(max(min(edge.conf  for  edge  in  b)  for  b  in  branches)  if
branches else 0)
return min(per_req)                                      # 所有需求都要满足：取最弱
rerank(candidates, key=witness_score)

结果（据论文数据）。在 SkillRet 上，SKALOS 的 NDCG@10 比匹配的纯文本重排器高 2.68 个百分点；用见证路径引导技能选择，使 ALFWorld 任务成功率从 22% 提高到 29% [5]。

何时失效。能力图依赖从技能文档中抽取能力元素。文档写得含糊或格式差异很大时，抽取误差会直接进入 min 运算——一个被低估的环节就能拉低整个技能的分数。校准步骤缓解但不能消除这一点。

3.2 技能与记忆打架时，谁说了算

注入上下文的不只有技能。生产环境中的智能体往往同时运行情景记忆和程序性技能，两者被放进同一段上下文，却没有规定优先级。Navigating Epistemic Parity（2026-10-23）[9] 把这种状态称为“认知平价”，构造了 52 个场景（事实、格式、流程、权限四类冲突），在三个开源权重模型上运行 1,383 次。据论文数据：没有哪个来源总是胜出，结果取决于冲突类型、模型和注入顺序；把技能块移到离任务更近的位置，在事实和流程冲突的六个单元中都提高了技能胜率，但在格式冲突上反转，说明裁决跟随的是词元位置而不是来源语义；明确写上“技能绝对优先”，在两个较强模型上提高了遵从，但仍有 3%–10% 不遵从，并让最小模型在事实和流程冲突上朝错误方向移动。尤其值得警惕的是：在智能体通过工具调用行动的运行中，98.8% 没有附带任何文字，89% 的运行完全没有披露存在矛盾——静默裁决是默认行为 [9]。

四、留：内化、退役与生命周期

4.1 算法拆解 ②：内化判定与有效性闸门

问题。公共技能库可能有约十万条技能，服务许多模型。模型变强后，有些技能它已经“学会了”，继续加载只是浪费上下文。现有的退役规则比较“有技能”和“无技能”两次运行的增益，增益接近零就退役。Beyond Gain（2026-10-23）[6] 指出这个规则有一个盲区：增益接近零有两种情况——模型已经内化了技能（不需要它），或者模型和技能都做不到（论文称为“未覆盖”）。前者该退役，后者不该。

类比。一门补习课，学生上不上成绩都一样。可能是学生早就会了，也可能是这门课本身教不会。只看“上课前后的差距”，两种情况无法区分；只有知道学生“不上课时的水平”，才能判断。

步骤（据论文定义 [6]）：

1. 只看能力项。对技能合成的任务，挑出“必须依赖技能中信息才能通过”的评分项 C（而非“文件存在、代码能编译”这类通用项）。
2. 算两个分数。不给技能运行 k 次，得到无辅助能力分 U；给技能运行，得到辅助能力分 A。两者都是能力项通过率的平均。
3. 有效性闸门。一个高 U 可能只说明任务太简单。因此只有当至少一个“见证模型”在同样的能力项上从技能获益时，才接受该任务：max_w (A_w − U_w) > γ，γ = 0.1。
4. 水平规则。通过闸门后，U ≥ τ = 0.8 才判定为内化、可以退役。

def retire(skill, target, witnesses, task):
C = capability_items(task, skill)
if max(A(w, C) - U(w, C) for w in witnesses) <= 0.1:
return "无法判断"            # 没有任何模型从技能获益：高分可能只因任务太简单
return "退役" if U(target, C) >= 0.8 else "保留"

小例子（示意）。技能 S 教“某开源库的配置迁移步骤”。目标模型不用 S 时能力项通过率 U = 0.85，看起来已经会了；但如果三个见证模型用不用 S 分数都一样，就说明任务可能根本不需要 S 中的信息，闸门不放行，不能据此退役。反之，若某个较弱的见证模型用了 S 之后从 0.3 升到 0.7，闸门放行，目标模型的 0.85 就是真正的内化证据。

结果（据论文数据）。闸门放行了 1,165 个已评分任务中的 844 个（72.4%），但在 U ≥ 0.8 的任务中只放行 52.6%，即接近一半“看似已内化”的高分来自没有任何模型能从技能中获益的任务。在四个模型下，按每个技能一个任务应用已发表的增益规则，会删除 58%–65% 的“未覆盖”技能，而水平规则删除 0%。在 SkillsBench 上，31 次退役中有 28 次依据的是没有任何一次运行完全通过的探针，而按无辅助分数退役没有可检测到的奖励损失。无辅助判定在不同任务间的复现一致性高于增益规则（Cohen's kappa 0.42 对 0.23），但在不同模型间不同，所以技能库必须按模型分别读取判定结果。作者发布了 1,251 个技能及其在四个模型下的任务与评分项 [6]。

何时失效。判定依赖评分项的质量；论文中目标模型 Qwen3.6-27B 同时担任裁判，作者在局限中讨论了裁判依赖问题 [6]。见证模型的选择也会影响闸门：作者发现两个见证模型能恢复三个见证模型 85%–90% 的信息，纳入一个较弱模型能让闸门在模型变强后仍保持信息量 [6]。

4.2 算法拆解 ③：TrackRL——在训练中做随机对照实验

直觉。Beyond Gain 解决的是“推理时的技能库怎么退役”；TrackRL（2026-10-18）[7] 解决的是“强化学习训练过程中的技能库怎么管理”。训练中，有的技能随策略进步变得多余，有的持续有用，有的变得有害。难点在于：同时被检索出来的技能会“搭便车”，任务难度会混淆效果，而且缺少针对单个技能的反事实证据。

类比。想知道一种肥料有没有用，更可靠的办法是在同一块地里随机划出施肥区和不施肥区。TrackRL 把 GRPO 本来就要做的“同一任务采样多条轨迹”，变成了一次免费的随机对照试验。

步骤 [7]：

1. 随机注入。在每个 GRPO 组内，对每个选中的技能独立地以 Bernoulli(p) 决定是否注入，从而对同一任务形成“有技能/无技能”两组。
2. 组内对比，跨组累积。技能效用 u_s 定义为注入相对于不注入带来的成功率变化；用可靠性加权在各组之间累积证据；同时跟踪“掌握度”m_s，反映模型内化该能力的程度。
3. 证据闸门式状态机。新技能只有与现有技能和已删除的有害技能都不相似时才被接纳；接纳后进入受保护的孵化期，证据不足时不允许退出；证据充足后：

• 删除：效用的置信上界都低于零（u_s + λ·SE < 0），永久排除；
• 退役：效用 ≤ 0 且掌握度的置信下界高于绝对阈值和同类任务的基线；
• 保留：其余技能作为长期“脚手架”留在库中；
• 软容量上限控制库的增长。若遗忘使退役技能重新变得必要，后续失败会触发它重新生成和接纳 [7]。

for group in grpo_groups:
for s in selected_skills(group.task):
z[s, e] ~ Bernoulli(p)  for e in group.episodes       # 独立随机注入
rollout(group, inject=z)
for  s:  update_utility(s,  mean(R  |  z=1)  -  mean(R  |  z=0),
weight=reliability(group))
lifecycle_step(library)   # 孵化 → 保留 / 退役 / 删除，受软容量约束

结果。论文报告 TrackRL 在“带库评估”和“无技能评估”两种设置下都优于近期的技能增强强化学习基线，并分析了技能价值在策略学习过程中的变化 [7]。

何时失效。随机注入意味着部分轨迹故意不给有用技能，会牺牲一部分训练样本的成功率；当组内样本数很少时，单组对比噪声大，需要更多组才能积累足够证据。

4.3 选择性注入：SkillScaffold

SkillScaffold（2026-10-13）[8] 从同一问题的另一面切入：基于采样估计技能效用，在样本有限时既贵又不稳定。它复用经结果验证的训练轨迹生成候选技能，通过“考虑结果的似然比较”估计效用，无需为每个候选单独采样；当没有候选被估计为有帮助时，就保持无技能执行。论文报告在 ALFWorld、WebShop、ScienceWorld 和 τ²-Bench 上优于强基线，并强调“基于效用的选择与弃权”的重要性 [8]。

五、变：技能从哪里来，又变成什么

• 从代码轨迹中分层提炼。HSE（2026-10-26）[11] 先从单条轨迹中提取任务级证据，再在同一仓库内聚合为仓库级候选，最后把跨仓库一致的模式整合成可迁移技能，由外部的“写作者—评估者”循环驱动，编程模型本身保持冻结。据论文报告，仅从 SWE-Gym 演化出的 10 个技能，在 SWE-bench Verified 和 DeepSWE 上、跨多个模型与 Harness 的所有评估设置中都提升了编程表现 [11]。
• 随拉取请求持续演化。Skill Dreaming（2026-10-26）[12] 从已验证的拉取请求中提取可执行知识，构建仓库专属技能库，并随新的拉取请求信息持续更新；技能不只指导实现功能，也指导维护测试、文档、兼容性和仓库约定 [12]。
• 把技能“编译”成程序。FlashScript（2026-10-24）[10] 认为，对反复出现的工作流，技能仍会让智能体每次重跑完整过程、结果不一致。它把一次成功运行编译成神经—符号程序：动作和数据变换变成代码，实例相关的值变成参数，需要模型判断的地方变成 LLM 调用。据论文数据，在 120 个 WorkBench 分析任务上（Claude Haiku 4.5），这些程序每次运行都正确且工具调用完全一致，输入词元约为技能引导智能体的 1/70，运行时间约为三分之一；在组合版任务中，技能引导智能体的准确率降到 23%，程序仍全部正确；程序泛化到同模板的全部 108 个未见实例 [10]。编译不消除不确定性，而是把它局部化，让确定性程序和神经调用可以分别审查和测试 [10]。

六、横向对比

注：各研究的任务、模型与评价口径不同，数值不可直接横比。

实践：一张技能库治理表

把上面的研究落到工程上，我们建议为每个技能维护一行记录，至少包括以下字段：

这张表的价值，在于把“技能好不好用”从个人印象变成可查询、可复核的证据。表格本身并不复杂，难的是坚持在每次模型升级、每次新增技能时更新它。对于已经积累了上百个技能的团队，可以先从使用频率靠前的二十个技能开始。

七、我们的观点

第一，技能库的瓶颈正在从“写技能”转向“管技能”。写一个技能的成本越来越低，甚至可以由智能体自动生成 [11][12]；但库越大，路由越容易崩塌 [2]，冲突越容易被静默裁决 [9]。技能库需要像代码库一样有目录、有测试、有退役流程。

第二，不要让模型在做事的同时挑技能。路由崩塌的根源之一是“选技能”与“做任务”相互竞争 [2]。在技能数量较多的场景，显式预选或按需浏览 [3] 往往比把所有描述塞进系统提示更可靠。

第三，退役要看“不用时的水平”，而不只是“用了以后的增益”。增益为零可能是已经学会，也可能是谁都做不到 [6]。我们建议企业在模型升级后，对技能做一次按模型分别的“无辅助能力测试”，并用一个较弱模型做见证。

第四，高频稳定的工作流，应当从技能走向程序。FlashScript 的结果说明，一旦流程固定，把它编译成可测试的程序，在一致性和成本上都有明显优势 [10]。技能适合“需要判断”的部分，程序适合“必须一致”的部分。这与弘犀智能规则引擎的思路一致：把确定的业务逻辑交给规则，把需要判断的部分留给模型。

八、未来展望

6–12 个月：

• 技能平台会普遍提供显式预选或检索层，系统提示中只放少量高置信候选，而不是全部描述 [2][3] [4]。
• 技能元数据会增加“适用模型”“内化状态”“最后验证日期”等字段，退役判定按模型分别存储 [6]。
• 记忆与技能的优先级会被写进协议，并要求智能体在发现冲突时显式披露 [9]。

1–3 年：

• 技能库会出现“持续集成”：每个技能附带任务与评分项，模型升级时自动重测，结果驱动保留、退役或删除 [6][7]。
• “技能 → 程序”的编译会成为常规能力，智能体在识别到重复工作流后主动提出编译建议 [10]。
• 仓库级技能会和代码一起演化，拉取请求既是技能的来源，也是技能的检验 [12]。

九、对金融风控与企业落地的启示

1. 控制同时暴露的技能数量。风控、合规、运营等团队各自沉淀技能后，总数会快速增长；应按业务域预选，而不是全部挂到一个智能体上 [2]。
2. 相似技能要按“能力短板”区分。例如多个“报表解析”技能，应标注各自支持的报表类型与字段，用能力匹配而不是描述相似度选择 [5]。
3. 为记忆与技能规定优先级并要求披露。当历史记忆中的口径与当前技能规定的口径冲突时，智能体必须说明采用了哪一个以及为什么 [9]。
4. 模型升级后做一次技能体检。用无辅助能力测试判断哪些技能可以退役，并保留“见证模型”证据，避免误删 [6]。
5. 把高频固定流程编译成规则或程序。每日对账、固定格式报告等流程，编译成可测试的程序后，一致性和成本更可控 [10]；需要判断的部分再交给模型。

十、结语

技能把经验变成了可复用的资产，而资产一多，就需要治理。10 月的研究给出了治理的四个抓手：用检索和预选解决“找不到”，用能力证据解决“分不清”，用无辅助测试和随机对照解决“该不该留”，用编译和持续演化解决“怎么变得更稳”。技能库的规模越大，这些抓手越重要。

想了解弘犀智能在规则引擎与智能决策系统方面的实践，欢迎点击文末「阅读原文」访问 www.hxallai.com。

参考文献

1. [1]Anthropic. Equipping agents for the real world with Agent Skills. Anthropic Engineering Blog, 2025-10-16.（背景文献）https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
2. [2]Jinlin Liu, Wei Chen, Xiaojin Zhang. Lost in Implicit Routing: How LLM Agents Fail to Load Relevant Skills at Scale. arXiv, 2026-10-13. https://arxiv.org/abs/2610.18522
3. [3]Jin Ye, Yifan Jiang, Lan-zhe Guo. SkillBrowser: Selective Skill Exposure for Scalable Skill-Using Agents. arXiv, 2026-10-16. https://arxiv.org/abs/2610.23554
4. [4]Tianyi Sun, Pengfei Yao, Yanze Wang, Hongda Chen et al. SkillRep: Characterizing and Understanding the Representation Design Space of Agent Skill Retrieval. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32336
5. [5]Wenhan Xiao, Ziwei Zhang, Xingcheng Fu, Chuanyue Yu et al. SKALOS: Learning to Distinguish Similar Skills with Capability Graphs. arXiv, 2026-10-26. https://arxiv.org/abs/2610.34728
6. [6]Yanze Wang, Pengfei Yao, Tianyi Sun, Hongda Chen et al. Beyond Gain: Measuring Skill Internalization for Agent Skill Retirement. arXiv, 2026-10-23. https://arxiv.org/abs/2610.32322
7. [7]Xi Zhu, Yuanlin Duan, Changyi Yang, Kai Mei et al. Trackable Skill Library Lifecycle Management for Agentic Reinforcement Learning. arXiv, 2026-10-18. https://arxiv.org/abs/2610.25126
8. [8]Wenlin Zhong, Hao Wang, Kun Yuan, Fan Yang et al. SkillScaffold: Scaffolding Agentic Reinforcement Learning with Policy-Adaptive Skill Credit Assignment and Selective Injection. arXiv, 2026-10-13. https://arxiv.org/abs/2610.18807
9. [9]Prakhar Pandey. Navigating Epistemic Parity in LLM Agents: A Benchmark for Cross-Source Conflict Resolution Between Memory and Procedural Skills. arXiv, 2026-10-23. https://arxiv.org/abs/2610.33128
10. [10]Sadra Sabouri, Hosein Hasanbeig, Adam Sage, Shreya Sinha et al. FlashScript: Compiling Recurring Agent Workflows into Reusable Neuro-Symbolic Programs. arXiv, 2026-10-24. https://arxiv.org/abs/2610.33876
11. [11]Jun Gao, Yun Peng, Changhai Zhou, Yuhan Zhu et al. Hierarchical Skill Evolution for Coding Agent. arXiv, 2026-10-26. https://arxiv.org/abs/2610.35616
12. [12]Xinyuan Song, Hasibul Haque, Jay Somasundaram, Ryan Turner et al. Skill Dreaming: Evolving Repository Skills through Pull Request Streams. arXiv, 2026-10-26. https://arxiv.org/abs/2610.36188