什么是 Agent Skills？从上下文“失忆”到技能系统

最近，不少主流 AI 开发工具都开始支持 Agent Skills（技能）。

社交媒体、视频平台上关于“技能”“Skill 文件夹”“skill.md”的讨论也越来越多，但很多人看了一圈，还是一头雾水：

• Agent Skills 到底解决什么问题？
• skill.md 为什么这么重要？
• 它和以前的提示词、MCP、Slash 命令有什么本质区别？

这篇文章不讲太多概念堆砌，沿着一个真实的开发场景，把 Agent Skills 讲清楚：

它从哪来、长什么样、怎么用、适合谁。

一、从最普通的一次对话说起

先把脑子里对“技能”的所有定义暂时清空，回到最原始的场景：

你只是想用一个 AI 编程工具（比如 Cloud Code 类的东西），帮你写前端页面。

这时只涉及三件事：

1. AI 编辑工具本身

• 提供界面和基础提示词（system prompt）
• 负责和大模型通信、管理文件、展示代码

2. 上下文（Context）

• 记录你和 AI 的历史对话
• 让大模型“记住”你之前说过的话

3. 大模型

• 根据上下文和当前问题输出代码或文本

你对 AI 说：“帮我做一个儿童服装网站的首页。”

AI 很听话，给你了一版代码。

但你一看：界面不太美观、颜色奇怪、间距不舒服。

于是你追加要求：

• 不要蓝紫色界面
• 不要用 emoji，当成 icon
• 尽量用 SVG 图标
• 调整间距、字体大小等等

AI 再改一版，效果好了不少。

但你心里清楚：这套要求下次还得再说一遍。

二、上下文的硬瓶颈：记不住才是常态

很多人以为“上下文很长就行了”。

其实上下文有两个硬问题：

1. 长度有限

• 比如一个编辑器最多给模型塞 1000 条信息
• 超过之后要么丢掉最早的，要么做“压缩”
• 一压缩，你精心写的设计规范可能从 2000 字变成 300 字

2. 压缩不可控

• 系统会自动总结历史对话
• 很可能把你具体的颜色规范、间距要求统统“概括”掉了

结果就是：

• 第一次你和 AI 一起打磨了很久，终于调出一套满意的设计规范
• 换一个新页面（比如产品列表页），你想复用那套规范
• AI 已经“忘了”，或者只记得一个模糊版

你只好又来一遍：

“颜色不要蓝紫色，图标用 SVG，不要 emoji，间距照上次那套……”

时间一长，你会很自然地问一句：

有没有办法，让 AI 永远记住这套规范，只在需要时读一遍，而不是每次我都从头讲？

Agent Skills，基本就是为了解决这个问题诞生的。

三、Skill 是什么？本质上就是“可复用的封装”

用一个尽量不装的说法：

Skill 就是对一段固定流程和知识的封装。

在传统编程世界里，我们会把一段常用逻辑写成函数或模块。

在 Agent 世界里，我们把一段常用「提示词 + 资源 + 工作流」写成一个 Skill。

典型的 Skill 文件夹，大致长这样：

my-skill/

├── skill.md # 必须存在：技能“说明书”

├── design.md # 设计规范（可选，多份）

├── style.csv # UI 风格数据表（可选）

├── script.py # 辅助脚本（可选）

└── assets/ # 其他资源（可选）

其中 skill.md 是核心，里面至少要包含两件事：

1. 元数据（Metadata）

• name：技能名字（一般建议用英文）
• description：一句话说明什么时候应该用这个技能、它能干什么

2. 指令（Instructions）

• 用自然语言写给大模型看的“说明书”
• 告诉它在什么场景下，按什么步骤读取哪些文件，如何执行脚本

AI 编辑器会在每次对话时：

• 自动把所有技能的 name + description 加载进系统提示词
• 它们非常短，基本不占什么 Token
• 不会被上下文压缩和丢弃

这样一来，即使你聊了一大堆别的内容，

模型始终知道：

“这里有一个叫 frontend-design 的技能，是用来做网页 UI 设计的。”

当你下次说：“帮我做一个科技风的产品主页。”

模型会主动想起：

“这好像可以用 frontend-design 这个技能。”

然后它会请求编辑器：“把这个技能的 skill.md 内容发给我。”

编辑器再把对应的说明书和后续引用的 design.md、csv、脚本，按需塞进上下文。

四、渐进式加载：Skill 真正厉害的地方

上面这个过程，有两个关键点：

1. 触发式加载（Trigger-based）

• 一开始，上下文里只有各个技能的名字和描述
• 当模型判断“这个需求可以用某个技能解决”时，才要求加载 skill.md

2. 按需加载（On-demand）

• skill.md 本身还可以引用更多文件，比如：
• design.md：详细设计规范
• tech-style.md / minimal-style.md：不同风格
• ui_styles.csv：各种细粒度 UI 组件表
• script.py：搜索 / 过滤样式的脚本
• 模型只在需要时，才让编辑器把这些文件逐个加载进上下文

这套机制有个专业名字：渐进式披露（Progressive Disclosure）。

它解决了两个老大难问题：

• 不再需要把所有规范一次性塞进上下文，减少 Token 浪费
• 不怕上下文压缩，把关键的“入口信息”（技能元数据）永远放在系统提示里

换句话说：

你不再需要每次从零开始“调教”大模型，而是让它学会主动“翻技能手册”。

五、从“网页设计 Skill”看技能的进化

回到一开始的 UI 设计例子，我们看一下 Skill 是怎么慢慢长大的。

1. 最初版本

• 一个 skill.md 写死所有规则：
• 不用蓝紫色
• 不用 emoji
• 用 SVG
• 标题字号、段落间距、按钮样式……全写进去

2. 第二阶段：按风格拆分

• 发现一个文件越写越长，维护困难，也浪费 Token
• 就把风格拆出来：
• minimal.md 简约风
• tech.md 科技风
• fresh.md 小清新
• skill.md 里只写规则：
• “要简约风就读 minimal.md，要科技风就读 tech.md……”

3. 第三阶段：结构化 + 脚本化

• 再往后，你想让按钮、段落、图表、图标这些细节更好维护
• 于是用 CSV 表管理 UI 元素，并写一个 Python 脚本做检索
• 在 skill.md 里写清楚流程：
• 第一步：根据用户描述决定用哪个 CSV
• 第二步：调用 script.py 检索具体样式
• 第三步：按检索结果生成页面

这时，一个 Skill 不只是提示词片段，而是一套完整的工作流定义：

• 包含说明书
• 包含资源
• 包含代码
• 由大模型驱动执行流程

这样的 Skill，已经能在 GitHub 上收获上万 Star，被实际用于 Cloud Code、各类智能体中。

六、Skill、MCP、Slash 命令，到底差在哪？

不少人看完官方文档之后，反而更晕了：

• MCP 是什么？
• Mini / Slash 命令又算什么？
• 有了 Skills 之后，还需要 MCP 吗？

如果你已经用过一段时间，会发现它们有一个共同点：

本质上都是提示词工程 + 外部能力封装。

可以粗略这么类比：

1. Skill：Agent 自身能力的“本地模块”

• 重点是：
• 复用高频流程
• 优化上下文使用
• 给特定 Agent 加“专长”
• 既可以只包含提示词，也可以引用脚本、外部服务

2. MCP：对外部服务的“连接器”

• 更偏向于：
• 访问数据库
• 调用 GitHub / 飞书 / Notion 等 SaaS 服务
• Skills 里完全可以通过脚本去调用 MCP，二者是可以叠加的

3. Slash 命令 / Mini 工具：交互层的快捷入口

• 用户通过 /xx 触发特定流程
• 可以看作是对某些 Skill / 工具的“前端封装”

从工程视角看，Skill 更像是你给智能体写的一组“内置模块”：

• 逻辑清晰
• 粒度可控
• 方便版本管理和复用

很多情况下，你完全可以先用 Skills，把自己的常用流程封装好，再根据需要少量使用 MCP。

七、哪些场景适合做成 Skill？怎么动手？

判断一个东西适不适合做成 Skill，有一个简单标准：

是不是高频、繁琐、流程化，而且你已经很熟悉？

例如：

• 每个项目都要做的 代码 Review 流程
• 各类项目通用的 需求梳理 / PRD 模板
• 自媒体创作者的 选题 → 提纲 → 撰稿 → 改稿 工作流
• 日报、周报、PPT 模板生成规则
• 数据分析项目的 数据清洗 → 特征检查 → 报表生成 流程

不太建议一上来就做：

• “万能 Skill”
• 又写前端，又写后端，还管产品，还生成视频脚本

一来 skill.md 太长，会拖垮上下文；

二来模型在选择、触发、执行时也会变得混乱。

官方的建议是：skill.md 文本尽量控制在 500 行以内，

保持单一职责，粒度适中。

真正值得做的，是那些你每天都在重复、你自己已经非常熟悉的流程。

八、安全和风险：脚本是双刃剑

只要 Skill 里出现脚本，就一定要考虑安全问题。

潜在风险包括：

• 读取本地敏感文件
• 未经确认地执行危险命令
• 发起外部网络请求，泄露信息

几个最基本的建议：

1. 只用可信来源的公共 Skill

• 例如 GitHub 上 Star 数量高、被很多人使用和审计的项目

2. 让大模型帮你做一次静态分析

• 把脚本内容发给模型，让它指出可能的危险点

3. 在最小权限环境里运行

• 容器、沙盒、只读文件系统等
• 明确划定 Skill 允许访问的目录和接口范围

Skill 带来的效率提升，和安全边界，永远是绑定在一起的。

使用AI算力可以上 晨涧云AI算力平台 租用GPU，体验高效易用的云算力服务。

九、结语：不要焦虑，“有流程才有技能”

最后想强调一点：

没有技能，你一样可以写代码、做项目。

Skills 只是一个工程化演进的结果，它出现的原因很简单：

• 上下文长度有限
• 提示词会被压缩、丢失
• 人不想总重复讲同一套东西

如果你现在的工作和生活中，还没有总结出清晰的流程，

那就不用强行给自己加“学习技能”的焦虑。

先把自己的流程梳理清楚，写成文档，

当你发现自己在对 AI 说同一套话第 N 遍时，

那就是该把它封装成 Skill 的时候了。