AI 中的skill、mcp和 Function Call
Skill（技能）、MCP（模型上下文协议） 和 Function Call（函数调用） 这三个概念。
简单来说，你可以这样理解：
- Function Call 是基础的、标准的“能力调用机制”。
- Skill 是面向用户的、打包好的“功能产品”。
- MCP 是连接 AI 与外部资源和工具的“新一代通信协议”。
1. Function Call（函数调用）
这是最基础、最广泛使用的概念，主要由 OpenAI 在 2023 年 6 月引入并普及。
- 是什么： 一种让大语言模型（如 GPT-4）能够智能地决定在何时、以何种参数调用开发者预先定义好的函数（或工具） 的机制。它不是直接执行代码，而是输出一个结构化的调用请求。
- 如何工作：
- 定义： 开发者向模型描述一系列可用的函数（包括函数名、描述、参数列表及参数类型）。
- 决策： 用户提问后，模型根据对话上下文判断是否需要调用函数，以及调用哪个函数、参数是什么。
- 响应： 模型返回一个结构化的 JSON 对象（如
{“name”: “get_weather”, “arguments”: {“location”: “Beijing”}}），而不是自然语言。 - 执行： 应用程序收到这个 JSON 后，在本地或服务器端实际执行对应的代码，获取结果（如调用天气 API）。
- 回复： 将执行结果返回给模型，模型再组织成自然语言回复给用户。
- 特点：
- 标准化： 已成为众多模型（OpenAI， Anthropic， 国内大模型等）支持的标准特性。
- 核心机制： 是实现 AI 与外部世界交互的基石。
- 开发层： 主要面向开发者，用户感知不强。
示例：你问“北京天气怎么样？”，模型不是瞎猜，而是“调用”了你定义的 get_weather(location) 函数，并将 API 返回的真实数据告诉你。
2. Skill（技能）
这是一个更高层、更产品化的概念，常见于 AI 智能体（AI Agent）和 AI 应用平台（如扣子/Coze, GPTs, Dify）。
- 是什么： 一个封装好的、可重复使用的功能模块或 AI 能力。一个 Skill 内部可能包含提示词、知识库、一个或多个 Function Call、工作流等。
- 如何工作：
- 构建： 在平台上通过可视化或配置化的方式，将一个完整的能力打包。例如，一个“订机票”Skill 可能包含：查询航班、获取价格、填写订单等多个步骤或函数。
- 调用： 用户通过自然语言触发（如“我想去上海”），AI 智能体自动识别并调用最匹配的 Skill。
- 执行： Skill 作为一个整体在后台运行，可能串联多个动作，最终返回结果。
- 特点：
- 产品化： 是终端用户可以直接理解和使用的东西（如“翻译技能”、“画图技能”）。
- 可组合性： 可以在智能体中安装多个 Skills，让它具备多种能力。
- 封装性： 隐藏了底层复杂的函数调用和逻辑，提供端到端的体验。
示例：在 Coze 平台上，你安装了一个“全网搜索” Skill。当用户问“最近有什么科技新闻？”时，你的 Bot 会自动使用这个 Skill 去搜索并返回结果。这个 Skill 底层就是通过 Function Call 来调用搜索 API。
3. MCP（Model Context Protocol，模型上下文协议）
这是一个由 Anthropic 提出并主导的开放协议，旨在标准化 AI 模型与外部资源（服务器、数据库、API 等）的交互方式。可以看作是 Function Call 的“进化版”或“标准化版本”。
- 是什么： 一个客户端-服务器协议。它定义了一套标准，让任何兼容 MCP 的“服务器”（提供资源的工具）都能轻松地被任何兼容 MCP 的“客户端”（AI 应用或 IDE）使用。
- 如何工作：
- 服务器： 任何工具（如文件系统、数据库、日历 API）都可以实现为 MCP 服务器，它向客户端宣告自己提供哪些“资源”和“工具”。
- 客户端： AI 应用（如 Claude Desktop， Cursor IDE）作为 MCP 客户端，启动时可以连接一个或多个 MCP 服务器。
- 通信： 客户端和服务器通过标准的 JSON-RPC 消息进行通信。当用户需要时，客户端会从服务器获取资源列表或调用工具，并将结果提供给 AI 模型。
- 特点：
- 协议化与标准化： 解决了不同 AI 模型和工具之间“各自为政”的问题。工具开发者只需实现一次 MCP 接口，就能被所有支持 MCP 的 AI 使用。
- 动态发现： 客户端可以动态地发现服务器提供的工具，无需在提示词中硬编码。
- 资源概念： 不仅限于“工具/函数”，还引入了“资源”（如文件、数据库条目）的概念，AI 可以读取资源内容作为上下文。
- 安全性： 连接通常本地化，资源访问可控，比传统的将 API 密钥暴露给模型更安全。
示例： 你在本地运行了一个 sqlite MCP 服务器和一个 filesystem MCP 服务器。当你使用 Claude Desktop 时，你可以直接说：“请查询我/projects目录下的schema.sql文件，然后根据它告诉我数据库中有哪些表。” Claude 会通过 MCP 协议读取文件内容，并调用 SQLite 工具执行查询，整个过程无需你手动配置复杂的 Function Call。
总结对比
| 特性 | Function Call | Skill | MCP |
|---|---|---|---|
| 层级 | 基础机制（原子操作） | 产品模块（功能集合） | 通信协议（基础设施） |
| 目标 | 让模型能调用单个外部函数 | 为用户提供完整的、可复用的能力 | 标准化模型与外部工具的交互方式 |
| 面向对象 | 开发者 | 终端用户 / 低代码开发者 | 工具开发者 & AI 应用开发者 |
| 关键优势 | 直接、灵活、广泛支持 | 易用、可组合、端到端 | 标准化、可发现、安全、资源感知 |
| 类比 | 单个“积木” | 打包好的“乐高套装” | 统一的“积木连接接口标准” |
| 维度 | Function Call | Skill | MCP |
|---|---|---|---|
| 抽象层级 | 模型原生接口 | 应用功能模块 | 通信协议标准 |
| 厂商绑定 | 是（OpenAI/Anthropic 等） | 否（框架无关） | 否（开放标准） |
| 互操作性 | 低（各厂格式不同） | 中（依赖框架） | 高（统一协议） |
| 开发复杂度 | 低（直接用 API） | 中（需封装逻辑） | 中（需实现 server） |
| 适用场景 | 快速集成简单工具 | 构建复杂 Agent | 企业级多模型/多工具集成 |
- Function Call 是"脑"：决定做什么
- MCP 是"神经系统"：传递信号到手脚
- Skill 是"职业技能"：知道如何专业地做事
关系与趋势
- Skill 建立在 Function Call 之上：一个复杂的 Skill 内部会利用多次 Function Call 来完成工作。
- MCP 可以视为 Function Call 的标准化演进：它提供了更丰富、更安全、更动态的工具调用和资源访问方式。未来，AI 应用的“Function Call”能力很可能通过 MCP 协议来实现。
- MCP 赋能 Skill 开发：在支持 MCP 的平台上，开发 Skill 可以更简单，直接接入丰富的 MCP 服务器资源，而无需从零编写每一个函数。
演进趋势（截至 2026 年）
- 短期：Function Call + Skill 是主流（如 LangChain + OpenAI）。
- 中期：MCP 逐渐被 IDE（如 Cursor）、AI 平台（如 Databricks）采用，成为“AI 操作系统”的一部分。
- 长期：MCP 可能成为类似 HTTP 的基础协议——任何 AI 都能通过 MCP 访问世界上的服务。
💡 类比：Function Call ≈ 浏览器原生的 fetch()Skill ≈ 封装好的 Axios 或 SDKMCP ≈ RESTful API 标准 + OpenAPI 规范总结
- Function Call 是能力基础：没有它，LLM 无法与外部世界交互
- MCP 是连接标准：没有它，每个工具都需要定制开发集成（N×M 问题）
- Skill 是价值封装：没有它，AI 只是工具的执行者，而非业务专家
