技能涨到几千个之后：LangChain 给 Deep Agents 的 Skills 打了三个补丁
结论
LangChain 重构了 Deep Agents 的 Skills 支持，针对"企业技能库已经涨到数千个技能"这一现实补上三项能力：工具可绑定到技能、仅在技能被读取时才加载；用户可用 /meeting-prep 这类显式请求固定技能，使其在首次模型调用前就载入；长线程可通过把 skills_metadata 设为 None 来重载新增或变更的技能。三条改动指向同一个工程问题：技能数量上来以后，上下文预算怎么花。
三个要点
- 延迟加载解决的是"描述也要占窗口"。 技能库规模一上去，光是列出所有技能的元数据就会吃掉大量上下文。把工具绑定到技能、读取时才挂载，等于把"目录"和"内容"分开计费。
- 显式固定解决的是"确定性"。 自动检索有概率漏掉关键技能。允许用户用斜杠命令固定，是把不确定性换成一条明确路径，对会议准备、发布检查这类流程化场景尤其必要。
- 线程内重载解决的是"长会话的陈旧"。 会话拉长之后技能定义可能已经更新，但上下文里还是旧版。
skills_metadata=None提供了一个不重开会话就能刷新定义的口子。 - 三条改动合起来是一次"从目录到索引"的转身。 技能少的时候，把所有技能列出来是最简单也最可靠的做法；数量上千之后，必须引入类似数据库索引的取舍机制——哪些常驻、哪些按需拉取、什么时候失效重载。这也是所有 Agent 框架迟早要交的一份作业。
对你意味着什么
如果你在自建智能体，这三条可以直接当设计清单来对照：技能元数据是否常驻上下文？有没有一个"这次必须用某个技能"的显式入口？长会话中技能变更如何生效？另外要注意，延迟加载和显式固定是两股相反的力——前者省 token，后者保确定，通常正确做法是给高频且关键的少数技能开固定通道，其余走延迟加载。可迁移的经验是：当工具或技能数量从几十涨到几千，架构上真正要解决的不是"更多能力"，而是"更少的默认加载"。