怎么理解skill文件中的元数据

回复 Erfan： 一句话理解：Skill 文件的元数据（通常是 SKILL.md 顶部的 name 和 description 等 YAML 头信息）本质上是给模型看的「轻量级路由索引」，用来实现刚才聊到的「渐进式披露」。 具体可以从这三个层面理解： 1. 为什么需要它（解决上下文爆炸与缓存问题） 一个 ca 或通用 Agent 往往挂着几十个 Skill，每个 SKILL.md 正文可能有几千字的操作规范、脚本路径和边界案例。如果把所有正文全塞进 System Prompt，不仅 token 瞬间爆炸、模型注意力被严重稀释，而且稍微改一个 Skill 就会击穿前缀缓存。所以必须拆成「常驻目录（元数据）」和「按需正文」两层。 2. 它是怎么工作的（两阶段加载机制） 第一阶段（感知与路由）：Agent 启动时，框架只解析各个 Skill 文件顶部的元数据（name + description），把这几行简短目录注入到 System Prompt 的可用列表或工具描述区里。 第二阶段（按需拉取）：模型在每一轮思考时扫一眼这个目录，判断当前任务命中了某个 Skill 的触发条件，就会主动调一个读取工具（比如 read/view SKILL.md），把完整正文动态加载进当前上下文，再去执行具体步骤。 3. 工程上怎么写好元数据（决定触发准不准） 既然元数据是模型判断是否加载该 Skill 的唯一依据，它的写法直接决定了路由准确率，而且直接关系到 Skill 的管理与生命周期： 第一，description 不是写给人看的宣传语，而是写给模型的「if-then 触发判据」。要明确写出“当用户要求做 X、遇到 Y 报错或处理 Z 格式文件时使用此 Skill”，并写清楚边界（什么情况下不要用它）。 第二，控制数量与防治冲突。Skill 不是越多越好，哪怕只放元数据，几十个近似的 description 堆在 System Prompt 里照样会让模型路由打架（不知道该调哪个，或者乱调）。平时要定期评估不同 Skill 元数据之间的职责重叠度，随着底座模型能力更新定期复测，把模型原生已经能做好、或者不再适用的旧 Skill 淘汰掉。