Skills 如何实现渐进式披露？
- 启动: Agent 只看到一份薄薄的目录——每个 skill 的
name 与 description，合计数百 token;
- 展开: 当当前上下文真的需要某种能力时，模型才去读取对应的 sub-skill，并顺着其中的引用再往下一层，读取具体的脚本或子文档;
- 定位: 这是渐进式披露模式在工具侧的变体，也是“工具太多怎么办”的第三层答案——干脆不把工具当成需要注册、检索、注入的正式定义，而当成一份可以随手翻阅的参考资料;
为什么说它更接近人使用参考资料？
- 类比: 没有人会把一本工具书或整个维基百科从第一页读到最后一页，而是顺着索引和目录，根据当下需要逐个查阅词条;
- 对应: 工具的详细定义不必全部常驻上下文，用到哪条查哪条;
与专用工具的按需加载相比，成本差在哪？
- 前提: MCP 协议本身并不规定工具定义是全量还是按需进入模型上下文，但早期或简单的宿主实现通常会把完整 schema 一次性摆在模型面前;
- 专用工具的额外基础设施: 要达到同样的渐进式披露，必须在工具之外另建一层——关键词检索或嵌入索引、检索元工具、命名空间与允许列表、
tool_search 与 tool_reference 这类 API 原语;
- Skills 的优势: 把渐进式披露内建为默认形态，实现成本更低，因此是一种更省心的工具发现思路;
- 参照: 专用工具侧的这两套机制见 层次化组织与按需加载与主动工具发现与动态加载;
三层方案的关系是什么？
- 第一层（按需加载索引）: 工具定义事先备好，只是不再全量塞进上下文;
- 第二层（主动工具发现）: Agent 在执行中声明能力缺口，由系统动态匹配并注入;
- 第三层（Skills）: 把能力当成可翻阅的文档，目录常驻、正文按需读取;
- 递进关系: 一层比一层更“按需”，对基础设施的依赖也更少;