为什么值得读
技能库/工具库越堆越多是 Agent 落地的常态，而大多数团队的默认反应是「再训一个 router」或「让人工重写描述」，前者会遗忘、后者不可扩展。这篇把问题正确定义成类增量持续学习，并给出一个不需要标注、不改 router 的干预点：只动来者的元数据。成本极低，值得先试。
问题：progressive disclosure 把压力全压在元数据上
LLM Agent 的能力以技能（skill）形式扩展，每个技能有名称、描述与正文。渐进披露机制下，router 只看名称与描述来选技能，正文只在选中后才加载。
技能库是持续增长的：用户和 Agent 自己都会往里加。于是出现一种失效——一个相似的新技能挤掉了先前的技能，导致原本正确的路由被破坏，而此时旧技能与 router 都没有改动。公开技能更严重，因为它们的描述可能与正文并不一致。
为什么现成办法不够
论文把它形式化为「终身技能路由」，属于类增量持续学习：既要让早先的技能保持可选，又不能压制新技能。
两条常见路线都不够用：持续重训 router 有灾难性遗忘风险；改写类方法要么忽略相似技能之间的区分，要么需要逐技能的反馈标注。
方法：三句话改写来者的元数据
Skill++ 只改写每个新进技能的名称与描述，不训练 router，也不需要标注数据。新描述要说清三件事：正文实际支持什么、它与最近的前任技能差在哪、它明确排除哪些相关工作。
这个设计的巧妙处在于把「区分度」写进被检索的文本本身：router 不需要变聪明，候选之间的边界变得更清晰了。
结果与边界
技能库在十轮会话中增长到 731 个技能，Skill++ 让 76.3% 的查询选中了全部所需技能，原始元数据下是 36.4%。三个基准、五个 LLM router 上均优于所有对比方法，增益还能迁移到 Codex CLI 的 agent harness。
边界同样明确：76.3% 意味着仍有约四分之一的查询没有选全技能；「最近的前任」如何判定（相似度阈值、是否用嵌入检索）摘要未展开；方法只改元数据，无法解决正文本身与描述不符的问题——那属于技能质量问题，不是路由问题。
本站仅据 arXiv 摘要页（E1）整理，未复现。36.4%→76.3% 为作者自述，基准构成、查询分布与「选全技能」的判定方式细节在摘要中未给出；相似技能检索的具体实现与阈值未披露，复现依赖作者后续放出；摘要页检索未发现代码仓库；结论基于十个会话的模拟增长，真实长期技能库的分布可能不同。
本文基于论文原文摘要与方法章节整理，观点由编辑撰写；如与原文有出入，以 arXiv 原文为准。 内容为信息整理与技术评论，不构成投资或决策建议。 发现错误请通过站内纠错页提交（记录可查），修订记录只增不删。