其实 Skills 的爆火也有一段时间了，最近的热点已经被 OpenClaw（原 Clawbot）霸屏了，但还是有不少人追问：Skills 到底是什么？跟 MCP 或 SubAgent 有什么区别？今天这篇就不只是介绍 Skills 了，而是从 AI 技术发展的角度，把 Function Call、Tools、MCP、A2A、Multi-Agent 和 Skills 这几个概念串起来，聊清楚它们之间的关联与区别。
Function Call、Tools 与 MCP
2022 年底，ChatGPT-3.5 推出后没多久，大家就发现了一个尴尬的问题：大模型只能回答自己训练数据里已有的知识，超出这个范围要么答不上来，要么瞎编。比如你问“现在某地天气如何”，它根本没法正确回答。
这时 OpenAI 率先出手，引入了 Function Call（函数调用）的概念。背后的逻辑其实很简单：既然有些事大模型自己干不了，那就告诉它有哪些函数可以调用，让它自己决定什么时候该调用哪个。举个例子，询问某地天气时，大模型会自动调用你事先写好的 get_weather 函数，传入参数 city，然后把函数执行结果返回给大模型，由它生成最终回复。
随着 Function Call 流行起来，一个新的概念——Tools 应运而生。Tools 代表了一套标准化的工具体系，每个工具都有统一的描述格式（名称、功能说明、输入输出 Schema），让大模型更容易自主发现和调用工具。
但是新问题又来了：OpenAI、Anthropic、Google 各有各的工具体系。比如你写了一个 get_weather 工具给 ChatGPT 用，想让 Claude 也能调用，就得按 Anthropic 的标准再写一套——标准不统一，工作量翻倍。
于是 Anthropic 站了出来，推出了 MCP（Model Context Protocol），即模型上下文协议。MCP 的思路很好理解：定义一个标准接口，就像 USB 一样，把所有工具服务做成 MCP Server，所有基于大模型的应用做成 MCP Client。任何 Client 可以即插即用地连接任何 Server。
MCP 一出现就迅速引爆了 AI 开发社区。现在社区里已经有很多现成的 MCP Server，直接集成就能用，比如 GitHub MCP Server 之类的——否则以前得自己写一大堆代码才能对接。
简单总结一下：Function Call 让大模型具备了获取外部知识的能力，Tools 给了 AI 一个工具箱，而 MCP 则为整个工具生态定义了通用接口。
A2A
既然 MCP 打通了大模型与工具之间的调用，那智能体之间的通信是不是也需要一个协议？这次轮到 Google 出场，推出了 A2A（Agent-to-Agent）协议，作为 Agent 之间的标准化通信方式。可惜的是，A2A 没能复制 MCP 的热度——MCP 已经在开发者社区形成了事实标准，而 A2A 因为落地场景偏向企业级、上手门槛高等原因，推进速度慢了不少。
Multi-Agent
在 MCP 爆火之后，除了 A2A，还有一个得到广泛应用的思路是 Multi-Agent（多智能体协作），SubAgent 的使用也属于这一范畴。核心思想不是让一个 Agent 包揽所有事，而是让多个 Agent 分工合作：每个 Agent 有自己的角色定位、专属工具和专业领域，再有一个主 Agent 负责整体调度，它们相互协调，共同完成复杂任务。
Multi-Agent 整体来看，并不像前面那些由某家公司提出的规范或协议，它更像是一种广泛应用在复杂场景下的 Agent 实现方式。
Skills
Skills（技能）的爆火，坦白说有点意外，又是 Anthropic 的杰作。Claude Code 作为 2025 年爆火的 AI 编程工具之一，在 10 月发布了 Skills，但当时并没有掀起太大波澜——毕竟只在 Claude Code 中间出现，使用者有限。后来可能因为 Simon Willison 写了一篇博文《Claude Skills are awesome, maybe a bigger deal than MCP》，大家才开始试用 Skills，口碑慢慢传开，持续发酵。直到 2025 年 12 月，Anthropic 才将 Skills 作为开放标准正式发布，OpenAI 也迅速在 Codex CLI 中采用了同样的 SKILL.md 格式。所以 Skills 的爆火时间其实不长，而且很大程度上得益于在 Claude Code 中的成功。下面就来具体讲讲 Skills 到底是什么——这也是大家问得最多的问题。
Skills 的本质，可以理解为一套最佳实践方法的集合。它积累了过去那些经过验证的任务执行方式，比如使用某类工具完成某类任务时，应该遵循哪些规范、注意哪些坑、采用哪些经过验证的正确做法。
具体实践上，你需要在工程中创建一个 skills 文件夹，里面放各种技能文件夹。下图是 Anthropic 官方给出的一些 skills，具体可以参考 GitHub 地址：https://github.com/anthropics/skills
每个 Skill 文件中，核心是一个 SKILL.md 文件。该文件以 --- 标记之间的 YAML 元数据开始，必须包含 name 和 description，然后是 Claude 在 Skill 激活时遵循的 Markdown 说明。此外，也可以附带脚本、模板等资源。
AI 在执行任务时会自动判断需要加载哪些 Skill，然后按 Skill 中的指导来操作，本质上是一种按需加载的即时经验注入。具体流程如下：
1. 元数据发现： 当 Claude Code 启动时，它会扫描所有可用的 Skills，但只会加载每个 SKILL.md 文件头部的元信息（尤其是 name 和 description）。这两个字段必须清楚地描述你的 Skill 是干什么的。扫描后，这些信息会被注入到 System Prompt 中。
2. 即时加载： 用户提出一个具体任务后，AI 会加载 Skills 进行匹配，如果发现有可用的 Skill，就会触发它。此时才会真正去读取对应 SKILL.md 文件的主体内容（下面的 Markdown 部分）。
3. 指令执行： 对于 SKILL.md 中的指令，如果发现该 Skill 用到了目录中的其他文件（比如某个 Python 脚本），AI 只有在执行时才会去加载那个脚本。这是更深层次的按需加载，允许我们构建包含大量脚本、模板、数据和文档的复杂 Skill。这种设计的好处是：不用担心一次性撑爆 AI 的上下文窗口。
最后对 Skills 做一个总结：Skills 的本质是经验，解决的是“如何把任务做得更好”的问题；而前面说的 Tools 和 MCP 是能力，解决的是“能不能做”的问题。两者有明显区别。
Skills 现在非常火，类似于 MCP 的影响力，开源社区已经涌现了大量 Skills，大家可以直接参考使用。各大 AI 厂商也纷纷在自己的产品中支持了 Skills。
好了，今天的文章就写到这吧。最后感叹一下这三年来 AI 的进化史，有一条暗线贯穿始终：AI 正在从一个对话工具变成生产力的基础设施。现在爆火的很多 AI 热点，终归只是发展过程中的中间产物，一定不会是最终答案。2026 年初，Claude 的 Skills 与 OpenClaw 爆火，打响了第一枪，接下来，让我们看看还会有什么。
