一、搞懂：Skill 到底是什么

Skill 可以理解为给 Agent 准备的一份份专业操作手册，定义完成一类任务的完整步骤。 一个 Skill 一般是独立文件夹，标准目录结构如下：

plaintext

skills/
├─ pdf‑analysis/
│  ├─ SKILL.md      # 核心：告诉Agent操作步骤、要求
│  ├─ references/   # 详细参考资料
│  └─ scripts/      # 可调用脚本程序
├─ excel‑analysis/
│  ├─ SKILL.md
│  ├─ references/
│  └─ scripts/
└─ database/
   └─ SKILL.md

• SKILL.md：核心说明书，写明完成这项任务一步步怎么做；
• references/：存放补充参考文档；
• scripts/：存放可被调用的程序脚本。

Skill 不只是一个 Markdown 文本文件，是一组包含说明、参考资料、可执行脚本的资源集合。

二、为什么不能把所有 SKILL.md 全部塞进 Prompt？

假设我们拥有 100 个 Skill，每一份 SKILL.md 都有上千 token。用户仅仅希望分析 PDF 文件，如果我们启动 Agent 的时候，把 100 份 Skill 完整文档全部放进 Prompt，会带来 3 个严重问题：

1. 浪费宝贵上下文窗口：只需要 PDF 分析，却加载了 Excel、数据库、PPT 等全部无关技能，挤占 token 预算。
2. 无关信息带来干扰：大量无关说明书混杂在 Prompt，模型容易混淆不同技能规则，产生幻觉。
3. 调用成本暴涨：每一轮请求都携带海量文本，推理耗时、Token 成本急剧上升。

所以工业界不会采用全量加载，采用渐进式加载：先拿到技能目录，用到哪个，才加载哪个完整说明书，就如同去图书馆，不会把全部书籍搬回家，只拿自己要看的那一本。

三、Skill 渐进式加载完整六步流程

步骤 1：宿主程序发现全部 Skill

宿主扫描 skills 目录，扫描所有可用 Skill，此时只是发现存在哪些技能，不会读取 SKILL.md 完整正文。

举例：扫描得到三个技能：table‑cleaning、pdf‑analysis、image‑compression。

步骤 2：读取元数据（YAML Frontmatter）

只读取每个 SKILL.md 文件最开头的元数据部分：name、description，保存文件路径，组装一份轻量化技能目录。 这份目录体积很小，只保存技能名字 + 简短描述，交给大模型，模型只知道 “我现在拥有哪些能力”，并不知道每个技能内部详细操作步骤。

步骤 3：模型选择需要使用的 Skill

拿到轻量化技能目录之后，结合用户当前任务，模型判断需要哪一项 Skill；也可以由用户显式指定 Skill，或者由宿主规则路由选择，不一定完全交给模型判断。

例子：用户要求清理 Excel 表格，模型读取元数据描述，判断任务需要table‑cleaning技能。

步骤 4：按需读取完整 SKILL.md 正文

宿主收到 “需要 table‑cleaning” 信号，才去磁盘读取 table‑cleaning/SKILL.md完整全部内容，把这份完整操作指南注入上下文，模型此时才拿到详细操作步骤。

步骤 5：模型按照 Skill 的步骤做任务规划

模型依据 SKILL.md 里面的操作流程，规划后续工具调用，例如：检查 Excel、识别重复行、统一格式、校验空值、保存文件。

步骤 6：辅助资源继续按需懒加载

就算该 Skill 被加载，references参考文档、scripts 脚本，也不会一次性全部读入上下文。 执行流程走到需要某份参考资料，才读取对应 md；需要运行程序，才调用 scripts 下脚本。做到资源最大限度按需读取，减少上下文压力。

四、面试高频坑点：加载 Skill ≠ 执行 Skill

面试官很喜欢追问这个点，很多同学在这里答错。

场景：SKILL.md 文档写了：运行scripts/clean.py清理 Excel。 当模型读取完这份 SKILL.md，脚本会不会自动运行？

答案：不会！ SKILL.md 里面文字，仅仅是给模型阅读的操作指令、步骤说明，文本本身不会自动执行程序。想要真正运行脚本，仍然需要 Agent 发起工具调用，由宿主程序执行脚本。 加载 Skill 只是把操作手册交给模型看，真正执行动作依旧依赖工具调用链路，这点一定要分清。

五、渐进式加载带来的收益

1. 极大节省 Token 开销：常驻上下文只有技能元数据目录，大量技能说明书只在命中任务的时候才加载。
2. 减少无关信息干扰：不会把上百份技能全部堆进 Prompt，降低模型混淆规则的幻觉概率。
3. 支持大规模 Skill 扩展：可以挂载几十上百个 Skill，不会随着技能数量膨胀直接打满上下文窗口。

六、它的局限性（面试加分，体现客观思考）

1. 多 Skill 协同任务，一次性要加载多份 SKILL.md，这时候要做好上下文预算控制，防止加载多份说明书把 token 占满；
2. 增加工程复杂度，需要实现目录扫描、元数据解析、按需读取文件逻辑；简单 Demo 场景，少量 Skill 直接全量塞 Prompt 可以接受，但生产环境禁止。

面试满分总结话术

Skill 渐进式加载核心是 “元数据常驻，正文按需加载”。宿主先扫描所有 Skill，仅提取技能名称与简短描述组成轻量目录交给模型；当任务判定需要某个 Skill，再读取完整 SKILL.md，执行过程中参考资源继续懒加载。注意加载 Skill 只是读取操作手册，不等于自动执行脚本，执行仍然依靠工具调用。该方案解决大量 Skill 全量塞进 Prompt 带来的上下文浪费、信息干扰、成本过高问题，适合生产环境大规模技能场景。

文末互动

你们项目中 Skill 是全量加载还是渐进式加载？踩过哪些坑？评论区一起聊聊！