1. 问题从哪里开始#

理解 Agent Skill(智能体技能)最常见的误区,是把它想象成”给模型装了个插件”或”让模型学会了新本事”。这两种直觉都不准确。

真正需要先接受的前提是:Skill 从头到尾没有触及大语言模型(LLM)本身——它不修改任何一个模型权重,不改变模型的推理过程,也不是模型”内部”的一部分。一个 Skill 最终对模型产生影响的唯一途径,和一段普通提示词(prompt)完全一样:变成 token,进入上下文窗口(context window),被同一次前向推理(forward pass)读取。

所以要真正搞懂 Skill 是什么,不能停留在”它是一种能力封装”这种模糊说法：

• 它到底以什么形式存在于磁盘上?
• 它以什么角色(role)、在什么时机进入上下文窗口?
• 它和普通 prompt、和 system prompt、和 tool call、和 MCP 到底是什么关系?

我们可以通过这几个问题来搞懂skill。

本质上,Skill 是一套围绕”上下文窗口”这一稀缺资源做加载调度的机制,而不是一样神秘的新东西。

2. Skill 的起源:谁提出的,为了解决什么#

Agent Skills 这一概念由 Anthropic 在 2025 年 10 月正式提出,并很快演变成一个跨平台的开放格式——微软 Copilot Studio、GitHub Copilot、Cursor、Gemini CLI 等生态随后都采用或兼容了这套思路。

它要解决的,是纯 prompt 工程在规模化时的三个结构性痛点:

简单来说:Skill 是把 prompt 工程”产品化”了——加上了持久化、按需加载、自动路由,以及(关键的)可选的代码执行能力。

3. Skill 到底是什么:定义与形式#

从底层来讲,一个 Skill 就是磁盘上的一个文件夹。文件夹里必须有一个 SKILL.md 文件,可选地附带脚本、参考文档、模板等资源。

一个完整 Skill 在磁盘上长这样:

1
pdf-skill/                    ← 整个 Skill 就是一个文件夹
2
├── SKILL.md                  ← 核心:元数据(标题)+ 正文(指令)
3
├── scripts/                  ← 可执行脚本
4
│   ├── fill_form.py
5
│   └── merge_pdf.py
6
├── references/               ← 参考文档
7
│   └── pdf_spec_notes.md
8
└── assets/                   ← 模板 / 静态素材
9
    └── letterhead_template.pdf

SKILL.md 本身内部又分两部分:

1
---
2
name: pdf-form-filler
3
description: 当用户需要填写或处理 PDF 表单时使用     ← 元数据(标题)
4
---
5
# 填写 PDF 表单                                      ← 正文(指令)1. 读取用户提供的字段数据
6
2. 调用 scripts/fill_form.py 完成填充
7
3. 细节规格见 references/pdf_spec_notes.md
8
...

它把”某一类任务该怎么做”的流程性知识固化下来,让一个通用模型在需要时表现得像某个领域的专家。

4. 三层结构:渐进式披露(Progressive Disclosure)#

Skill 最核心的设计,是把内容分成三层,按需逐层加载。这套机制叫渐进式披露,目的只有一个:省上下文窗口。

用一个类比贯穿理解:

• L1 元数据 = 一本书的书名 / 目录里的一行标题——“第 7 章:如何填 PDF 表单”。
• L2 正文 = 第 7 章的完整内容。平时不翻,真要做这件事时才翻到那一页读进来。
• L3 资源 = 附录里的计算器和详细规格表。你用计算器算,但不需要把它的电路图背下来。

正因如此,有 50 个 Skill,平时只占 50 行简短描述的成本(几百 token),而不是 50 套完整指令。模型在有限窗口里能”认识”上百种能力,却不必时刻背着它们的全文。

1
flowchart TD
2
    A[会话启动] --> B[L1: 50 行 description 常驻 system]
3
    B --> C{用户提出需求}
4
    C -->|匹配到某 Skill| D[L2: 该 Skill 正文动态注入]
5
    D --> E{正文里引用了资源?}
6
    E -->|要执行脚本| F[L3 scripts: 窗口外运行, 只回填结果]
7
    E -->|要查参考| G[L3 references: 按需读取部分进窗口]
8
    E -->|不需要| H[直接完成任务]

5. 例子:生成规范 Excel#

用同一个任务对比”纯 prompt”和”Skill”,能立刻看清差别。任务是:把一批数据做成一张格式规范的 Excel 表。

方案 A — 纯 Prompt(每次手敲):

1
请帮我生成 Excel。要求:
2
- 表头加粗、底色深蓝、白字
3
- 冻结首行,数字列右对齐保留 2 位小数
4
- 金额列用千分位,列宽自适应
5
- 用 openpyxl 输出到 output.xlsx
6
数据如下:...

下次再做同类任务,这段又得从头贴一遍。

方案 B — Skill(建一次,长期复用):

1
xlsx-skill/
2
├── SKILL.md          # name + description + 上面那套格式规范
3
└── scripts/
4
    └── format_table.py   # 真正干活的代码

之后你只需说”把这批数据做成 Excel”,模型读到 L1 描述判断匹配,把 L2 正文拉进来,再调用 format_table.py 完成——那段格式规范再也不用手敲。

6. Skill vs Prompt:本质相同,定位不同#

两者本质上都是”外部输入”:都不改变模型权重,都以 token 进入上下文,由同一次推理处理。 从这个意义上说,它们和微调(fine-tuning)、RLHF 这种真正改动参数的手段有本质区别——后者才”触及根本”。

但在”外部提示”这个大类里,两者定位差别很清楚:

关键区别不在”是否触及模型”,而在”复用性 + 加载机制 + 谁来触发 + 能否外挂执行”。 Skill 可以粗略理解成”被规范化、模块化、按需加载的 prompt 仓库”,外加一层纯 prompt 做不到的可执行能力。

7. Skill 是不是 system prompt?#

既然skill是以prompt的形式出现在上下文，那么它的role是什么，是system prompt吗？

答案是:不完全等于,但有交集,而且必须精确措辞。

先厘清 “system prompt” 到底指什么。在一次推理里,送进上下文窗口的文本按**角色(role)**分层:

所谓 system prompt,就是 System 角色那一段,而它的定义里隐含了”静态常驻”。

Skill 的两层内容,落点不同:

• L1 元数据(那行描述) → 确实被塞进 System 区并常驻,让模型一直知道有哪些技能可选。这部分算 system prompt 的一部分。
• L2 正文 → 触发后动态注入。它以 System 级的权威进入,但它是”会进出的”,不是一开始就钉在那儿的固定 prompt。

所以严谨的表述是:

L2 正文是”动态注入的 system 级指令片段”,而不是”一段动态的 system prompt”。

而且要记住:Skill ≠ 只有正文。它还有 L3 那层——那是窗口外的可执行代码,根本不是 prompt。所以”本质上是一种 prompt”这句话只覆盖了 L1 + L2。

8. 动态注入 vs 静态注入:区别到底在哪#

这是理解 Skill 机制的核心:

对模型的单次前向推理来说,“一开始注入”和”运行时注入”没有任何区别。 模型只看它这一刻窗口里有什么 token,token 不带时间戳,模型无从分辨哪段是开机就有、哪段是刚才才塞的。

那区别在哪?在整场多轮对话里,这段文本存在多久、占用多少、由谁决定。

一个推演最能说明问题。假设有 50 个 Skill、对话进行 10 轮:

• 若全部静态注入:每一轮窗口都背着 50 套完整正文(比如 5 万 token),被重复喂 10 次,而大部分这次根本用不上——纯浪费,上下文窗口很快撑满。
• 若动态注入:任何一轮窗口里只有”50 行索引 + 当前用得上的那 1 套正文”,省下 90%+ 的空间。

动态注入最大的价值是”可逆、可调度”:

系统能用有限窗口支撑海量能力——模型平时只背一份薄目录,真要用哪一章,编排器现场翻开塞给它,用完合上。

9. L3 资源:不进窗口,怎么执行?#

这里要破除第二个误区:“进上下文”和”被执行”是两条完全独立的路径。 上下文窗口是给模型”读”的;执行是在模型之外的机器上”跑”的。

模型本身不运行任何代码。 LLM 是个文本预测器,只会输出 token。真正干活的是它旁边的运行环境(runtime / sandbox / 工具执行器)。流程是:

1
① 模型在 L2 正文里读到:"调用 scripts/format_table.py 处理数据"
2
② 模型据此输出一个动作指令 token:
3
   { "tool": "bash", "command": "python scripts/format_table.py data.csv" }
4
③ 外部执行器收到 → 在沙箱里真正运行那个 .py 文件
5
④ 脚本跑完,把【结果】(成功/报错/输出值)作为文本回填进上下文窗口
6
⑤ 模型读到结果,继续下一步

所以进出上下文的到底是什么,要分清:

10. role 的定义权与生效层级#

一个更底层的问题:注入进上下文的那段东西,role 到底是谁定的、在哪一层生效?这要拆成两个不同的问题。

1
<|system|> 你要遵守...  <|end|>
2
<|user|>   帮我做...    <|end|>
3
<|assistant|> ...

11. L3 的 reference 如何参与上下文#

L3 内部还要再分”读”和”跑”两种命运——第 9 节讲的是”跑”(脚本),这里讲”读”(参考资料)。

核心区别 通常不是被系统被动”直接加载”,而是模型主动去”读”的。

具体流程——它走的是和 L3 脚本执行一模一样的工具调用管线,只不过脚本是”跑”、reference 是”读”:

1
① 模型读到 L2 正文:"详细规格见 references/spec.md"
2
② 模型判断:这次任务需要这个细节
3
③ 模型输出动作 → { "tool": "read_file", "path": "references/spec.md" }
4
④ 外部执行器读取该文件 → 把内容(或指定的某几段)作为【结果】回填
5
⑤ 这段文本进入上下文,role 通常是 tool,模型接着用

所以 reference 回填进上下文时,最典型的 role 是 tool(工具返回结果)——因为它复用了现成的文件读取管线,和 L3 脚本共用一套机制。同样,这也是实现相关的:少数实现会直接把内容拼进 system 上下文,role 就成了 system。

reference 常常不是全量加载。它的价值恰恰在于可以只读需要的片段——带 offset 的部分读取,或先读目录 / 摘要再决定深入哪段。这就是**“更深一层的渐进式披露”** → L2 渐进过一次,reference 内部还能再渐进一次,尽量少占窗口。

12. 核心结论#

1. Skill 从头到尾没有触及 LLM 本身。 它不改权重、不改推理,最终只是以 token 进入上下文窗口,和普通 prompt 走同一条路。它与微调 / RLHF 有本质区别。

2. Skill 由 Anthropic 于 2025 年 10 月提出,现已成为跨平台开放格式。 它把 prompt 工程”产品化”,解决了纯 prompt 的三大痛点:不可复用、占满上下文、要人手动触发。

3. 一个 Skill 就是一个文件夹,核心是 SKILL.md,内容分三层 元数据(常驻的”书名”)、L2 正文(动态注入的”章节内容”)、L3 资源(窗口外的脚本 / 参考 / 素材)。

4. 渐进式披露是它的灵魂。 平时只暴露 L1 的简短描述,匹配到任务才注入 L2;省的是上下文窗口这一稀缺资源的调度效率,而非模型的理解力。

5. “动态注入”与”静态注入”对模型单次推理无区别(token 不带时间戳),区别在多轮对话中”存在多久、占多少、谁调度”——静态是纹身,动态是便利贴。

6. L1 + L2 本质是”动态加载的 system 级提示”;L3 不是提示,是窗口外的可执行资源。 L3 内部又分两种命运:脚本”给机器跑”(bash 或 MCP,不进窗口,只回填结果),参考资料”给模型读”(按需读片段进窗口,role 通常是 tool)。

7. role 的词汇表由 API 定义,role 的权力由训练在模型端刻死。 Skill 正文以 system 级权威进入上下文永远成立,但其字面 role(system / tool / developer)取决于具体产品实现,唯一确定的是它绝不是 user。

Skill 不是一样神秘的新东西,而是一套围绕上下文窗口做加载调度的机制——用一个静态常驻的”书名”(L1)在 system 里挂号,用到时把”正文”(L2)以 system 级权威动态注入,必要时再指挥窗口外的脚本(L3)去干活。读的归读,跑的归跑,谁都不挤占本就稀缺的上下文窗口。