最近 Anthropic 又刷了一波存在感。作为最早把 MCP 这个概念带火的“开拓者”，他们显然没打算停下来：这两天又提出了一个新概念，叫Skills。更关键的是，Anthropic 还表示会在2025 年 12 月把Agent Skills以开放标准的形式正式发布。

乍一看，MCP（模型上下文协议）和 Skills 就像是给大模型装上的各种“外挂”或者“插件”。既然已经有了 MCP 这种能让 AI 联网、读数据的标准，为什么还要搞出一个叫 Skills 的新概念？这到底是技术真的升级了，还是又一次“换个名字继续讲”的概念膨胀？

其实，搞技术开发的核心目标就三个：能不能方便扩展、靠不靠谱、值不值得（成本是否划算）。很多看起来“新东西”的出现，其实都是围绕这三点在优化。

从这个角度出发，Skills 之所以出现，是因为现有架构在实际落地时暴露了一些明显的痛点，而它正是用来针对这些问题做补齐和改进的。

为什么有了 MCP，还需要 SKILLS？

之所以在 MCP 生态日渐成熟后又引入 SKILLS，核心原因主要归结于以下两点现实约束与定位缺失：

MCP 生态越来越成熟之后，MCP 虽然好用，但随着功能变强，它也变得越来越“臃肿”。引入SKILLS，本质上是为了给模型“减负”和“省钱”。

1) 现实限制：上下文窗口容易“被撑爆”，还显得笨重

比如前段时间探索Playwright MCP， 给模型加上浏览器自动化能力。为了让模型“会用”这个工具，往往需要在提示词/上下文里塞进很多东西：

Playwright 一大堆 API 定义

各种参数结构说明

甚至还有当前页面的 DOM 树信息

这些内容一多，上下文窗口很快就被占满，系统也显得笨重、不灵活。

更麻烦的是：工具调用过程中产生的中间结果也要占 token。在典型的 MCP 流程里，模型不仅要做决策，还常常要负责“转发/整理数据”（有点像数据路由器），于是中间数据来来回回，token 消耗就被放大了。

官方举的例子也能说明这个问题：当你让 Agent 执行“从 Google Drive 下载会议记录，并把它附加到 Salesforce 的线索里”这种跨工具任务时，过程中会产生很多步骤和中间信息，而这些都会持续挤占上下文和 token(太费钱了)。

在 MCP 这种模式里，数据的传递方式说白了有点像“人工搬家”，而且是用手扛着着一整套沙发从一楼爬到二十楼那种笨办法：

(1）读取时怎么做：模型先调用 Drive 工具，Drive 不管三七二十一，把一份长达 2 万字的会议纪要整份塞进模型的上下文窗口里。

(2）写入时怎么做：模型把这份长文档读完后，又调用 Salesforce 工具，然后把这2 万字原封不动当作参数再塞进去，重新发送一遍。

结果就是：又贵、又卡、还容易出错。

Token 花费翻倍（贵）：

比如一场 2 小时的销售会议，转录文本可能就有 50,000 个 Token。现在等于“进一次、出一次”，模型要处理两遍大文本，额外多吃掉 100,000+ Token，成本直接飙升。

上下文容易爆掉（卡）：

就算是支持长上下文的模型，遇到更大的文档或更复杂的数据结构，也可能一下子把窗口塞满，导致流程跑到一半直接中断。

稳定性变差（错）：

模型在“手动搬运”海量内容时，就像人 copy-paste 大段文字一样，容易出现幻觉、漏内容、被截断、格式乱等问题。

这种做法不仅让 Token 消耗暴涨（成本更高），还会因为上下文太长、信息太多而分散模型注意力，让它在真正需要思考的关键逻辑上反而“变笨”。

2). 定位缺失：工具和方法“没连起来”

MCP 的核心作用，是把“怎么调用工具”这件事统一成一套标准协议。它最初要解决的问题很现实：如果有N个模型、M 个工具，两两适配会变得特别复杂。

但问题在于：MCP 只规定了“手怎么用工具”（调用方式），却没规定“脑子怎么把事情做完”（业务流程/SOP 怎么编排）。

所以在当前常见架构里，就算 Dify、n8n 这类平台能很方便把 MCP 接进来当“工具库”，真正的业务逻辑往往还是：

藏在大模型的“隐性经验”里（靠模型临场发挥），或

写死在人工配置/硬编码的工作流里。

结果就是：工具本身是“被动提供能力”的，但“怎么组合这些工具完成复杂任务”，缺少一个统一、标准的承载方式。

3). 怎么补这个空？Anthropic 用 Skills 给出答案

为了解决“有工具但缺流程标准”的问题，Anthropic 提出了Skills（技能）。

你可以把 Skill 理解成：把某件事做好的标准操作方法（SOP）打包成一个可复用模块。

打个比方：

大模型像厨师，

工具像锅碗瓢盆和灶台，

Skill 就像一道菜的“标准菜谱”：什么时候切菜、先炒什么、火候多少、用哪些厨具——都写清楚。

因此，Skill 的本质是标准化的 SOP 沉淀：不仅说明“要做什么”，还把“怎么做、需要哪些资源”一起封装进去。

对比一下变化会更直观：

过去：因为模型理解有限，业务流程通常只能用 Python/JS 或 Dify 的 YAML 这类方式“硬编码”出来。

现在：模型理解力更强后，很多流程可以直接用自然语言描述；非程序员也能把自己的经验固化成可复用的流程模块。类似思路早期在 OpenAI 的 GPTs 上出现过，但 Skill 更强调“工程化与标准化”——不局限在某个聊天产品里，而是能成为 Agent 可调用的基础能力单元。

核心理念：别一股脑塞给 AI，要“按需投喂”

虽然现在的 AI 记性越来越好（上下文窗口变大），但如果你把成吨的信息一次性全倒给它，AI 也会“大脑过载”，不仅容易胡言乱语、抓不住重点，而且还特别费钱。

所以，Skill 的设计思路就像**“剥洋葱”或者“看菜单”**：不问不给，问到哪层给哪层。这种专业术语叫“渐进式披露”，说白了就是：只在最需要的时候，给最关键的信息。

为了实现这一点，Skill 把信息分成了三层：

第一层：店招/名片（元数据层 —— 始终亮着）

作用： 告诉 AI “我是干嘛的”。

内容： 只有技能的名字和一句话简介。

好处： 就像店门口的招牌，AI 一眼就能扫到，占用的“脑力”（Token）极少，非常省钱。

第二层：操作手册（指令层 —— 选中后再看）

作用： 告诉 AI “这事儿具体怎么办”。

**内容：**详细的步骤、规矩和工作流程（比如SKILL.md 文件）。

好处： 只有当 AI 确定要用这个技能时，才会去读这份手册。这样它能集中注意力，把事儿办得更稳妥。

第三层：工具箱/大仓库（资源层 —— 干活时才开）

作用： 给 AI 真正干活用的“原材料”。

内容： 复杂的代码脚本、厚厚的参考文档、庞大的数据模板。

好处： 这是最占内存、最费钱的部分。所以，只有当 AI 真正开始动手干活、非用不可时，才会去仓库里取。

Skill 的标准结构：一个有序的“工作间”

一个标准的 Skill 通常会按“文件夹 + 文件”的方式来组织。你可以把它想成：一个技能包，里面把“说明书、工具、资料、素材”分门别类放好，结构大概是这样：

my-skill/ ├── SKILL.md          # [必需] 核心大脑。包含元数据（name、description）和自然语言编写的指令流程 ├── scripts/          # [可选] 执行手脚。存放 Python/Bash 等可执行代码，封装复杂逻辑 ├── references/       # [可选] 知识库。存放模型决策所需的参考文档、API 手册等 └── assets/           # [可选] 静态资源。存放输出报告所需的模板、图片、示例数据等

这种分层设计有什么好处？

更省 Token、上下文更“干净”

模型不会一上来就把所有内容都读进来：

先只看SKILL.md里的元信息来判断“要不要用这个技能”；决定要用之后再读具体流程；真正执行时才去加载scripts或references。

这样可以有效避免上下文越堆越大。

也能解决“中间工具结果把 token 吃光”的问题：在 Skill 模式下，模型更多是下指令让脚本去干活，比如脚本直接从 Google Drive 拉数据并写进 Salesforce，大段会议记录根本不需要塞进模型的上下文窗口。

更稳定、更不容易出错（鲁棒性更强）

把复杂、常用、容易踩坑的操作封装进scripts，就不需要模型每次都“现场写代码、现场调试”。

结果就是：幻觉更少、错误更少、执行更一致。

这也符合很多工具型产品的思路：把高频且容易错的部分固化成“工具/代码”，把需要灵活判断的部分留给模型来做。

简单三步，上手使用 Skill

使用 Skill 的过程非常直观，就像给你的 AI 助手安装了一个“功能插件”。

1). 怎么安装？

你不需要复杂的配置，只需要把写好的skills文件夹，像放文件一样丢进特定的目录即可。

通常有两个地方可以选择：

全局有效： 放在你电脑的用户目录下。

**项目有效：**放在你当前工作项目的根目录下，路径通常是.claude/skills。

2). 怎么运行？

如果你习惯用命令行，直接使用Claude Code工具就能调用。如果你更喜欢在编译器里操作，比如Cursor或VS Code，只要符合文件规范，AI 就能自动识别并学会这个新技能。

3). 举个例子：做一份红烧肉

开发一个 Skill 到底有多简单？以“教 AI 做红烧肉”为例：你只需要写清楚步骤和逻辑，保存成文件即可。

这种方式带来了一个巨大的变化——“配置即代码”：

以前： 你可能需要在 Dify 这种可视化平台上，像连连看一样拉很多线条、点很多按钮来设计工作流。

现在： 你只需要写一段结构化的文字（代码）。

这样做有什么好处？

管理方便： 像管理代码文件一样，你可以随时查看修改记录（版本管理）。

轻松分享： 把文件发给同事，他粘贴到文件夹里就能直接用。

随处复用： 同样的功能，可以在不同的项目中无缝切换。

就一句话，Skill 让 AI 的能力变得“模块化”了——写完即用，复制即学会。

后记

这几个月里，开发者社区一直在分享各种 MCP 工具，大家主要是在解决“怎么把手伸出去干活”的问题——也就是让模型能调用工具、访问资源、完成具体操作。

但从现在开始、以及接下来一段时间，Skill 很可能会成为的方向。因为它不只解决“手”，更在解决两件更关键的事：怎么思考（脑），以及怎么把事情按步骤做完（流程）。

更重要的是，Skill 不只是把工具和资源“收纳起来”，它还能把一套做事方法标准化、流程化。当大模型的推理能力越来越强，Skill 就像补上了“自主智能体”拼图里那块最关键的缺口——让它不止会做事，还会按正确的方法持续把事做成。