Claude 发布了 Skills 规则、Codex 也开始支持 Skills，它正在成为 AI Agent 标配能力。将所有工具一股脑扔给 LLM 让其自行选择（即“Tool search”）是一条死胡同；未来的方向是将能力封装为独立、可靠的“Skills”，并通过更精准的分类机制来调用。
核心论点：为什么“工具搜索”已死？
在早期的 Agent 开发中，开发者习惯将几十甚至上百个 Function Calling 定义全部塞进大模型的 Prompt 上下文中，指望模型能像查字典一样，自己“搜索”并挑选出正确的工具来使用。
作者认为这种模式有三大致命伤：
· 不可靠： 当工具数量增加，模型的注意力会被分散，经常选错工具或产生幻觉。
· 扩展性差： 上下文窗口是有限且昂贵的。试图在一个 Prompt 里塞入所有工具的定义，不仅浪费 Token，还会降低模型的推理质量。
· 缺乏“用法”知识： 仅仅给模型一个工具的 API 定义（例如 get_weather(city)）是不够的。模型往往需要知道“何时用”、“怎么用”以及“遇到错误怎么办”等隐性知识，而“工具搜索”模式忽略了这些上下文。
解决方案：技能正在成为新的标准
“技能”不仅仅是工具的重命名，它代表了一种更模块化、更具指导性的架构思想。
什么是“技能”？
· 封装了上下文： 一个“技能”不仅包含工具本身，还包含了如何使用该工具的最佳实践、特定的 Prompt 指令、甚至是一些预置的知识库。
· 按需加载： 技能不是一直挂在上下文里的。系统只在需要的时候，才把特定的技能“加载”给模型。
它是如何工作的？（分类 vs. 搜索）
作者提倡使用 分类器 或路由层，而不是让大模型在长列表中盲目搜索。
- 意图识别： 当用户发出请求时，先通过一个轻量级模型或分类器判断意图。
- 加载技能： 根据分类结果，系统只调取对应的“检索技能包”或“编程技能包”进入上下文。
- 精准执行： 此时，主模型看到的只有与当前任务高度相关的几个工具和详细的指导说明，因此成功率极高。
总结：对 AI 开发者的启示
Agent 开发正在从“提示词工程”走向“软件工程”。
· 旧模式： 把所有希望寄托在 LLM 的泛化能力上，祈祷它能从混乱中找到对的工具。
· 新模式（技能）： 像写代码一样，将复杂任务解耦。不仅给 AI 锤子，还给它附上一本「锤子使用指南」，并只在需要敲钉子的时候才把它们递过去。
这种转变使得 AI Agent 从“偶尔能用的玩具”变成了“稳定可靠的生产力工具”。对于企业级应用来说，定义清晰、边界明确的“技能”库，将是比单纯堆砌模型参数更重要的资产。