Skill 能力封装：把任务方法沉淀成资产

第一次让 Agent 整理会议纪要，你要解释一堆要求：什么算结论、待办怎么提取、负责人缺失怎么处理、输出什么格式。第二次遇到类似任务，这些要求又要重新说一遍；换个同事、换个 Agent，再解释一次。

问题不在 Agent 不会，而在这套方法只存在于某次对话里——没被保存，也没变成可重复调用的能力。Skill 解决的就是这个问题。

一、Skill 是什么：给 Agent 的专业工作手册

Skill 把一类任务的说明、步骤、工具、参考资料和验收标准放在一起：遇到同类任务，Agent 先读这套方法，再按已验证的规则干活。它不改变模型参数，改变的是 Agent 每次干活时的"作业指导书"。

核心载体是 SKILL.md：开头用 YAML 元数据声明名称与使用场景，正文用 Markdown 写具体方法。以会议纪要 Skill 为例：

---
name: meeting-notes
description: 将会议转写稿、聊天记录或散乱笔记整理为结构化会议纪要。
  当用户要求提取会议结论、行动项或待确认问题时使用。
---
执行步骤：
1. 检查输入是否包含可识别的会议内容
2. 区分讨论意见、最终结论和未决问题
3. 提取行动项、负责人和截止时间
4. 无法确认的信息标记为"待确认"
5. 按规定模板输出，并与原始记录复核

name 和 description 是规范必填字段——description 写的是"什么时候用我"，它直接决定 Agent 能不能在正确的时候想起这个 Skill。

二、三层渐进加载：Skill 的运行机制

安装 Skill 后，系统不会把所有文件一股脑交给模型，而是：

1. 先提供所有已装 Skill 的名称和描述，模型据此判断哪些与当前任务相关；
2. 某个 Skill 被选中后，才加载它的 SKILL.md，模型照此检查输入、执行核心步骤；
3. 执行到特定环节，再按说明读取参考资料、套用模板或运行脚本。

大模型负责结合任务做判断，Skill 负责提供稳定方法，平台负责加载文件和调用工具——三层各司其职。渐进加载同时省上下文：不相关的 Skill 只占一行描述的成本。

三、边界辨析：Skill vs Prompt / 工作流 / MCP

Prompt 和 Skill 不是二选一：Skill 沉淀稳定方法，Prompt 说明本次材料和临时要求。工作流管多个节点的衔接编排（先后、分支、数据传递、失败去向）；MCP 管模型与外部工具的标准化连接。四者是互补层次，不是竞争方案。

四、什么任务值得沉淀成 Skill

**不是每条 Prompt 都值得做成 Skill。**判据：

• 同类任务反复出现、处理方法逐渐稳定 → 沉淀；
• 只做一次、目标还在变 → 先用 Prompt 跑通，等稳定再沉淀。

沉淀的判断口诀：当你发现自己在复述上次的同一套要求时，就是该做成 Skill 的时刻。

五、FDE 视角：Skill 是交付经验的容器

• 本平台的技能商店就是这套体系的工程化：SkillPackage 分发、版本台账、审批上架——你在这门课学的 SKILL.md 结构，就是上架技能包的素材格式；把客户现场验证过的方法写成技能包提交，团队所有人下次直接装；
• 驻场交接：把"我怎么干这个活的"写成 Skill 留在客户环境，移交质量立刻上一个台阶（呼应交付工程线的移交阶梯）；
• 验收标准进 Skill：把"怎样算合格"写进 SKILL.md 的验收段，Agent 自检，人也照此验收——标准从聊天记录升格为资产。

本课自测

1. Skill 解决的"重复解释"问题，根源是什么？
2. SKILL.md 的 YAML 头里哪两个字段是必填？description 决定什么？
3. 三层渐进加载分别加载什么？这样设计省了什么？
4. 判断"该不该沉淀成 Skill"的口诀是什么？