上周有读者问我一句话：Skills 出来了，MCP 是不是快被淘汰了？

我盯着这句话看了很久。它错得很典型——不是理解错了某个细节，是整个方向反了。

Function Calling、MCP、Skills，这三样东西在时间上确实一前一后出现，功能上看起来都在"让 AI 干活"，于是很自然被理解成一代接一代的迭代关系。但它们压根不在同一个层面上，谈不上谁取代谁。

把这个关系理清楚，比学会任何一个新工具的用法都值钱。因为分层一旦看懂，以后每冒出一个新技术，你自己就能判断它该放哪。

先说结论

Function Calling 解决"能不能调用"，MCP 解决"接得顺不顺"，Skills 解决"会不会干"。

三句话，三个层面：接口、连接、经验。

它们不是三个版本，是三层结构。叠着用，不是换着用。

下面一层一层拆。

一、Function Calling：让模型伸出手（2023）

2023 年年中，OpenAI 给模型加了一个能力：它可以输出一段结构化的指令，说明"我想调用哪个函数、参数是什么"。

注意这里有个特别容易被忽略的点——模型自己不执行任何东西。它只是把"我想干什么"写清楚，真正去查数据库、发请求、改文件的，是你自己的程序。

所以 Function Calling 的本质，是给模型装了一只手。手能伸出去，但手不会自己动。

它解决了从 0 到 1 的问题：在此之前，模型只能吐文字，你没法可靠地让它触发一个真实动作。

但它很快撞上一个天花板。假设你有 10 个 AI 应用、要对接 30 个外部系统，每个组合都要单独写一套对接代码。10 乘 30，三百套。每换一个数据源，所有应用都得跟着改一遍。

这个成本在行业里有个名字，叫"集成税"。

Function Calling 给了模型一只手，但没给这只手准备任何标准接口。每接一个新东西，都要重新焊一次。

二、MCP：给手配一个插排（2024–2026）

2024 年底，Anthropic 提出了 MCP（Model Context Protocol，模型上下文协议）。它的想法很朴素：既然每个工具都要单独对接，那不如把"AI 怎么调用工具"这件事本身标准化。

标准化的效果是立竿见影的——原来是你对接我、我对接你，两两配对；现在是大家都插到同一个标准插排上。

从 N 乘 M，变成 N 加 M。

这个账很容易算：10 个应用、30 个系统，从三百套对接变成四十个。而且换掉任意一个应用或系统，其他部分不用动。

MCP 的推进速度也说明了这个痛点有多真：

2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会下属的 Agentic AI Foundation，Anthropic、Block、OpenAI 共同参与。中立治理这一步是关键——没有它，其他厂商不会放心把自己的产品接到另一家公司的协议上。到 2026 年 7 月，MCP 发布了迄今为止最大的一次规范修订，核心协议改成了无状态的，去掉了初始化握手和会话管理，服务器可以像普通 HTTP 服务一样水平扩容。官方 SDK 现在月量接近 5 亿次，TypeScript 和 Python 两个 SDK 累计都过了一亿到十亿这个量级，注册表里的公开服务器接近 1.9 万个。Anthropic、OpenAI、Google、Microsoft、AWS 都已经原生支持。

到这一步，MCP 已经不是在争"要不要用"了，它变成了默认的接入层。

但这里有个代价，而且几乎没人讲。

MCP 统一的是接口的形状，不是接口底下的所有东西。传输机制还在分叉——有的服务器走 stdio，有的走 HTTP 加 SSE；认证方式各家不同；权限模型更是各写各的。

结果就是那句理想中的"写一次，到处能跑"，在实际工程里退化成了"写一次，然后对着每个客户端分别测一遍"。

有个数字很说明问题：行业调研里，真正把 MCP 服务器跑进生产环境的组织，大概只有四成左右。剩下六成了 SDK、搭了 demo，然后卡在这里。

量衡量的是热情，不是互通。这是 MCP 目前最真实的处境。

三、Skills：教手怎么干活（2025–2026）

2025 年 12 月，Anthropic 又往前走了一步，发布了 Agent Skills，并且直接做成了开放标准。

它要解决的问题和前两层完全不同。

MCP 让 AI 能连上你的数据库。但从"连上了"到"干得对"，中间还隔着一整套做法：先查什么、怎么校验、遇到异常怎么处理、结果按什么格式输出。这些知识过去只能靠写超长的提示词硬灌，或者干脆留在人的脑子里。

Skills 做的就是把这套做法打包成一个可复用的单元。一个 Skill 基本上是一个文件夹：里面有一份 SKILL.md 说明什么时候用、怎么用，再配上脚本、模板、参考资料。

关键在于"按需加载"——它平时不占上下文，只有在相关的时候才被拉进来。

几个事实可以说明它跑得多快：

OpenAI 的 Codex CLI 和 ChatGPT 随后也采用了同一套规范。这挺罕见的——它成了第一个跨厂商的 agent 扩展开放标准。到 2026 年年中，公开可用的 Skills 数量超过 120 万个。2026 年 7 月，Anthropic 还加了"录制技能"：你对着屏幕做一遍任务、嘴上说着为什么这么做，它就能把这套动作转成一个可复用的 Skill。这个功能指向一个很明确的人群——大量非技术岗位的人，他们不会去手写配置文件，但他们知道活该怎么干。

Skills 的代价也很清楚：数量爆炸，质量参差。

120 万个 Skill 里，真正被反复使用的只是极少数，大量是重复的、粗糙的、没人验证过的。而且 Skill 可以打包可执行脚本，这意味着装一个来路不明的 Skill，风险接近于装一个来路不明的。官方文档写得很直白：恶意的 Skill 可以指挥模型调用它本不该调用的工具。

四、它们其实是三层，不是三代

现在回头看开头那个问题。

Anthropic 自己给过一个架构描述，四层：

Agent loop（推理）：决定下一步做什么Agent runtime（执行）：跑代码、读写文件MCP servers（连接）：接外部工具和数据Skills library（指导）：告诉它这类活该怎么干

再往外还有一层 A2A，管的是 agent 和 agent 之间怎么协作。

每一层的职责都是分开的：loop 负责想，runtime 负责跑，MCP 负责连，Skills 负责教。

举个具体的例子就明白了。你让 AI 做一份竞品分析：

Skills 提供的是流程——先查哪几个维度、怎么对比、报告按什么结构写MCP 提供的是通道——去连数据库、翻 Slack 记录、读内部文档Agent loop 提供的是判断——发现某个数据对不上，决定再查一次A2A 管的是分工——把查资料和写报告拆给两个 agent

四样东西同时在跑，没有一样能省。

所以判断一个新技术属于哪一层，你只需要问三个问题：

1. 它是在定义"怎么连接外部世界"吗？→ 连接层（MCP 这一类）

2. 它是在沉淀"这类活应该怎么干"吗？→ 经验层（Skills 这一类）

3. 它是在决定"下一步做什么"吗？→ 决策层（agent loop、编排框架这一类）

问完就知道它跟现有系统是什么关系，也就知道要不要动、动哪里。

五、真正的风险不是选错，是混层

我见过两种典型的误判，代价都不小。

第一种，把 Skills 当 MCP 用。 写了一个几百行的 Skill，里面塞满了各种 API 调用和数据处理逻辑，指望它替代连接层。结果是这套东西只能在自己这一套环境里跑，换一个模型、换一个客户端就废了——因为它把"怎么做"和"怎么连"焊死在了一起。

第二种，把 MCP 当 Skills 用。 接了一堆 MCP 服务器，以为接上就万事大吉，结果模型根本不知道该在什么时候用哪个工具。连接是通的，行为是乱的。

这两件事的共同点，都是把不同层的东西混成一层用。

写在最后

回头看这三代技术，真正在变的东西其实不是"功能更强了"，而是抽象层级更高了。

Function Calling 抽象的是"一次调用"，MCP 抽象的是"一种连接"，Skills 抽象的是"一套做法"。每往上一层，能复用的范围就大一圈，能描述的东西也更接近人的经验。

但每上一层，也都会留下一道新的缝：MCP 留下了碎片化的实现，Skills 留下了质量和安全的隐患。抽象层级越高，标准化的收益越大，但标准化覆盖不到的地方也越多。

下一个机会大概率就在这些缝里——不是再发明一层，而是把已有的这层做扎实。120 万个 Skill 里，缺的从来不是数量。

你在实际项目里，这三层是怎么分工的？有没有遇到过"接上了但用不对"的情况？评论区聊聊，我挑典型的下篇展开写。

#2026年度头条精选创作者评选#