这张图在讲： “技能（Skills）是怎么被塞进模型的上下文窗口（Context Window），以及模型在对话中如何‘触发’技能并按技能说明去调用工具。”
你可以把它理解成一套“给 AI 装插件 + 插件使用手册 + 运行时调用”的机制示意图。
下面按图里的结构逐层拆开讲。
1）大框：Context Window（上下文窗口）是什么
图中间的大灰框叫 Context Window，代表“模型在这一轮回答之前能看到的全部信息”。
它主要由三类东西组成：
-
Agent’s System Prompt（系统提示词）
- 相当于“AI 的岗位说明书 + 行为规则”
-
Skills 的短片段（snippets）
- 相当于“插件目录 / 能力清单的摘要”
-
用户的消息（Initial message from user）
- 当前用户请求 + 附件路径等
**重点：**模型不是凭空知道“有 PDF 技能、XLSX 技能”，而是这些技能的“入口提示”被拼进了系统提示词里，所以模型在上下文里能看到它们。
2）上半部分：Skills 怎么进入系统提示词
图左上绿色框写着：
“Short snippets from each Skill appended to the system prompt”
意思是：每个 Skill 都会贡献一小段摘要，被“追加”到系统提示词里。
图里用一排小标签表示这些 skill 的名字或类型：
- bigquery
- docx
- nda-review
- pptx
- …
- xlsx
它表达的是：
系统提示词里不仅有规则，还有一个“技能列表”，告诉模型：你能用这些能力，必要时去触发它们。
但注意：这里通常只是摘要（snippets） ，不是完整说明书。
3）中间：用户消息触发“需要某个技能”的判断
左侧第二个绿色框：Initial message from user
图中用户请求示例是：
“Fill out this PDF based on what you know about me
Attached: /mnt/uploads/order_form.pdf”
这句话同时包含了两个信号：
- 任务类型：填 PDF
- 输入资源：有一个 PDF 附件路径
所以模型会在技能目录里匹配到：pdf skill 可能能解决。
4）右侧：模型如何“触发”技能（trigger）
右边绿色框明确写了：
“Claude decides to ‘trigger’ the PDF Skill by reading it”
意思是：模型决定要用 PDF 技能时，第一步不是直接开始瞎填，而是先去读取该技能的说明文档。
图里用对话框展示了一个典型流程：
Step A：模型声明要用技能
Claude: “Certainly! I’ll use the PDF Skill to help”
这句话不是关键，关键是下一步。
Step B：工具调用读取技能说明（SKILL.md）
Tool use: Bash("cat /mnt/skills/pdf/SKILL.md")
这里表达：技能不是“魔法”，而是一个可读的操作指南（SKILL.md）。
模型先把它读进来，知道：
- 该技能怎么用
- 有哪些工具/脚本
- 流程注意事项
- 输出格式规范等
Step C：工具返回技能说明内容
Tool result: {stdout: "... contents of SKILL.md file ..."}
这一步把“技能手册”真的塞回上下文里，模型就能按手册操作了。
5）技能说明里可能还引用更多文件（forms.md）
右下绿色框写着：
“Claude decides to follow the reference from the SKILL.md to the forms.md file”
意思是：SKILL.md 可能只是入口说明，还会链接更细的子文档，比如：
- forms.md：专门讲“怎么填表单/字段映射/校验规则”
- examples.md：示例
- troubleshooting.md：排错
图中因此出现第二次工具调用：
Tool use: Bash("cat /mnt/skills/pdf/forms.md")
Tool result: {stdout: "... contents of the forms.md file ..."}
这表达的是一个“递归式加载”模式：
先读技能入口 → 发现引用 → 再读更详细的指南 → 然后按指南执行真实任务
6）这张图整体想传达的核心概念（总结成一句话）
Skills 并不是模型“天生会”，而是：
- 在系统提示词里给一个“技能目录摘要”
- 当用户需求出现时，模型决定用哪个技能
- 然后通过工具把该技能的完整说明文档读进上下文
- 再按照说明文档去执行任务（比如操作 PDF）
7）你可以把它类比成什么
- Skills snippets = 菜单
- SKILL.md / forms.md = 菜谱 + 操作手册
- Bash 调用 = 去厨房拿菜谱并照做
- Context Window = 当前厨师台面上摆着的所有信息
没有菜谱（不读 SKILL.md），模型就容易“凭感觉做菜”（幻觉、流程不一致）。
来看看第二张图
两张图放在一起看，其实正好解释了一个关键设计目标：
Skills 的本质作用之一：在不牺牲能力的前提下，极大节省 context window。
下面我用「问题 → 对比 → 机制 → 总结」的方式，把这个逻辑完整串起来。
一、先明确问题：为什么 context window 是稀缺资源？
Context window 里放的东西有三个特点：
- 越多越贵（token 成本）
- 越多越慢（推理负担）
- 越多越容易互相干扰（指令冲突、噪声）
但现实中我们又希望模型“会很多事”：
- 会 PDF
- 会 XLSX
- 会 SQL / BigQuery
- 会 NDA review
- 会 Bash / Gmail / Forms …
天真的做法是：
👉 把所有能力的完整说明，一次性塞进 system prompt
结果就是：context 爆炸 💥
二、没有 Skills 的世界（第一张图左半部分）
回顾你第一张图（Without Bash / Without Skills）隐含的问题：
特点
-
模型没有外部执行环境
-
所有“能力说明 + 操作逻辑”必须：
- 预先写进 prompt
- 或靠模型“记忆 + 想象”
后果
-
为了让模型会做事，你不得不：
- 把大量说明塞进上下文
-
但即使塞了：
- 模型也只是“描述自己会怎么做”
- 没有真实执行
-
还容易 hallucinate（胡算、胡填）
👉 既费 context，又不可靠
三、Skills 的核心节省机制（第二张图）
第二张图展示的正是反模式的解法。
关键设计思想（非常重要）：
不是把“能力”放进 context
而是把“能力入口（index / pointer）”放进 context
我们拆开来看。
四、Skill 是如何“分层加载”的（节省 context 的关键）
第 1 层：Skill Snippets（极小）
在 system prompt 里只放：
- 技能名称
- 能力摘要
- 触发条件（非常短）
比如（概念示意）：
You have access to a PDF skill that can read and fill PDF forms.
✅ 成本：极低
❌ 但还不能直接用
第 2 层：按需触发（lazy loading）
当用户说：
“Fill out this PDF … attached order_form.pdf”
模型判断：
- 当前任务 真的需要 PDF skill
- 其他技能（xlsx / bigquery / pptx）完全不相关
于是它做的是：
只加载 PDF skill 的说明
而不是：
- 一次性加载所有技能说明
第 3 层：只读入口文档（SKILL.md）
cat /mnt/skills/pdf/SKILL.md
这一步的意义是：
- 把“PDF 技能的使用手册”拉进 context
- 仅此一个技能
context 里现在包含：
- system prompt
- PDF skill 的完整说明
- 用户请求
📉 context 仍然是可控的
第 4 层：继续按引用加载（仍然是按需）
如果 SKILL.md 里说：
“For form filling, see forms.md”
模型才会再去加载：
cat /mnt/skills/pdf/forms.md
⚠️ 注意：
- 只有当任务真的涉及“表单填写”
- 才加载 forms.md
五、对比总结：Skills vs 全量 Prompt
❌ 不用 Skills（全塞进 prompt）
| 问题 | 结果 |
|---|---|
| 所有能力说明都在上下文 | context 很快爆 |
| 无法动态裁剪 | 无关内容污染推理 |
| 无真实执行 | 高幻觉率 |
✅ 使用 Skills（按需加载）
| 机制 | 节省点 |
|---|---|
| 只放 skill snippet | system prompt 极小 |
| lazy loading | 只加载当前任务需要的能力 |
| 文件引用结构 | 不一次性读完所有文档 |
| 工具执行 | 不用靠语言“模拟”流程 |
👉 能力规模 ∝ 技能数量
👉 context 使用量 ∝ 当前任务复杂度
这是一个非常漂亮的解耦。
六、再把两张图合在一句话里
第一张图说明：不把事情真的交给工具，模型只能在 context 里“脑补”，既费 token 又不准。
第二张图说明：Skills 把能力变成“可按需加载的外部模块”，context 只承担“索引和当前任务”的角色。
七、一句工程化总结
Skills 通过“能力外置 + 入口内置 + 按需加载”，
把 context window 从“能力仓库”降级为“调度台”，
从而用更少的 token，支撑更多的能力。
