Skill 的渐进式披露是什么？

核心回答

Skill的渐进式披露是先让Agent发现“有哪些能力”，任务匹配后再读“怎么做”，执行中才加载所需细节。它把能力发现与详细内容分开，减少无关说明长期占据上下文，也让同一个Agent可以管理更多专业方法。

常见组织是名称与描述、SKILL.md正文、按需引用的资料和脚本三层。这里的“层”描述信息加载时机，不是要求技能必须拆成三个文件，也不是让用户一步步确认。

各层分别加载什么

第一层是轻量元数据。宿主发现技能目录后，把名称和准确的触发描述提供给模型，帮助判断适用任务。描述应说清场景与边界；“通用专家，什么都能做”会让路由失去区分度。

第二层是完整操作说明。命中后读取SKILL.md正文，获得方法、前提、步骤、异常处理和产物要求。触发技能通常意味着加载指令，不一定是直接调用一个名为Skill的函数，更不等于所有宿主都使用同一种JSON接口。

第三层是执行所需资源。正文引用专题资料、模板、示例和脚本，Agent只读取当前分支需要的文件。脚本可以通过宿主提供的执行能力运行，模型主要消费结果；这并不意味着执行没有资源成本，也不意味着加载技能就自动获得更多权限。

一个例子

假设有一个CSV分析Skill。目录描述只说“分析CSV的字段质量、统计分布和异常记录”；读取正文后知道如何检查数据和组织报告；任务需要时间序列分析时才读取相应说明，必要时运行已有统计脚本。

只做字段检查就不必把时间序列、绘图、导出等全部材料注入本轮。脚本结果返回样本与统计摘要，原始大文件保留可回查引用，避免大量数据反复进入上下文。

工具或技能很多时怎么办

元数据本身也有成本。数量增加后，可先按身份、可用性和任务范围筛选，再进行关键词或语义召回，将少量候选交给模型判断。候选数量应由召回质量与预算评估，不能认为固定Top-20或某个Token数普遍最优。

错误路由可能让后续永远看不到正确技能，因此要允许扩大候选、拒绝不匹配或进行必要澄清。技能版本与资源引用要一起维护，避免入口描述更新了，正文仍指向旧脚本。

它不保证什么

渐进披露减少上下文噪声，但不能保证模型一定选对、一定执行或一定成功。仍需验证触发与不触发样例、资源加载、关键步骤和最终产物。技术亮点是把发现、理解和执行资源分开，让能力扩展与上下文预算能够同时管理。

对应教程

参考资料