Skill 的实现原理：渐进式披露，以及它和”动态提示词”的关系
日期：2026年9月20日
作者：Honlnk/鸿影
适用读者：AI Agent 工具使用者、想自己写 Skill 的开发者、对提示词工程机制感兴趣的读者
定位说明：会用 Skill 的人很多，但”写在 md 里的文本到底是怎么进提示词的”这个机制问题很少有人展开。本文讲清 Skill 的三层加载机制（渐进式披露），并厘清它和”动态提示词”这个被用滥的词之间的关系。
一、问题的起点：Skill 用起来太简单了
用过 Claude Code / ZCode 这类 Agent 工具的人对 Skill 不陌生：写一个 SKILL.md，顶部是 YAML frontmatter（name + description），下面是 Markdown 正文，旁边可以放脚本和参考文档。丢进技能目录，Agent 就会在合适的时机”自动学会”这套流程。
简单到让人忽略了一个机制问题：这些写在 md 文件里的文本，到底是怎么进入模型上下文的？ 是启动时全部塞进系统提示词？还是别的什么方式？
答案是一个叫**渐进式披露（Progressive Disclosure）**的设计模式。
二、渐进式披露：三层加载机制
先交代词源：Progressive Disclosure 原本是 UX 设计术语——界面先展示最简单的选项，复杂功能在用户需要时才展开。Anthropic 在 Agent Skills 的工程博客里把这个概念借来描述 Skill 的加载机制：把信息分层，每层只在被需要时才进入上下文。
2.1 Level 1：目录常驻（启动时）
会话启动时，Agent 框架扫描所有技能目录，只解析每个 SKILL.md 顶部 --- 之间的 frontmatter，把 name 和 description 收集成一份”技能目录”，注入系统提示词。
关键点：此时正文一个字都没进上下文。每个技能只占几十到一百 token——所以装 50 个技能也不会拖垮上下文。Agent 一上来就知道环境里有哪些技能、每个技能大概是干什么的（靠 description），但不知道任何技能的具体细节。
这也解释了为什么 description 要写成”做什么 + 什么时候触发”——它是写给模型看的匹配依据，不是写给人类看的注释。
2.2 Level 2：正文按需（模型自己决定）
模型看到用户消息后，拿任务意图去匹配目录里的 description。命中后，它调用一个专门的 Skill 工具，框架这时才去读 SKILL.md 的正文，并以工具返回结果（tool result）的形式注入对话流。
注意注入位置：不是系统提示词，而是对话中的一条工具响应。正文可以是几千 token 的完整流程文档，但只在真正用到的那一轮才占上下文。
2.3 Level 3：资源永不主动加载
正文里引用的附属文件——脚本、参考文档、模板——框架完全不处理。模型按照正文的指令，用普通的文件工具去读，或者干脆直接执行脚本。用到才读，用不到就永远躺在磁盘上，访问前成本为零。
2.4 完整链路
启动：扫描 SKILL.md → 只取 frontmatter → 系统提示词里的"技能目录"
↓ 用户发消息
模型：意图匹配目录 → 命中 → 调用 Skill 工具
↓
框架：读正文 → 作为 tool result 注入对话
↓
模型：照正文干活，需要时再读/执行附属文件三层合起来的效果：Agent 始终”知道”所有技能的存在，却只为正在使用的那一个付出完整成本。
三、那”动态提示词”又是什么？
3.1 字面含义 vs 行业惯用
“动态提示词”不是一个有标准定义的术语。它的字面含义很宽：凡是不是写死的字符串、内容在运行时才确定的提示词，都算动态提示词。按这个口径，RAG 把检索结果拼进上下文是，根据用户选择切换不同安全级别的提示词是，甚至连 Skill 加载正文也是。
但在 Agent 开发的日常交流中，这个词发生了语境收窄：工程师说”动态提示词”时，听众默认他指的是开发者在代码里写好组装逻辑、程序运行时无条件注入的那一类——比如项目内置了一批工具、运行时把这些工具的提示词拼接进系统提示词，根据会话状态组装 persona，RAG 检索结果注入。
3.2 分水岭：push 还是 pull
两种机制的真正差异不在”内容是不是运行时进来的”，而在一个问题：这次注入是程序的规则触发的，还是模型的判断触发的？
| 动态提示词（行业惯用义） | 渐进式披露 | |
|---|---|---|
| 决策者 | 开发者写的代码规则 | 模型自己 |
| 方向 | push：程序无条件塞进来 | pull：模型看目录后自己拉取 |
| 注入位置 | 通常是系统提示词 | 对话流中的工具结果 |
| 成本模型 | 组装了就常驻上下文 | 不用就只占目录的几十 token |
| 典型例子 | RAG 注入、工具提示词拼接、按状态切换 | Skill、文件系统探索 |
3.3 一个光谱
静态提示词 动态提示词（狭义） 渐进式披露
写死的字符串 → 程序按规则运行时拼接 → 模型看目录、自己决定加载
开发者全权决定 开发者写规则决定 模型自主决定所以严格地说：渐进式披露也是动态提示词的一种——它最终的上下文同样是运行时才拼出来的。它是”动态”这个大类之下、把组装决策权交给模型的那个特例。
一个容易归错类的例子：Agent 用 read 工具读文件，虽然内容也是运行时才进上下文的，但读什么是模型自己决定的，属于 pull 型，是最原始的渐进式披露，不该归到代码驱动的动态提示词那边。
四、渐进式披露无处不在
一旦认出这个模式，你会发现它到处都是：
- 文件系统本身就是天然的两层结构——目录列表是元数据，文件内容是正文。Agent 用
ls/grep/read探索代码库，而不是把整个仓库塞进上下文，这就是渐进式披露的原始形态； - DeepWiki 的 MCP 接口——先
read_wiki_structure拿目录树，再read_wiki_contents取具体某一页，同样是”先目录后正文”的两级设计（参见上一篇 llm-wiki-and-deepwiki）； - MCP 工具列表——工具的名字和描述常驻上下文，工具的执行结果按需返回，也是同一个思想。
Skill 只是把这个早已存在的思想 formalize 成了规范：frontmatter 约定、触发协议、三层结构。
五、结语：Skill 的本质
Skill 不是什么新技术。它的本质是**“惰性加载的提示词片段 + 一套加载协议”**。
它真正做的设计决策只有一个，但很关键：把”什么时候该把哪段提示词放进上下文”的决定权，从开发者代码手里移交给了模型自己。 开发者不再需要在代码里写死”什么场景注入什么提示词”的规则——规则总有写不全的时候——只需要把知识整理成带描述的技能文档，剩下的匹配与加载交给模型判断。
从这个角度看，Skill 和动态提示词不是竞争关系，而是同一个问题的两代答案：上下文窗口有限，如何把对的文本在对的时间放到模型面前——动态提示词用开发者的规则回答，渐进式披露用模型的自主性回答。
参考与延伸
- Equipping agents for the real world with Agent Skills——Anthropic 工程博客，渐进式披露概念的出处
- Agent Skills 开放规范 与 anthropics/skills 示例仓库
- 本系列上一篇：AI 圈的 “Wiki” 到底是什么：从 LLM Wiki 到 DeepWiki