吴恩达的skill课程（一）：Agent Skills到底是什么

最近花了大概两个多小时把吴恩达在 DeepLearning.AI 上和 Anthropic 合作出的那门《Agent Skills with Anthropic》刷完了。课程本身不复杂，10节课，每节都不长，但信息密度挺高的。本来打算一篇笔记写完，结果发现内容实在太多，还是拆成上下两篇比较合适。

这一篇先聊最核心的问题：Skills 是什么，它解决了什么问题，以及它和 Tools、MCP、Subagents 这些概念到底有什么区别。

Skills 的本质：一个文件夹而已？

说起来有点不可思议，Skills 的核心载体就是一个文件夹。

对，就是你在电脑上每天创建的那种文件夹。里面必须有一个 SKILL.md 文件，包含 YAML 头部的名称和描述，以及具体的指令内容。然后你可以选择性加一些子目录——references/ 放参考文档，scripts/ 放执行脚本，assets/ 放资源文件。

就是这么简单。

my-skill/
├── SKILL.md          # 核心指令（名称 + 描述 + 详细指令）
├── references/       # 参考文档
├── scripts/          # 执行脚本
└── assets/           # 模板、图片等资源

但我越往下看越觉得，这个”简单”的设计其实是经过深思熟虑的。Skills 要解决的不是”如何让 AI 更聪明”，而是另一个完全不同的问题：如何让 AI 稳定地、可重复地执行一个专业领域的工作流。

很多时候我们和 AI 对话的问题是：你上个月教过它的东西，这个月还得重新教一遍。你上次精心调试好的提示词，换个会话窗口就没了。每次都要重新描述需求，重新打包参考材料，重新解释”这个事情的背景是这样的”。这些重复劳动消耗的不只是时间，还有一种很难描述的认知负担——你要一直保持”我在教一个聪明但不太了解情况的助手”的状态。

Skills 的答案很直接：把专业知识和操作流程写成文件，放进文件夹，需要的时候按需加载。

核心机制：渐进式披露

如果仅仅是把指令写成文件，其实没什么新鲜的。Skills 真正巧妙的地方在于它的三层加载策略，官方叫 Progressive Disclosure。

这个设计解决了一个很实际的痛点：上下文窗口是有限的。

你不可能把几十个 Skill 的完整内容全部塞进上下文里，那样的话 AI 还没开始干活就已经被各种指令淹没了，而且每一轮对话都要为这些”可能用不到”的指令支付 token 成本。

渐进式披露的做法是这样：

层级	加载内容	什么时候加载	Token 成本
第一层	`name` + `description`（YAML 头部元数据）	始终在上下文中	约 100 tokens 每个
第二层	`SKILL.md` 的完整指令正文	当 Agent 判断该 Skill 与当前任务匹配时	一般不超过 5000 tokens
第三层	`references/` `scripts/` `assets/` 中的文件	当具体执行需要参考资料时	按需加载

这个设计的精妙之处在于：你理论上可以拥有无限多个 Skill，但上下文成本是可控的。 Agent 先看”菜单”（名称和描述），点菜之后才上菜（完整指令），最后需要参考配料时才查文档（资源文件）。

某种意义上，这和人类的认知方式挺像的。你不会把所有知识时刻放在脑子里，大部分东西都是以”索引”的形式存在——你知道它能解决什么问题，应该在什么场景下使用，但直到真正需要时，才会把详细的知识调出来。

Skills 不是什么万能胶

课程里有一节专门讲 Skills 和其他几个概念的区别，我觉得这是整个课程最值得认真看的部分。因为这几个概念确实容易搞混，但它们各自解决的问题其实不同。

Tools（工具）

工具是原子操作。读取文件、执行代码、发起网络请求——这些都是”手”和”脚”，让 Agent 能够与环境交互。工具始终挂在 Agent 的上下文里，永远可用。

Skills 不是工具。Skills 更像是使用工具的方法论。”如何用锤子和锯子做一个书架”，而不是锤子和锯子本身。

MCP（Model Context Protocol）

MCP 解决的是连接外部系统的问题。Google Drive、GitHub、数据库、API——MCP 是一个标准协议，让 Agent 能访问外部数据和服务。可以把它理解成万能数据插座。

Skills 和 MCP 的关系是互补的：MCP 负责”拿到数据”，Skills 负责”知道怎么处理数据”。两者组合起来才是完整的。

Subagents（子代理）

Subagents 是独立的执行单元，拥有自己独立的上下文窗口和工具权限。你可以给不同的子代理配置不同的工具、不同的权限、不同的 Skills。

区别在于：Skills 是”培训手册”，Subagents 是”专职员工”。Skill 加载到主 Agent 的上下文里使用，Subagent 则是把任务派发出去，在隔离的环境里执行。

这两者也可以组合：一个 code-reviewer 子代理可以加载 python-security 这个 Skill——独立的执行环境加上可移植的专业知识。

简单总结一下这几个概念的分工：

Tools：给 Agent 手和脚，让它能做事
MCP：给 Agent 数据来源，让它能连接外部世界
Skills：给 Agent 经验和方法，让它知道怎么做事
Subagents：给 Agent 独立分身，让不同任务互不干扰

它们不是互相替代的关系，而是各管一摊，组合起来才是完整的 Agent 能力体系。

一个具体的例子

课程里用了一个市场营销分析的案例来演示 Skills 的价值。

假设你要做一个营销活动分析报告，流程大概是：从 BigQuery 拉数据 → 做数据分析和洞察 → 按品牌调性写成报告 → 生成 PPT。

没有 Skills 的情况下，你得一步步告诉 Agent 怎么做每一步，解释品牌调性是什么，报告格式长什么样，PPT 模板在哪。

有了 Skills 之后，这个过程就变成：

BigQuery Skill 负责数据查询逻辑（SQL 模板、表结构说明）
Marketing Analysis Skill 负责分析框架（指标解释、分析维度、benchmark 参考）
Brand Skill 负责品牌调性（文案风格、视觉规范、禁忌事项）
PowerPoint Skill 负责输出格式（模板文件、排版规则、图表样式）

这几个 Skill 可以串联成一个端到端流程，而且每个人都可以复用别人写好的 Skill。更重要的是，同一个 Skill 可以在 Claude Code、Claude.ai、API、Agent SDK 甚至 Cursor 和 Trae 里使用——因为 Skills 已经是一个开放标准，不是某个产品的专属功能。

我的一点感受

我觉得 Skills 最值得关注的地方，不在于技术有多复杂——说实话，文件夹加 Markdown，真的不复杂。它值得关注的地方在于它指向了一个方向：AI 应用的工业化正在从”写好提示词”走向”构建可复用的知识资产”。

之前我们用 AI，更多是手工作坊模式——每次都是一个 prompt 接一个 prompt，靠个人手艺，难以规模化。Skills 相当于把那些经过验证的、可以重复使用的专业知识，用文件的形式资产化了。你不会丢失它，可以迭代它，可以分享它，可以用在任何兼容的 Agent 上。

而且它能显著提高一致性。课程中演示了 Brand Skill 如何确保输出风格统一、品牌调性不跑偏，这背后其实是让 AI 的行为更像”可预期的助手”，而不是每次随机发挥。

某种意义上，Skills 的价值会随着时间累加。你写的 Skill 越多，能复用的积累越深，后面做事情的效率提升越明显。这和传统软件开发里”造轮子 vs 调库”有异曲同工的地方——一开始写 Skill 可能要花些心思，但一旦形成库，后续的工作就变成了搭积木。

下篇会聊更实操的部分：怎么创建自定义 Skill，以及在不同环境（API、Claude Code、Agent SDK）里具体怎么用。