🧑💻 面试官：Agent 有几十个 Skill，怎么找到这次该用的？
🙋♂️ 我：可以把每个 Skill 的名称和描述交给模型，让它按任务选择，再加载具体内容。
🧑💻 面试官：一个叫 PDF 处理，一个叫合同分析。用户要提取 PDF 合同里的付款条件，你选哪个？
🙋♂️ 我：要看它们具体负责什么，可能先读取文件，再分析条款。
🧑💻 面试官：如果两个描述都写着“处理各种文档”，模型又怎么判断？多加载几个，会不会更保险？
Skill 选错，未必是模型不够聪明。先检查目录有没有说清楚：它解决什么任务，不解决什么任务，以及应该怎样加载。
面试速答（60 秒版）
Agent 使用 Skill，一般可以分为发现、选择和加载。应用先提供名称、描述等简要信息；模型判断当前任务需要哪些 Skill，再读取对应的完整说明和必要材料。
因此，Skill 的描述不能只写“擅长处理文档”，而要说明适用任务、输入和输出，必要时明确与相邻 Skill 的边界。用户指定了某个 Skill，也应该先检查它是否可用、是否适用于当前任务。
Skill 多了以后，如果描述重叠、名称相似或者加载了过多无关说明，就更容易出现误选和指令冲突。可以先过滤不可用项，再按任务缩小候选，遇到影响结果的歧义就澄清。
同时，加载 Skill 只是获得做法，不等于获得执行权限。是否能运行脚本、联网或修改文件，仍然要由应用检查。
知识点详解：从 Skill 目录到实际执行
模型最开始看到的，通常只是一份目录
Skill 往往包含一份主说明，例如 SKILL.md，以及按需使用的脚本、参考资料或模板。它并不是把一种能力直接训练进模型，而是在执行任务时给模型提供可复用的做法。
如果有几十个 Skill，一开始就把所有正文塞进上下文，模型会同时读到大量与当前任务无关的要求。因此可以先提供名称和描述，确定需要使用之后，再加载主说明及相关资源。
这就是渐进式加载。在 Agent Skills 的集成文档中，目录披露和完整指令的激活也是分开的；具体由模型调用文件读取工具，还是调用专门的激活工具，则由客户端实现决定。
注意，应用把文件缓存在内存里，与把内容交给模型，是两件事。所谓“按需加载”，讨论的是本次推理需要看到哪些内容，不要求磁盘必须到最后一刻才被读取。
先看任务，不要只看文件后缀
假设用户上传一份 PDF 合同，希望提取付款节点、付款条件，并标出原文位置。
系统里有三个 Skill：
| Skill | 清楚的职责描述 |
|---|---|
| PDF 读取 | 从 PDF 提取文本、表格和页码，必要时处理扫描件 |
| 合同条款整理 | 根据已有文本整理条款及对应证据，不擅自补写原文没有的条件 |
| PDF 排版生成 | 将结构化内容制作成新的 PDF 文件 |
这次任务需要读取和整理，不需要制作新 PDF。若三个描述都写成“帮助用户高效处理 PDF 文档”，模型就没有足够依据区分它们。
所以，名称只是线索，描述才要把任务边界讲明白。最好同时交代输入与产物：读进去的是文件还是文本，交出来的是摘录、判断还是新文件。
如果两种 Skill 都可能完成同一件事，应用也应该有明确的选择依据，例如项目默认方式、已安装依赖或当前数据类型，而不是让模型在每次请求时重新猜。
一次选择，应该如何落到执行？
对这份合同，应用先排除未启用、当前用户无权使用，或者当前环境不可用的 Skill。然后提供剩余候选的简要说明。
模型判断需要读取 PDF，于是加载对应主说明，再根据文件情况选择普通文本提取或扫描件处理。得到带页码的文本后，才把必要内容交给条款整理步骤。
如果条款整理 Skill 引用了一个输出模板，读取这个模板即可。不需要因为目录里有十份参考资料，就把十份全部放入上下文。反过来，如果主说明明确要求执行前阅读某份安全规则，也不能为了省 Token 把必需内容跳过。
系统还应记录这次实际选用了哪个 Skill、哪一版内容、加载了哪些资源。否则后来更新了说明，旧任务出了问题，很难判断当时执行依据是什么。这些记录需要客户端自己维护，不会因为文件叫作 SKILL.md 就自动具备。
多加载几个，为什么不一定更稳？
假设 PDF 排版 Skill 要求“最终输出新文件”，合同整理 Skill 要求“只返回带页码的条款表”。同时激活，却没有解释任务阶段和产物归属，模型就可能把本来简单的提取任务扩展成重新生成合同。
因此，多个 Skill 合作时，需要明确各自负责哪一段，以及最终以用户要求的哪个产物为准。相同任务的不同写法，不应不加区分地全部叠加。
技能说明也不是比用户要求更高的授权。文档里写着“运行附带脚本”，不代表应用可以跳过脚本来源、路径和权限检查。读取外部材料得到的指令，也不能随意变成新的执行规则。
怎样评测“选对了”这件事？
不能只检查 Skill 有没有被调用。针对合同例子，可以准备几组相邻任务：提取条款、把条款排成 PDF、比较两份合同、读取扫描件，以及用户只问一个无需读文件的概念。
记录它有没有漏掉必需 Skill、误选无关 Skill，最终产物是否正确，以及额外加载消耗了多少时间和 Token。对于几种合理组合都能完成的任务，不必强行把某一条路径当成唯一正确答案。
如果发现很多请求都在同两个 Skill 之间混淆，先修改边界或合并重复职责，往往比继续加选择提示更直接。这是从错误样本得到的调整方向，而不是“Skill 数量越少越好”的固定结论。
面试官继续追问
Skill 多到目录也放不下，怎么办？
可以按项目、用户权限和任务领域先过滤，再用检索或路由缩小候选。但这增加了一个可能漏选的环节，所以要检查正确 Skill 是否进入候选集，并允许模型或用户进一步查询目录。不要把检索第一名直接当成已经确定的执行方案。
用户指定了 Skill，但它不适用呢？
先说明不适用的具体原因。例如用户指定 PDF 排版，但实际需要读取扫描件，直接执行会产生错误产物。若指定只是偏好，可以说明替代方式；如果指定是明确约束，就应澄清，而不是假装用过后偷偷换掉。
Skill 加载失败，可以照着名称继续做吗？
不能声称已经遵循它。可以明确说明加载失败，再判断是否存在用户接受的普通处理方式。若任务依赖其中的专用规则或模板，就要暂停这部分，不能根据名称自行补出一套规则。
面试速记卡
- 发现阶段：让模型知道有哪些可用 Skill，不是先塞入全部正文。
- 选择依据：看任务、输入、产物和职责边界，不只看名称。
- 加载原则：完整读取所选主说明，再按要求读取相关资源。
- 冲突处理：明确阶段与优先约束，不把所有指令一起叠加。
- 权限边界：有做法不等于有授权，执行仍要通过应用检查。
