当前位置：首页 > news >正文

Function Call、MCP、Skills深度解析：AI Agent开发者的必备知识！

news 2026/4/18 0:25:38

Skill 不就是一种更高级的工具吗？

MCP不就是工具调用吗？

Function Calling不就是让模型用Skill吗？

准确的说，这个3个其实是有关联，但是不能完全这样理解。因为这几个东西，压根就不是一个层级的问题。很多人做 Agent 最大的麻烦，不是不会写 Skill，也不是不会接工具，而是把“任务方法”“调用机制”“连接协议”“外部能力”全揉在了一起。为了便于理解这3者之间的关系，我们举出一个通俗易懂的例子。

先讲个故事，想象一下，你雇了一个超级聪明的助手。这个助手能听懂人话、能帮你查资料、能帮你干活，唯一的问题是它能动嘴，但不能动手。

这时候你面临三个问题：

它怎么帮你干活？得有个"调用"的机制吧？

怎么统一各种工具？查天气、打卡点、调API，总不能每个都单独学一套吧？

怎么让它更聪明？能不能把一堆能力打包成一个"技能包"？

这三个问题，正好对应今天要讲的三个概念：Function Call、MCP、Skills。

一、Function Call：让AI"能动"的第一把钥匙

它是什么？

Function Call(函数调用），可以理解为LLM(大型语言模型)的"手"，是模型发起结构化调用的一种机制。OpenAI 官方对 Function calling 的表述非常直接：它允许模型连接外部工具和系统，由模型生成结构化参数，再由应用执行相应函数。

换句话说Function Calling 本质上是在回答“模型该怎么把调用意图表达出来”。也就是调哪个函数、给什么参数、参数长什么结构、调完之后结果怎么回传。

以前，AI再聪明，也只能聊聊天、回答回答问题。但是让它帮你查个天气、订个机票——对不起，它只能说"抱歉，我做不到"。但有了Function Call就不一样了。AI可以主动调用外部工具，完成实际动作。

我们看下这个简单的例子，让模型去帮我查询下天气。

我："帮我查下明天北京天气" AI：一想：这我得调用天气工具啊！ AI：生成一个"调用请求"（函数名+参数） AI：外部系统执行，返回天气数据 AI：把结果翻译成人话告诉你

简单说：Function Call = AI的"动手能力"。

局限性

但Function Call有个问题——它是模型自带的，不同模型之间不通用。就像苹果的充电线和安卓的充电线，虽然都能充电，但接口不一样。OpenAI的Function Call格式和Claude的Function Call格式，就不太一样。这就引出了下一个概念——MCP。

二、MCP：让AI工具"统一度量衡"的协议

它是什么？

MCP（Model Context Protocol），翻译过来是"模型上下文协议"。这是Anthropic（Claude的背后公司）提出的标准化方案。Anthropic 在发布 MCP时把它定义为一个开放标准，用来在 AI 应用和外部数据源、工具之间建立安全的双向连接。

MCP 官方文档也把它类比成 AI 应用的 “USB-C port”，意思就是：不同应用和不同外部系统之间，不要每次都重新发明一套连接方式，而是尽量走统一协议。也就是说，MCP 不是某个具体工具，也不是某个具体 Skill。它更像一种连接外部能力的通用协议层。

如果说Function Call是"汽车发动机"，那MCP就是"方向盘+变速箱"——它定义了AI怎么和外部工具"对话"。

为什么需要MCP？

现在市面上的工具那么多，比如：

查天气的API 调日历的接口 读文件的系统 浏览网页的插件 ...........

每个工具的"说话方式"都不一样，AI要一个个学，是不是太累了？

MCP的作用就是：统一所有工具的"语言"。

不用MCP：AI要学10种"方言"

用了MCP：AI只需学一种"普通话"

MCP的核心能力

能力	解释
工具发现	AI能自动知道有哪些工具可用
标准化描述	所有工具都用统一格式描述
双向通信	不只是调用，还能接收工具返回的上下文

三、Skills：把AI能力"打包"成产品

它是什么？

Skills是OpenClaw提出的概念，可以把它理解为"技能包"，把提示词、工具、工作流打包成一个完整的产品。它的核心理念是不要让AI从零开始学做事，而是给它一套标准化的技能工具箱。

如果说：

Function Call =引擎（提供动力）

MCP =传动系统（控制方向和传递动力）

那Skills =整车（直接给用户用的完整产品）

Skills包含什么？

一个完整的Skill不仅仅包含执行逻辑，更包含容易被理解的描述信息。通常有三部分：

1）能力描述层

是一个对外的接口，包含功能描述、输入/输出的规范，在这里会扮演提示词的角色，它会告诉AI怎么扮演这个角色。

2）元数据层

标识信息:唯一名称、版本号、开发者。

分类与标签:便于检索和归类，比如Tag

权限说明:执行所需的数据或系统访问权限清单。

3）执行逻辑层

核心处理逻辑:实现功能的代码、脚本或工作流，定义了执行顺序和逻辑。

配置与参数:允许用户自定义的设置项。

错误处理机制:定义异常情况的反馈与处理方式

这样，用户只需要"安装技能"，就能拥有一系列完整的能力，不用自己一个个配置。简单说：

Function Call让AI"能动手"

MCP让AI"会说话"（统一协议）

Skills让AI"能干活"（完整技能）

四、深度对比：三者的异同

功能对比表

维度	Function Call	MCP	Skills
定义	模型原生能力	标准化协议	应用封装
作用	让LLM能调用函数	统一工具交互格式	组合提示词+工具+工作流
层次	底层执行	中间协议	上层应用
灵活性	低（依赖模型）	中（标准化可扩展）	高（完全自定义）
典型场景	简单单步工具调用	多工具统一管理	复杂多步骤工作流
代表产品	OpenAI Function Call	Anthropic MCP	OpenClaw Skills

演进关系

简单任务中等任务复杂任务

Function MCP Skills

Call ──► Server ──► 完整技能)

单函数多工具工作流+提示

接下来，我们来看一张图，深入了解一下这个概念在工程上是处于什么层次。

我们可以从下面的这张图里看出来：

Skill层代表应用层，调用机制层在中层，MCP连接协议在下层。

第一层：Skill 层。这层直接解决的是这类任务怎么做。关注的是任务方法、输入输出、规则约束、边界异常、任务经验沉淀。

第二层：调用机制层。解决的是模型怎么把外部动作发出去。这里最典型的就是Function Calling、Tool call schema、参数结构、调用返回结果的组织方式，它更像“模型和外部能力之间怎么说话”。

第三层：连接协议/接入层。解决的是这些外部能力、数据和资源，到底怎么接进系统。这里最典型的就是MCP client / server、MCP tools / resources、标准化外部接入、不同应用与不同系统之间的统一连接方式。Anthropic 发布 MCP 的初衷之一，就是减少每个模型、每个工具、每个数据源之间都单独做一套碎片化集成的成本。

五、实战建议：什么时候该用哪个

场景	推荐方案	理由
只想让AI调用一个简单的API	Function Call	简单直接，不需要额外配置
需要接入多个工具，想统一管理	MCP	一次配置，所有工具统一调用
需要复杂的工作流，想封装复用	Skills	把提示词、工具、工作流打包成产品

我们简单理解下：

Skill：任务方法层，沉淀这类事怎么做。关注的是任务方法、输入输出、规则约束、边界异常、任务经验沉淀。

工具调用：外部能力使用层，让模型去用搜索、数据库、脚本、API 这些外部能力。

Function Calling：结构化调用机制，让模型以函数/工具参数的方式发起调用。

MCP：标准化连接协议层，让 AI 应用更统一地接外部工具、资源和系统。

它们是有关联，但不是替代关系。Skill 可以用到工具调用，工具调用可以通过 Function Calling 实现，外部工具和资源可以通过 MCP 暴露出来。