从 Function Calling 到 Skill：Agent 如何把能力沉淀成可复用的“技能包”？

一、学习背景：为什么今天会学到 Skill？

前面一段时间，我一直在围绕 Agent 的能力构建往下学。

大概学习路线是这样的：

Prompt
  ↓
Function Calling
  ↓
Tool Use
  ↓
MCP
  ↓
RAG
  ↓
Multi-Agent
  ↓
Skill

一开始我理解的大模型，更多是：

用户输入问题，大模型生成回答。

后来学习 Function Calling 之后，发现大模型不只是“说”，它还能判断什么时候需要调用函数。

再往后学习 Tool Use，理解了工具可以把大模型和真实系统连接起来，比如查询天气、查数据库、读文件、调用接口。

然后学习 MCP，发现工具还可以被标准化暴露出来，让 Agent 通过统一协议访问外部能力。

再学习 RAG，理解了大模型本身不知道所有外部知识，所以需要先检索资料，再基于资料回答。

到这里其实已经能看出一个趋势：

Agent 的能力不是只靠模型本身，而是由模型、工具、知识库、上下文和执行流程共同组成。

今天学习的 Skill，刚好是在这个基础上继续往前走。

如果说 Function Calling 解决的是：

大模型怎么调用函数？

Tool Use 解决的是：

Agent 能使用哪些工具？

MCP 解决的是：

外部工具如何标准化接入？

RAG 解决的是：

Agent 如何获取外部知识？

那么 Skill 更像是在解决：

Agent 面对一类任务时，应该按照什么经验和流程去完成？

这就是今天 Skill 这个概念出现的位置。

---

二、Skill 是什么？

1. 一句话理解 Skill

我现在对 Skill 的理解是：

Skill 是把 Agent 处理某一类任务的经验、步骤、规则和示例封装起来，形成一个可复用的能力包。

它不是一个简单的工具，也不是单纯的一段 Prompt。

它更像是给 Agent 准备的一份“任务操作手册”。

当 Agent 遇到某类任务时，可以参考 Skill 中的说明，知道：

• 这个任务适合用什么思路处理

• 应该先做什么，再做什么

• 需要注意哪些边界条件

• 输出结果应该是什么格式

• 是否需要调用脚本或工具

• 哪些情况不应该乱做

所以 Skill 的核心不是“提供一个能力按钮”，而是：

把做事的方法沉淀下来。

---

2. 用一个简单例子理解

假如有一个 Agent，要帮用户分析一个项目。

如果没有 Skill，用户可能每次都要告诉它：

你先看目录结构，再看依赖文件，再看启动类，再看配置文件，
然后总结项目技术栈、启动方式、模块作用和常见问题。

这就是临时 Prompt。

但是如果我们把这个分析流程写成一个 Skill，那么以后遇到类似项目分析任务时，Agent 就可以直接参考这个 Skill。

例如这个 Skill 可以叫：

project-quickstart-skill

它可以规定：

1. 先识别项目语言和框架
2. 再查看依赖管理文件
3. 找启动入口
4. 分析配置文件
5. 梳理模块结构
6. 总结启动命令
7. 提醒可能缺少的环境

这样，Agent 就不是每次从零理解任务，而是可以复用已经整理好的方法。

---

三、Skill 解决的核心问题是什么？

我觉得 Skill 主要解决三个问题。

---

1. 减少重复 Prompt

很多任务其实是重复的。

比如：

分析项目
整理文档
生成 README
排查报错
总结论文
分析日志
生成学习笔记
梳理代码结构

这些任务每次都重新写 Prompt，会很麻烦。

而且人写 Prompt 很容易漏掉要求。

Skill 可以把这些固定要求提前沉淀下来，让 Agent 后续直接复用。

也就是说：

临时 Prompt：这次怎么做
Skill：以后遇到这类任务都怎么做

---

2. 提高 Agent 输出稳定性

大模型每次回答可能不一样。

同一个任务，如果 Prompt 写得不够具体，Agent 可能这次先分析目录，下次先讲概念，再下次直接给结论。

输出风格和流程都不稳定。

Skill 可以明确规定任务步骤和输出格式。

例如：

必须先分析输入内容
再判断任务类型
再执行对应流程
最后给出结构化结果

这样 Agent 的执行就会更稳定。

---

3. 把经验沉淀成能力资产

这是我觉得最重要的一点。

学习 Agent 的过程中，我们会不断积累经验。

比如：

• 分析 Spring Boot 项目应该先看 pom.xml

• 分析 Docker 项目应该先看 docker-compose.yml

• 分析 Skill 项目应该先看 SKILL.md

• 分析 RAG 项目应该重点看文档切分、向量化、检索和生成链路

• 分析 Agent 项目应该重点看工具注册、状态流转和任务规划

这些经验如果只停留在脑子里，下次还要重新组织。

但如果写成 Skill，就变成了可复用资产。

所以 Skill 其实有点像：

经验 → 规则 → 流程 → 可复用能力

这也是我今天觉得 Skill 很有价值的地方。

---

四、Skill 和 Prompt 的区别

刚开始我最容易混淆的就是：

Skill 不就是 Prompt 吗？

现在看，它们确实有关系，但不是一回事。

---

1. Prompt 是一次性任务指令

Prompt 更像是当前这一次对话中的指令。

例如：

帮我分析这个项目怎么启动。

或者：

帮我总结一下今天学习的 MCP。

Prompt 的特点是：

临时性强
依赖当前上下文
每次都可能重新写

---

2. Skill 是可复用任务规范

Skill 更像是长期保存下来的任务规范。

它不只告诉 Agent “做什么”，还告诉 Agent “怎么做”。

比如一个项目分析 Skill 可能会写：

当用户上传一个项目并希望理解项目时，按照以下流程处理：

1. 识别项目语言
2. 判断框架类型
3. 查找依赖文件
4. 查找启动入口
5. 分析配置文件
6. 总结模块结构
7. 给出启动步骤
8. 提醒常见问题

所以它比普通 Prompt 更系统。

可以这样理解：

Prompt 是临时指令
Skill 是长期方法

---

五、Skill 和 Tool 的区别

前面学习 Function Calling 和 Tool Use 的时候，我已经知道 Agent 可以调用工具。

比如：

天气查询工具
计算器工具
数据库查询工具
日志查询工具
文件读取工具
搜索工具

但是 Skill 和 Tool 不一样。

---

1. Tool 解决“能不能做”

Tool 更像具体能力。

例如：

read_file(path)
search_docs(query)
query_database(sql)
call_api(url)

这些工具解决的是：

Agent 能不能读取文件？
能不能查询数据库？
能不能搜索资料？
能不能调用接口？

所以 Tool 更偏执行能力。

---

2. Skill 解决“怎么做好”

Skill 更偏任务方法。

比如 Agent 有 read_file 工具，不代表它就一定会很好地分析项目。

因为分析项目不是简单读一个文件，而是要知道：

先读哪个文件
哪些文件更重要
怎么判断技术栈
怎么找启动入口
怎么总结模块
怎么发现潜在问题

这些就属于 Skill 的范围。

所以可以简单区分：

Tool：提供动作
Skill：组织动作

或者说：

Tool 是手
Skill 是做事的方法

---

六、Skill 和 RAG 的区别

RAG 之前已经学习过，它的核心是：

先从外部知识库检索相关内容，再让大模型基于检索结果回答。

RAG 主要解决的是“知识不足”的问题。

例如：

模型不知道某个项目文档
模型不知道某个公司内部规范
模型不知道某篇论文内容
模型不知道用户上传的资料

这时候需要 RAG。

---

Skill 解决的不是知识不足，而是方法不足。

例如：

如何分析一个项目？
如何排查一个报错？
如何生成一份结构化说明？
如何处理一类固定任务？

这些问题不只是需要知识，还需要流程和经验。

所以可以这样理解：

RAG：补充外部知识
Skill：沉淀任务方法

当然，两者可以一起用。

例如用户上传一个项目，让 Agent 分析项目结构。

这时：

RAG 可以帮助检索项目文档和代码片段
Skill 可以指导 Agent 按固定流程分析项目

它们不是互相替代，而是互补关系。

---

七、Skill 和 MCP 的区别

MCP 之前学习的时候，我理解它主要是：

让 Agent 通过统一协议访问外部工具和数据源。

比如通过 MCP Server 暴露：

文件系统工具
数据库工具
GitHub 工具
日志查询工具
浏览器工具
搜索工具

MCP 更像一个工具接入标准。

而 Skill 不负责定义协议，也不一定直接暴露工具。

Skill 更像是告诉 Agent：

拿到这些工具之后，你应该怎么组合使用它们。

举个例子：

如果 MCP 提供了这些工具：

读取文件
列出目录
执行命令
搜索文本

那么 Skill 可以规定：

分析项目时：
1. 先列出目录
2. 再读取依赖文件
3. 再查找启动类
4. 再读取配置文件
5. 最后总结运行方式

所以 MCP 和 Skill 的关系可以理解为：

MCP 提供工具入口
Skill 提供使用方法
Agent 负责判断和执行

---

八、Skill 和 Workflow 的区别

Workflow 是固定流程。

比如：

A → B → C → D

每一步比较明确，适合流程稳定的任务。

而 Skill 可以包含 Workflow，但 Skill 不一定完全等于 Workflow。

Skill 更偏“指导规则”。

它可以告诉 Agent：

通常先做 A
如果发现某种情况，再做 B
如果缺少文件，就提醒用户
如果任务复杂，就分阶段输出
如果信息不足，不要乱猜

所以 Skill 比固定 Workflow 更灵活。

可以这样理解：

Workflow：固定流程编排
Skill：可复用任务经验

Skill 里面可以写 Workflow，但它还可以包含：

适用场景
不适用场景
输出格式
注意事项
示例
辅助脚本
边界条件

这也是 Skill 更像“能力包”的原因。

---

九、一个完整 Skill 通常包含什么？

一个比较完整的 Skill，通常不是只有一个文件。

它可能包含：

my-skill/
├── SKILL.md
├── README.md
├── examples/
├── scripts/
├── assets/
└── LICENSE

下面分别理解。

---

1. SKILL.md：核心说明文件

SKILL.md 是 Skill 最核心的文件。

它主要给 Agent 看。

里面通常会写：

Skill 名称
Skill 描述
适用场景
执行步骤
输入要求
输出格式
注意事项
示例

例如：

---
name: project-quickstart
description: Help analyze a software project and explain how to run it.
---

# Project Quickstart Skill

## Purpose

This skill helps analyze a project structure, identify the technology stack,
find startup commands, and explain common setup issues.

## When to use

Use this skill when the user uploads or links a software project and wants to understand how to run it.

## Workflow

1. Inspect the project structure
2. Identify dependency files
3. Locate the application entry point
4. Analyze configuration files
5. Summarize startup steps
6. List common errors and fixes

这里最上面的：

---
name: project-quickstart
description: Help analyze a software project and explain how to run it.
---

叫做 YAML Front Matter。

它的作用是提供元信息。

也就是告诉系统：

这个 Skill 叫什么
这个 Skill 大概是干什么的
什么情况下可能会用到它

---

2. README.md：给人看的说明

README.md 主要是给人看的。

如果 Skill 上传到 GitHub，别人点进仓库后，第一眼看到的一般就是 README。

README 适合写：

这个 Skill 的用途
适合什么场景
目录结构
怎么使用
示例效果
更新计划

简单来说：

SKILL.md 更偏给 Agent 看
README.md 更偏给人看

---

3. examples：示例文件

examples 目录可以放输入输出示例。

比如：

examples/
├── example-input.md
└── example-output.md

示例的作用很大。

因为大模型不仅看规则，也很依赖示例。

如果 Skill 里写了一个好的示例，Agent 就更容易模仿这个结构输出。

例如项目分析 Skill 可以放一个示例：

输入：一个 Spring Boot 项目目录
输出：技术栈、模块结构、启动步骤、常见问题

这样 Agent 后面处理类似任务时，就更容易保持一致。

---

4. scripts：辅助脚本

有些 Skill 里面会有脚本。

这个点一开始我也觉得奇怪：

Skill 不是说明文档吗？为什么还会有 Python 或 Shell 脚本？

后来理解了，因为有些任务只靠文字不够稳定。

例如：

统计项目文件数量
检查目录结构
解析 JSON
校验 Markdown 格式
生成目录树
批量处理文件

这些事情让大模型纯靠文本推理并不合适，用脚本更稳定。

所以 Skill 可以包含脚本，让 Agent 在需要的时候调用。

这说明 Skill 不一定只是 Prompt，它可以是：

说明文档 + 示例 + 辅助脚本 + 执行规范

---

5. assets：资源文件

assets 可以放一些资源，比如：

截图
模板
图片
示意图
配置样例

如果 Skill 是用来做可视化、写文档、生成报告，assets 会比较有用。

---

6. LICENSE：开源协议

如果 Skill 放到 GitHub 上公开，最好带一个开源协议。

这样别人就知道能不能使用、修改、分发。

对于个人学习项目来说，常见的是 MIT 协议。

---

十、Skill 的渐进式加载

今天我觉得一个比较重要的点是：

Skill 不一定是一开始全部加载进上下文的。

如果一个 Agent 有很多 Skill：

项目分析 Skill
论文总结 Skill
日志排查 Skill
代码审查 Skill
简历优化 Skill
README 生成 Skill

如果每次对话都把所有 Skill 全部加载进去，会浪费大量 Token。

更合理的方式是渐进式加载。

大概流程是：

用户输入任务
  ↓
先匹配 Skill 的 name 和 description
  ↓
判断哪些 Skill 可能相关
  ↓
只加载相关 Skill 的 SKILL.md
  ↓
如果还需要，再读取 examples、scripts、assets

也就是说，Agent 不一定一开始就看完整个 Skill。

它可能先看到 Skill 的简介。

只有当任务相关时，才进一步读取完整内容。

这和前面学过的 RAG 有一点类似：

RAG 是按需检索知识
Skill 是按需加载能力说明

区别是：

RAG 检索的是知识内容
Skill 加载的是任务方法

---

十一、Agent 是怎么“使用” Skill 的？

Agent 使用 Skill，大致可以理解成三个阶段。

---

1. 判断是否需要 Skill

用户输入一个任务后，Agent 会先判断这个任务和哪些 Skill 相关。

例如用户说：

帮我看看这个项目怎么启动。

如果存在一个 project-quickstart Skill，那么它的描述可能正好匹配这个任务。

这时 Agent 就会认为：

当前任务适合使用项目分析 Skill

---

2. 读取 Skill 的规则

然后 Agent 会读取 Skill 中的内容，比如：

适用场景
执行流程
输出格式
注意事项
示例

这些内容会影响 Agent 后续怎么做。

比如 Skill 要求先看目录结构，那 Agent 就会优先分析目录，而不是直接猜项目怎么启动。

---

3. 按照 Skill 组织执行

最后 Agent 会结合当前任务、工具能力和上下文，按照 Skill 中的流程完成任务。

如果需要工具，就调用工具。

如果需要读取文件，就读取文件。

如果需要生成结构化结果，就按照 Skill 规定的格式输出。

所以 Skill 并不是替 Agent 完成任务，而是指导 Agent 完成任务。

---

十二、为什么 Skill 对 Agent 很重要？

我现在觉得 Skill 对 Agent 很重要，主要是因为 Agent 的问题不只是“能不能回答”，而是“能不能稳定做事”。

大模型本身很强，但它有几个问题：

容易输出不稳定
容易遗漏步骤
容易每次风格不同
复杂任务容易跑偏
对固定任务缺少长期沉淀

Skill 可以缓解这些问题。

它让 Agent 处理任务时有一套参考标准。

就像人做项目会有 SOP。

Skill 就有点像 Agent 的 SOP。

比如：

项目分析 SOP
日志排查 SOP
文档总结 SOP
代码审查 SOP
论文阅读 SOP

有了 Skill，Agent 就不只是临时发挥，而是可以基于已有方法执行。

---

十三、Skill 和“插件”是不是一回事？

我觉得不能简单等同。

插件通常更强调：

提供一个具体功能

比如浏览器插件、API 插件、工具插件。

而 Skill 更强调：

指导 Agent 完成某类任务

Skill 里面可以包含工具说明，也可以包含脚本，但它的重点不是“装了一个功能按钮”，而是“沉淀了一种任务处理方法”。

所以 Skill 更像是：

任务能力包

而不是传统意义上的插件。

---

十四、为什么有些 Skill 里还有代码？

这个问题今天也很关键。

有些 Skill 里面不只是 SKILL.md，还可能有：

.py
.js
.sh
.json
.yaml

这是因为有些任务需要实际计算或处理。

比如：

读取文件结构
检查格式
生成目录树
转换数据
校验配置
批量处理文本

如果完全靠模型生成，可能不稳定。

脚本可以把确定性的部分交给程序完成。

模型负责理解任务和组织结果。

脚本负责稳定执行具体操作。

这其实也符合 Agent 的思想：

模型负责决策
工具负责执行
Skill 负责任务规范

---

十五、我的 GitHub Skill 展示区

---

1. 我的 Skill 仓库地址

这里后面放 GitHub 链接：

GitHub 地址：https://github.com/ZYZ666-RGB/project-quickstart-skill

---

2. 仓库截图位置

---

4. SKILL.md 核心内容展示

5. 当前 Skill 的定位

我目前这个 Skill 可以先定位为：

用于帮助 Agent 快速理解一个项目，包括项目结构、技术栈、依赖文件、启动方式和常见问题。

它的意义不是说这个 Skill 已经非常完善，而是作为一个初版实践：

先把任务经验写出来
再上传到 GitHub
再根据使用过程持续迭代

这也符合 Skill 的特点。

Skill 本身不是一次写完就固定不变的。

它应该随着使用经验不断改进。

---

十七、我对 Skill 的进一步理解

今天学完 Skill 之后，我感觉它在 Agent 体系中的位置可以这样理解：

Prompt：告诉模型当前要做什么
Tool：让模型有能力执行动作
MCP：让工具接入更标准
RAG：让模型可以获取外部知识
Workflow：让任务流程可以被编排
Skill：把某类任务经验沉淀成可复用能力
Agent：根据任务进行理解、决策和执行

这里 Skill 起到的是“经验复用”的作用。

它不一定直接执行任务，但它会影响 Agent 怎么执行任务。

比如同样是分析项目：

没有 Skill 时，Agent 可能想到哪说到哪。

有 Skill 时，Agent 会更倾向于按照固定思路：

目录结构
依赖文件
启动入口
配置文件
核心模块
启动步骤
常见问题

这种输出会更稳定，也更像一个真正的任务执行流程。

---

十八、Skill 的本质：把隐性的经验显性化

我觉得今天最重要的一句话是：

Skill 的本质，是把隐性的经验显性化。

很多任务其实我们知道怎么做，但没有写下来。

比如分析一个 Spring Boot 项目，我会下意识看：

pom.xml
application.yml
启动类
controller
service
config
docker-compose.yml
README.md

这些就是经验。

如果把这些经验写进 Skill，Agent 就可以复用。

所以 Skill 不是凭空创造能力，而是把已经总结出来的方法交给 Agent。

这也是为什么 Skill 很适合持续积累。

今天写第一版，后面发现问题再修改。

慢慢地，Skill 会从简单说明变成真正有价值的能力模板。

---

十九、今天的学习总结

今天主要理解了 Skill 这个概念。

我现在可以这样总结：

Skill 是 Agent 的可复用任务能力包。
它把某一类任务的处理方法、执行流程、示例、约束和辅助脚本组织起来，
让 Agent 在遇到类似任务时可以按照已有经验稳定执行。

它和之前学过的概念关系如下：

Function Calling：让模型学会调用函数
Tool Use：让 Agent 可以使用工具
MCP：让外部工具标准化接入
RAG：让 Agent 可以检索外部知识
Workflow：让任务按流程执行
Skill：让任务经验可以复用

Skill 最吸引我的地方在于：

它可以把平时学习和实践中积累的方法沉淀下来，变成以后可以持续复用的 Agent 能力。

这也让我对 Agent 工程有了更进一步的理解。

Agent 不只是模型调用工具，也不只是接入知识库。

更重要的是，要把任务经验、执行流程、工具使用方式和输出规范组织起来。

而 Skill 正是这种组织方式的一种体现。

---

二十、结尾

从前面学习 Function Calling、MCP、RAG，到今天理解 Skill，我对 Agent 的认识越来越清晰。

Agent 的能力不是单点能力，而是由多个部分组合出来的：

模型理解任务
工具执行动作
知识库补充信息
上下文维持状态
流程控制执行步骤
Skill 沉淀任务经验

今天学习的 Skill，让我意识到：

真正好用的 Agent，不只是能调用工具，还应该能复用经验。

后面我准备继续完善自己的 GitHub Skill，把它从一个简单的初版说明，逐渐整理成一个结构完整、可持续迭代的 Agent 能力包。

这也算是我学习 Agent 工程过程中的一次实践沉淀。