~/yomxxx/posts/2026-10-15-lost-in-implicit-routing-skill-collapse-paper.mdx
Paper

$ cat Lost in Implicit Routing 速读:技能库变大后,代理为什么找不到该用的技能

-- 5 min read ·

💡 论文信息:Lost in Implicit Routing: How LLM Agents Fail to Load Relevant Skills at Scale,arXiv 2610.18522,2026-10-13 提交,作者 Jinlin Liu、Wei Chen、Xiaojin Zhang,代码开源在 github.com/jinlinll/lost-in-implicit-routing,正文 22 页。

技能(skill)是这一年代理工程的主流抽象:把任务特定的指令、脚本与工具打包成可复用单元,代理按需加载。Claude 的 Skills、各家 CLI 的扩展机制、MCP 生态的工具目录,走的都是这条路。它有一个默认假设:代理能从不断变大的技能库里找到该用的那一个。这篇论文把假设放在实验台上压了一遍,结果它碎了。

一、实验设计:三行说清楚

论文的实验设计非常克制,也因此非常有说服力。

  1. 固定住 SkillsBench 的任务与其对应的正确技能(golden skills),一个都不改。
  2. 往库里逐步加入与任务无关的技能——从几条到 1000 条。
  3. 观察代理实际加载了什么。

这个设计的妙处在于唯一变量是库的规模。任务没变、正确技能没变、描述没变,性能却崩了。崩掉的部分只能归因于「选择环境」本身,而不是任务变难或技能失效。

二、结果:一条陡峭的下坠曲线

三组核心数字:

  • 加载召回率崩塌:无关技能达到 1000 条时,召回率从 73.6% 跌到 27.4%。注意这是「正确技能仍在库里、随时可加载」的条件下测出的——不是找不到,是不找。
  • 零加载率飙升:一条技能都不加载的运行占比从 9.3% 升到 51.6%。过半情况下代理裸奔执行任务,用通用能力硬顶本该由技能覆盖的工作。
  • 显式选择几乎免疫:同一个库、同样 1000 条无关技能,改成显式选择机制后召回率仍有 73.9%。

还有一个重要的排除项:加载了错误的技能(包括与正确技能相似的替代品)的比例极低,不足以解释下降。也就是说,坍塌的形态不是「选错」,而是「不选」。这直接指向机制层面的问题。

三、机制:两种干扰,两把刀

论文进一步做了归因实验,定位出两类独立机制。

语义干扰:技能的描述文本在语义空间里互相干扰。证据是决定性的——只屏蔽无关技能的描述、保留名称与结构,加载率就大幅恢复。描述越「能干」、越与目标任务域沾边,干扰越强。这对技能市场是个坏消息:为了让代理选中,人人都在把描述写得功能丰富、覆盖面广,而正是这些泛化描述制造了语义噪声。描述的军备竞赛直接加速路由坍塌。

指令干扰:隐式路由把「选技能」这个决策塞进了任务执行的主循环。当上下文里挤着 1000 条候选描述时,模型要一边推进任务、一边扫描候选、一边决定加载与否,多个目标在注意力上竞争,选择决策被牺牲。显式预选把选择拆成独立前置步骤,没有竞争,所以抗干扰。

论文还测了一个直觉上合理的缓解:明确要求代理「先规划要用的技能再动手」。结果仍不如预选——把计划写进提示词不等于改变架构,只要选择和执行还在同一条循环里,干扰就在。

四、预选方案的实测权衡

显式预选不是免费的。论文对它做了务实的评估,两个代价都量化了:

  • 覆盖代价:预选发生在看到任务细节之前或之中,如果任务在执行中途才显露出对另一个技能的需求,预选批次的覆盖会不足。论文给了覆盖率的实测数字。
  • 延迟代价:多一次独立的模型调用,端到端延迟增加。

这两个代价在技能库小于几十条时通常不值得付——小库上隐式路由本来就工作得不错。预选的收益是规模的函数:库越大、干扰越多,预选的召回优势越大。它应该是一个随库规模自动启用的策略,而不是一个默认配置。

五、工程清单:今天就该做的四件事

把论文结论翻译成团队清单:

  1. 给技能库设预算。超过 50 条就该按任务域拆分或引入检索层。论文的曲线告诉我们,坍塌不是阈值跳变而是渐进滑坡,等你感觉到「代理怎么不用那个技能」时,召回率可能已经掉了一半。
  2. 把加载率变成监控指标。端到端评测时记录「该加载而未加载」的比例,它是技能体系的健康度心跳。零加载率尤其值得盯——它是最隐蔽的失效形态,任务看起来还能跑,只是质量悄悄退化。
  3. 审一遍描述文本。找出那些「什么都沾一点」的万能描述,改成可区分的、具体的表述。这项零成本工作直接作用在最大的噪声源上。
  4. 在管线里预留预选位。当库规模触发预算线,把「选技能」做成显式的独立调用。OpenCode 2.0 的 Code Mode 把工具转成可编程函数、让模型写脚本组合调用,本质上也是在压缩隐式路由的决策面——两边的证据在互相印证。

六、结语

这篇论文的价值在于把一个大家隐约感觉到的现象(「技能多了代理就不用了」)变成了可复现的测量与可操作的机制解释。它没有提出新算法,但它给出的三个数字——27.4%、51.6%、73.9%——应该印在每一个做技能市场的团队的白板上。

代理技能生态正在复制当年浏览器扩展与移动 App 市场的爆发路径,而这项研究提前揭示了那条路上的一块断桥:选择机制的扩展性独立于任务能力的扩展性。模型再强,也强不过一个塞满噪声描述的隐性决策环境。技能协议的下一版标准里,也许应该长出一个检索层。

Frequently asked questions

「隐式路由」和「显式选择」的差别是什么?
隐式路由指代理自己浏览技能库的元数据(名称与描述),在执行任务的过程中决定加载哪个技能,加载动作与其他执行步骤混在一起。显式选择则是把「从库里挑技能」拆成独立的前置步骤,先选定再用,技能选择不与任务执行竞争注意力。实验显示两者在干扰下表现差距悬殊。
路由坍塌的量化结果有多严重?
固定任务与正确技能不变,无关技能从少量加到 1000 条时:加载召回率从 73.6% 跌到 27.4%,也就是三分之二以上的任务连正确技能都没加载;零加载率从 9.3% 升到 51.6%,超过一半的运行一条技能都不加载。而同样的技能库用显式选择仍有 73.9% 召回,几乎不受规模影响。
坍塌的机制是什么?
论文定位出两类干扰。一是语义干扰:无关技能的描述与正确技能在语义空间里互相干扰,屏蔽掉无关技能的描述(只留名称)就能大幅恢复加载率,证明描述文本本身是主要噪声源。二是指令干扰:当代理需要在执行中同时完成「选技能」和「做任务」两个目标时,选择决策被任务执行挤掉,这解释了显式预选的优势。
对维护技能库的团队有什么实操建议?
四条:控制技能库规模,超过几十条就要考虑按任务域分组隔离;投资描述质量,无关技能的描述要写得与正确技能可区分,模糊的「万能描述」是坍塌加速器;在管线里加显式预选步骤,先让模型从库里选技能再进入执行,代价是一次额外调用;建立加载率监控,把「该加载而未加载」当作一等公民指标跟踪。
这项研究对 MCP 与技能生态意味着什么?
当前生态正朝着「人人发布技能、市场聚合分发」的方向狂奔,技能数量破千是可预期的。这项研究用数据说明按需隐式加载不是可扩展的设计,技能协议需要内建检索或预选层,而不是把选择责任完全交给执行中的模型。技能市场的排序与元数据规范会因此变得有工程意义。
// next.txt ›

Some outbound links in this post are affiliate links — see disclosure.