每次让 AI 整理会议纪要，都得重新说一遍：去掉口头禅、按主题归类、列出负责人和截止时间，不确定的信息不能瞎编。
等到下一次换一份会议记录，同样的要求只能再写一遍。如果团队里有五个人，那每个人还可能写出五种不同版本的提示词。
说到底，这类任务真正缺的，不是一条更长、更复杂的临时指令，而是一套能保存、能复用、还能持续改进的工作方法。
其实，Agent Skill 就是专门用来承载这套工作方法的。
Skill 不是给模型增加了新的参数
根据 Anthropic 官方 Skills 仓库的定义，Skill 是一组由 Agent 动态加载的说明、脚本和资源，目的是提高特定任务的执行效果。它不会重新训练模型，也不会修改模型参数。
本质上，一个 Skill 就是一个目录，里面保存了某类任务的核心要素：
- 触发条件
- 执行步骤
- 输出格式
- 质量标准
- 参考资料
- 可执行脚本
- 模板和其他资源
举个例子，一个会议纪要 Skill 可以这样告诉 Agent：
收到会议文字稿→ 清理停顿词和无关内容→ 识别会议主题→ 按主题归并观点→ 提取结论和行动项→ 按固定格式输出
模型本身就有总结文本的能力，Skill 真正解决的是“应该按照什么专业流程来总结，以及什么样才算合格”。
最小 Skill 只有一个 SKILL.md
按照 Agent Skills 的规范，一个 Skill 最少只需要包含一个 SKILL.md 文件：
meeting-minutes/└── SKILL.md
这个 SKILL.md 由两部分组成：
---name: meeting-minutesdescription: 会议纪要生成器。当用户提供会议文字稿或录音转写，需要整理成结构化会议纪要时使用。---# 会议纪要生成器根据用户提供的会议文字稿，生成结构化会议纪要。## 工作流程1. 通读全文，清理无关内容2. 按主题整理会议内容3. 提取会议结论和行动项4. 按固定模板输出
--- 包围的是 YAML Frontmatter，下面则是 Markdown 格式的任务说明。在这个最小结构里，name 和 description 是必填字段。
name 是 Skill 的稳定标识
name 用来标识 Skill。规范要求它使用小写字母、数字和连字符，并且要与所在文件夹的名称保持一致。
name: meeting-minutes
下面这些名称就不太适合当作标准的 Skill 名称：
name: Meeting Minutesname: meeting_minutesname: -meeting-minutes
名称不必解释全部功能，只需要简短、稳定、可识别。真正决定 Skill 在什么时候被使用的，其实是 description。
description 决定 Skill 何时触发
Agent 不会等着用户准确说出 Skill 的名称才去调用它。用户可能会说：
帮我整理会议纪要总结一下这个会议把录音转写整理成会议记录提取会议里的待办事项
这些表达方式各不相同，但指向的都是同一类任务。所以 description 需要同时说明两件事：
这个 Skill 能做什么什么情况下应该使用
会议纪要 Skill 的描述可以这样写：
description: 会议纪要生成器。当用户提供会议文字稿、录音转文字或会议记录，需要整理成结构化会议纪要时使用。只要涉及将会议对话转化为结构化纪要的任务，都应使用此技能。
如果只写个“帮助处理会议”，Agent 就很难判断“安排会议时间”“创建会议链接”和“生成会议纪要”到底该不该触发它。描述写得太窄，该用时可能找不到；写得太宽泛，又会与其他 Skill 产生冲突。
正文保存专业任务的执行方法
YAML 层解决的是“什么时候用”，Markdown 正文则负责回答“触发以后怎么做”。
会议纪要 Skill 首先会要求清理原始转写中的噪音：
### 第一步：通读全文，清理无关内容- 停顿词和口头禅：如“嗯”“啊”“那个”“然后呢”- 与会议无关的闲聊- 同一观点的重复表达- “听得到吗”“信号不好”等技术性中断保留所有有实质内容的讨论、观点、决策和行动项。
接着会规定输出结构：
## 会议纪要### 一、会议基本信息### 二、会议目标### 三、会议内容### 四、行动项
最后还要设置质量边界：
1. 不确定的信息直接留空，不要编造2. 分散在不同时间点的同类讨论应归入同一主题3. 主要观点尽量标注发言人4. 行动项包含负责人、任务描述和截止时间5. 使用简洁的要点和表格，不写大段流水账
这样一来，保存下来的就不只是一个输出模板，还包括专业人员在处理会议材料时使用的判断规则。
Agent 为什么不把所有 Skill 一次性读完？
一个 Agent 可能同时安装几十甚至上百个 Skill。如果每次对话都把所有的说明、脚本和参考资料塞进上下文，不仅会消耗大量 Token，还会让无关的规则干扰当前任务。
Agent Skills 采用的是渐进式加载：
第一层：name + description启动时用于发现和判断 Skill第二层：SKILL.md 正文确认任务匹配后加载完整流程第三层：references、scripts、assets执行到相关步骤时按需读取或运行
举个例子，用户问“今天北京天气怎么样”，Agent 只需要看到 meeting-minutes 的名称和描述，就能判断它跟任务无关，完全不必加载整套会议纪要模板。只有当用户提供了会议文字稿并要求生成纪要时，Agent 才会读取完整的 SKILL.md。
这种方式同时解决了两个问题：既让 Agent 能拥有更多专业技能，又避免了每次任务都携带全部技能内容。
复杂 Skill 不只有一个 Markdown 文件
任务变复杂以后，可以在 Skill 目录里加入更多资源：
skill-name/├── SKILL.md├── scripts/├── references/└── assets/
各个目录适合承载不同的内容：
| 目录 | 作用 | 示例 |
|---|---|---|
scripts/ |
执行确定、重复的处理步骤 | 文件转换、数据校验、生成报告 |
references/ |
保存需要按需查阅的知识 | 接口说明、业务规范、格式规则 |
assets/ |
保存最终交付需要使用的资源 | HTML 模板、图片、字体、文档模板 |
SKILL.md 应该负责说明整体流程，并且明确在什么情况下读取哪个文件。如果把所有资料都堆进主文件，Skill 一触发就要加载全部内容，那渐进式加载也就失去意义了。
Skill 不只是“保存下来的 Prompt”
把 Skill 理解为“一个存起来的 Prompt”可以帮助入门，但这个说法并不完整。简单 Skill 的核心可能确实只有一段结构化指令，但复杂 Skill 还可以包含脚本、参考资料、模板和评测用例，并且能够随着项目一起进行版本管理。
更准确的理解是：
Prompt：本次任务的指令Skill：一类任务可复用的执行手册和配套资源
Prompt 可能告诉 Agent“生成一份会议纪要”，而 Skill 则负责回答：哪些内容应该删除？哪些信息必须保留？怎样识别会议结论？行动项包含哪些字段？信息缺失时怎么处理？最终使用什么结构交付？
Skill、Memory、MCP 和 Tool 有什么区别？
这几个概念经常同时出现在 Agent 应用中，但它们解决的问题不同。
| 能力 | 解决的问题 | 会议纪要场景 |
|---|---|---|
| Prompt | 用户这一次要做什么 | “整理这份会议文字稿” |
| Memory | Agent 应该长期记住什么 | 团队名称、用户偏好、固定术语 |
| MCP | 如何标准化连接外部系统 | 连接云盘、文档系统或数据库 |
| Tool | Agent 可以执行什么操作 | 读取录音文件、保存纪要 |
| Skill | 这类任务应该怎样专业完成 | 清洗、归类、提取行动项、套用模板 |
MCP 和 Skill 并不是互相替代的关系。
MCP / Tool 提供“能做什么”Skill 提供“应该怎么做”
举个例子，MCP 可以让 Agent 读取企业文档库，而会议纪要 Skill 则指导 Agent 如何处理读取到的转写内容。一个提供连接与操作能力，一个提供稳定的专业流程。
什么任务值得封装成 Skill？
适合创建 Skill 的任务通常具备以下特点：
- 会反复执行
- 处理步骤相对稳定
- 对输出格式有明确要求
- 存在容易遗漏的质量标准
- 团队成员需要使用同一套规则
- 结果可以通过案例或断言进行验证
会议纪要、AI 日报、代码评审、周报生成和品牌文档制作都符合这些特征。
至于下面这些情况，就不一定需要创建 Skill了：
- 只会执行一次的临时问题
- 没有稳定流程的开放式讨论
- 用一句简单 Prompt 就能稳定完成的任务
- 规则仍在频繁变化、还没有形成共识的工作
Skill 的目标不是把所有对话都变成流程，而是把那些真正稳定、重复、有专业要求的部分沉淀下来。
从重复任务开始创建第一个 Skill
一个可行的创建顺序是：
找到反复出现的任务→ 明确输入与输出→ 写出专业处理步骤→ 创建 SKILL.md→ 准备几组真实测试任务→ 检查触发和输出效果→ 根据失败结果继续修改
写完文件并不代表 Skill 已经大功告成。description 可能没有覆盖真实用户的表达，正文流程可能遗漏了边界情况，固定模板也可能让某类会议丢失重要信息。只有用不同的测试用例反复验证，才能知道这个 Skill 是否真的比普通 Prompt 更稳定。
至于如何使用 skill-creator 创建会议纪要 Skill，并通过有 Skill 与无 Skill 的结果对比来完成评测和迭代，这些内容就放在下一篇继续实现了。
总结
Agent Skill 把完成一类专业任务所需的说明、脚本和资源组织在一个目录中，并根据用户意图动态加载。它的核心结构可以概括为：
name：它是谁description：什么时候使用SKILL.md 正文：触发以后怎样完成任务scripts / references / assets：执行过程中按需使用的资源
Skill 没有让模型凭空获得新知识，也没有替代 MCP 和 Tool。它只是把原本散落在聊天记录、个人经验和临时 Prompt 中的工作方法，变成了可复用、可维护、可评测的 Agent 能力。
参考资料
- Anthropic：Skills 官方 GitHub 仓库
- Agent Skills：Specification
- Anthropic Engineering：Equipping agents for the real world with Agent Skills
