Agent Skills 是什么
Agent Skills 可以理解成给 AI Agent（智能体）准备的一个“技能包”。
它不是一句简单的 Prompt（提示词），也不是聊天框里临时补充的一段要求，而是一组放在目录里的结构化文件。这个目录告诉 AI：遇到某类任务时，应该读取哪些规则、参考哪些资料、使用哪些模板，必要时还可以运行哪些脚本。
一个典型的 Skill 目录大概长这样：
meeting-skill/
├── SKILL.md # 技能的元数据和核心执行说明
├── scripts/ # 可选：辅助执行任务的脚本
├── references/ # 可选：参考文档、规范、示例
└── assets/ # 可选：模板、样式文件、固定输出资源
其中最重要的是 SKILL.md。它通常包含两部分：
- 元数据：例如
name、description，用于让 Agent 判断什么时候该使用这个技能。 - 执行说明：告诉 Agent 具体怎么完成任务、输出什么格式、遵守哪些限制。
可以把 Agent Skills 看成：
一份可复用的任务说明书，加上一组配套资源，让 AI 在处理固定类型任务时不需要每次重新学习规则。
它解决的核心问题不是“让 AI 更聪明”，而是让 AI 在重复任务里更稳定、更容易维护、更像一个可组合的工程模块。
Agent Skills 和结构化 Prompt 的关系
很多人第一次看到 Skills，会觉得它像以前写过的结构化 Prompt。这个判断是对的。
过去为了让 AI 按预期工作，经常会把 Prompt 写成这种结构：
角色：你是一名会议纪要整理专家。
背景：用户会提供一段会议记录，可能包含口语化表达、重复内容和无关闲聊。
任务：请提取会议主题、关键结论、待办事项和负责人。
约束：
- 不要编造会议中没有出现的信息
- 输出必须简洁
- 行动项必须包含负责人和截止时间；如果没有提到，就标记为“未说明”
输出格式：
使用 Markdown 表格输出行动项。
这种写法本质上已经在做“技能定义”了，只是它还停留在一次性使用的阶段。每次遇到类似任务，都要复制、修改、粘贴一遍。
Agent Skills 把这件事文件化、模块化了。
| 对比项 | 结构化 Prompt | Agent Skills |
|---|---|---|
| 存放位置 | 聊天输入框或业务流程中 | 独立目录和文件 |
| 使用方式 | 每次手动输入或拼接 | Agent 按任务自动匹配 |
| 复用能力 | 依赖复制粘贴 | 可以被多个任务调用 |
| 维护方式 | 分散在不同对话或代码里 | 集中维护 SKILL.md 和资源文件 |
| 可扩展性 | 主要靠文字说明 | 可以配合参考资料、模板、脚本 |
| 适合场景 | 临时任务、一次性需求 | 高频任务、标准流程、团队规范 |
所以，Agent Skills 可以看成是工程化后的结构化 Prompt。区别不在于“写法完全不同”，而在于它从临时输入变成了可维护资产。
为什么需要把 Prompt 做成 Skill
如果只是偶尔问 AI 一个问题，直接写 Prompt 足够了。但当任务开始变得高频、复杂、需要统一格式时，单靠聊天框会遇到几个明显问题。
规则会反复复制
例如每次让 AI 整理会议纪要，都要提醒它：
- 提取会议主题
- 区分结论和待办
- 不要编造负责人
- 用 Markdown 表格输出
- 缺失信息要标注“未说明”
这些规则如果每次都手动输入，不仅麻烦，还容易漏掉。
Prompt 容易散落在不同地方
一个团队里可能有很多版本的“会议总结 Prompt”“文章改写 Prompt”“客服回复 Prompt”。它们分布在聊天记录、文档、代码、自动化工具里，时间久了很难判断哪个才是最新版本。
输出质量受当次输入影响很大
如果某次 Prompt 写得详细，输出就好一些；某次少写了几条限制，结果就可能跑偏。Agent Skills 的价值就在于把稳定规则沉淀下来，让任务质量不完全依赖每一次临时输入。
复杂任务需要拆成模块
一个完整的 AI 工作流往往不止一步。比如生成一份行业分析报告，可能包含：
flowchart LR
A[理解用户问题] --> B[整理资料]
B --> C[提取关键观点]
C --> D[生成报告正文]
D --> E[校对格式和引用]
如果所有规则都塞进一个超长 Prompt，维护成本会很高。把任务拆成多个 Skills 后，每个技能只负责一类事情，组合起来更清晰。
Agent Skills 的工作机制
Agent 使用 Skills 时，通常不会一开始就加载所有文件。更常见的方式是：先读取每个技能的 name 和 description，判断当前任务和哪个技能最匹配；匹配成功后，再加载对应的完整说明和资源。
这个过程可以用一张流程图表示：
flowchart TD
A[用户提交任务] --> B[Agent 扫描可用 Skills]
B --> C[读取 name 和 description]
C --> D{是否匹配当前任务}
D -- 否 --> E[继续寻找其他 Skill]
D -- 是 --> F[加载 SKILL.md 完整说明]
F --> G[按需读取 references / assets]
G --> H{是否需要脚本辅助}
H -- 是 --> I[调用 scripts 中的脚本]
H -- 否 --> J[直接执行任务]
I --> K[生成结果]
J --> K
K --> L[返回给用户]
这里有一个关键点：name 和 description 不是装饰字段，而是技能能否被唤醒的入口。
如果一个技能叫 skill-1，描述写成“处理文字”，Agent 很难判断它到底适合会议纪要、文章改写、客服话术，还是合同摘要。
更好的写法应该明确任务对象、使用场景和能力边界，例如：
name: meeting-summary
description: 将会议记录、会议录音转写文本整理成结构化会议纪要，提取议题、关键决定、行动项、负责人和截止时间。
这种描述能让 Agent 在看到“会议记录”“会议纪要”“行动项”等任务时更容易选中它。
一个完整的会议纪要 Skill 示例
假设要做一个专门整理会议纪要的 Skill，可以创建这样的目录：
mkdir -p meeting-skill/references
mkdir -p meeting-skill/assets
mkdir -p meeting-skill/scripts
touch meeting-skill/SKILL.md
目录结构如下：
meeting-skill/
├── SKILL.md
├── references/
│ └── meeting-rules.md
├── assets/
│ └── meeting-template.md
└── scripts/
编写 SKILL.md
SKILL.md 可以这样写：
---
name: meeting-summary
description: 将会议记录、会议录音转写文本整理成结构化会议纪要，提取议题、关键决定、行动项、负责人和截止时间。
---
# 会议纪要整理技能
## 适用任务
当用户提供会议记录、会议转写文本、会议草稿，或要求整理会议纪要、提取行动项时，使用该技能。
## 处理原则
- 保留会议中的真实信息，不补充未出现的结论。
- 删除寒暄、重复表达和无关闲聊。
- 将口语化内容改写成简洁、正式的书面表达。
- 如果负责人、截止时间、决策依据没有在材料中出现，标记为“未说明”。
- 不把讨论中的假设当成已经确定的结论。
## 输出结构
请使用以下 Markdown 结构输出：
```markdown
# 会议纪要
## 基本信息
| 项目 | 内容 |
|---|---|
| 会议主题 | |
| 会议时间 | |
| 参会人员 | |
## 议题摘要
- 议题 1：
- 议题 2：
- 议题 3：
## 关键决定
| 决定 | 依据 | 影响范围 |
|---|---|---|
## 行动项
| 事项 | 负责人 | 截止时间 | 备注 |
|---|---|---|---|
## 风险与待确认问题
-
质量检查
输出前检查：
- 行动项是否都有负责人；没有则写“未说明”。
- 截止时间是否来自会议记录；没有则写“未说明”。
- 是否把讨论过程和最终决定区分开。
- 是否存在自行补充的事实；如果有，删除。
这个文件已经包含了一个可用 Skill 的核心信息：什么时候用、怎么处理、输出成什么样、质量检查什么。
---
## 加入参考资料和模板
如果会议纪要还有内部规范，可以放进 `references/meeting-rules.md`：
```markdown
# 会议纪要规范
## 决定项写法
决定项必须满足：
- 已经在会议中达成一致
- 不使用“可能”“大概”“倾向于”这类不确定表达
- 能明确影响的产品、项目或流程
## 行动项写法
行动项必须包含：
- 要做什么
- 谁负责
- 什么时候完成
- 是否需要其他人配合
如果输出格式长期固定，可以放进 assets/meeting-template.md：
# 会议纪要
## 基本信息
| 项目 | 内容 |
|---|---|
| 会议主题 | |
| 会议时间 | |
| 参会人员 | |
## 关键结论
-
## 行动项
| 事项 | 负责人 | 截止时间 | 状态 |
|---|---|---|---|
这样做的好处是：SKILL.md 负责定义行为，references 负责补充知识，assets 负责存放固定资源。职责分开后，后续修改会轻很多。
Agent 调用 Skill 时发生了什么
当用户输入：
帮我把这段会议记录整理成纪要，并列出行动项。
Agent 的处理过程大致如下：
sequenceDiagram
participant U as 用户
participant A as Agent
participant S as Skills 索引
participant M as meeting-summary
participant R as references/assets
U->>A: 提交会议记录整理任务
A->>S: 查询可用 Skills 的 name 和 description
S-->>A: 返回 meeting-summary 等技能信息
A->>A: 判断 meeting-summary 与任务最匹配
A->>M: 加载 SKILL.md
A->>R: 按需读取会议规范和模板
A->>A: 按技能说明整理内容
A-->>U: 返回结构化会议纪要
用户不需要每次重复写“请提取行动项”“请用表格输出”“不要编造负责人”。这些规则已经写进 Skill，Agent 只要匹配到任务，就会按技能说明执行。
name 和 description 怎么写才容易被调用
很多 Skill 失效，不是因为执行说明写得差，而是因为元数据太模糊。Agent 在选择技能时，通常会先看 name 和 description，所以这两个字段要像搜索关键词一样准确。
| 写法 | 问题 | 更好的写法 |
|---|---|---|
name: skill-1 | 完全看不出用途 | name: meeting-summary |
description: 处理文字 | 范围太大，匹配困难 | description: 将会议记录整理成结构化会议纪要，提取决定项、行动项、负责人和截止时间。 |
description: 写内容 | 没有说明场景 | description: 将长文章改写成适合小红书发布的短文案，包含标题、正文、标签和表情符号。 |
description: 分析数据 | 不知道分析什么数据 | description: 分析 CSV 销售数据，生成趋势摘要、异常点说明和可视化建议。 |
一个好的 description 通常包含三类信息：
任务对象 + 处理动作 + 输出目标
例如：
description: 将用户访谈记录整理成产品需求洞察，提取用户痛点、使用场景、需求优先级和可验证假设。
这里的任务对象是“用户访谈记录”，处理动作是“整理成产品需求洞察”，输出目标是“痛点、场景、优先级、假设”。Agent 更容易判断这个技能该在什么场景下使用。
Skill 应该拆多细
Skill 不是越大越好。一个技能如果同时负责写作、查资料、做表格、生成代码、检查错别字，就会变得难以匹配，也难以维护。
更合理的拆法是按任务边界划分。
| 拆分方式 | 示例 | 适合程度 |
|---|---|---|
| 按任务对象拆 | 会议纪要、用户访谈、行业报告 | 适合 |
| 按输出格式拆 | Markdown 报告、JSON 摘要、表格清单 | 适合 |
| 按业务流程拆 | 需求分析、内容生成、质量检查 | 适合 |
| 按模糊能力拆 | 写作能力、分析能力、办公能力 | 不太适合 |
| 把所有规则塞进一个 Skill | all-in-one-assistant | 不太适合 |
一个可维护的 Skill 通常满足三个条件：
- 能用一句话说清它解决什么任务。
- 触发场景比较明确。
- 输出结构和质量标准能写清楚。
如果一个 Skill 的 description 需要写很长才能解释清楚，往往说明它该拆了。
Skills、工具和插件不是一回事
Agent Skills 容易和工具、插件混在一起，但它们的定位不一样。
| 类型 | 核心作用 | 例子 |
|---|---|---|
| Prompt | 给 AI 的一次性指令 | “请把这段文字总结成三点” |
| Skill | 可复用的任务说明书和资源包 | 会议纪要 Skill、文章改写 Skill |
| Tool | 可被调用的具体能力 | 搜索网页、查询数据库、运行代码 |
| Plugin | 接入外部系统的扩展 | 连接日历、CRM、工单系统 |
Skill 主要告诉 Agent“如何完成一类任务”。Tool 主要提供“能执行某个动作的能力”。一个 Skill 内部可以要求 Agent 使用某个工具，也可以附带脚本辅助处理，但 Skill 本身不等于工具。
例如会议纪要 Skill 可以这样组合：
flowchart LR
A[会议纪要 Skill] --> B[读取会议记录]
A --> C[参考会议规范]
A --> D[调用转写工具]
A --> E[使用固定模板]
E --> F[生成纪要]
Skill 像操作手册，工具像具体设备。手册规定什么时候用设备、怎么用、结果怎么验收。
什么场景适合使用 Agent Skills
不是所有 AI 任务都需要做成 Skill。判断标准很简单：这个任务是否会反复出现，是否需要稳定输出，是否有明确流程。
| 场景 | 是否适合做成 Skill | 原因 |
|---|---|---|
| 会议纪要整理 | 适合 | 高频、格式固定、规则明确 |
| 客服回复改写 | 适合 | 需要统一语气和边界 |
| 长文章改写成固定平台风格 | 适合 | 输出结构和风格可标准化 |
| 代码审查清单 | 适合 | 可以沉淀检查项 |
| 偶尔问一个概念 | 不太适合 | 临时 Prompt 更轻 |
| 开放式头脑风暴 | 不太适合 | 规则过多会限制发散 |
| 一次性私人任务 | 不太适合 | 维护 Skill 的成本高于收益 |
如果一个任务每周都会做，而且每次都要重复强调同一批规则，就可以考虑把它沉淀成 Skill。
常见坑
元数据写得太泛
不要写：
name: writing
description: 帮助用户写作。
这种描述太宽，任何写作任务都可能匹配，也可能完全不匹配。
更具体的写法是：
name: technical-blog-rewrite
description: 将技术资料改写成结构清晰的中文技术博客，包含概念解释、流程图、代码示例、对比表格和注意事项。
执行说明只写目标，不写标准
不要只写：
请输出高质量会议纪要。
“高质量”无法执行。应该拆成可检查的规则：
- 必须区分“讨论内容”和“最终决定”。
- 行动项必须包含事项、负责人、截止时间。
- 如果会议记录没有给出负责人或截止时间，写“未说明”。
- 不要补充会议中没有出现的信息。
一个 Skill 包含太多任务
如果一个 Skill 同时处理会议纪要、产品需求、文章改写和数据分析，Agent 很难判断什么时候该调用它。更好的方式是拆成多个小技能：
meeting-summary/
user-research-insight/
technical-blog-rewrite/
sales-data-analysis/
把参考资料全塞进 SKILL.md
SKILL.md 应该保持清晰，重点写触发条件、执行步骤和输出规范。大量背景资料、样例、模板更适合放到 references 或 assets 里。
推荐结构：
customer-service-skill/
├── SKILL.md
├── references/
│ ├── tone-guide.md
│ └── forbidden-responses.md
└── assets/
└── reply-template.md
这样后续只改语气规范时，不需要动核心技能说明。
设计一个 Skill 的检查清单
写完一个 Skill 后，可以用这张清单检查：
| 检查项 | 判断标准 |
|---|---|
| 名称是否清楚 | 看到 name 就能猜到用途 |
| 描述是否具体 | 包含任务对象、处理动作、输出目标 |
| 触发条件是否明确 | Agent 能判断什么时候该用 |
| 输出格式是否固定 | 有 Markdown、JSON、表格等明确结构 |
| 限制是否可执行 | 避免“高质量”“专业”这类空泛要求 |
| 是否拆分合理 | 一个 Skill 只负责一类任务 |
| 参考资料是否独立 | 长资料放入 references |
| 模板是否独立 | 固定输出样式放入 assets |
| 是否有质量检查 | 输出前有明确校验规则 |
如果这些问题都能回答清楚，一个 Skill 基本就具备了可复用价值。
小结
Agent Skills 的本质，是把临时 Prompt 变成可复用、可维护、可组合的任务模块。
它并不神秘，核心就是一个结构化目录：SKILL.md 写清元数据和执行规则，references 放参考资料，assets 放模板资源，scripts 放可选脚本。Agent 通过 name 和 description 判断什么时候调用技能，再按技能中的说明完成任务。
当 AI 任务从“偶尔聊一下”变成“长期稳定生产”时，Skills 的价值会变得明显：规则不用反复复制，输出格式更稳定，任务流程也更容易拆分和维护。