1. 引言

随着大语言模型（LLM）从单纯的对话机器人向能够自主执行任务的 Agent 演进，如何让模型安全、高效地与外部世界交互，成为了核心课题。在众多技术方案中，Function Calling、MCP（Model Context Protocol） 和 Skills 是三个最常被提及且容易混淆的概念。

它们都旨在解决同一个问题：让 LLM 能够调用外部工具、获取实时数据或执行特定操作。然而，它们在设计哲学、架构层次、使用场景和生态定位上有着本质的区别。

本文将深入剖析这三者的定义、工作原理、核心差异以及各自的适用场景，帮助你构建清晰的 AI Agent 技术选型认知。

2. Function Calling：最底层的原生能力

2.1 定义与起源

Function Calling（函数调用）并非一个独立的协议或框架，而是大语言模型 API 提供的一种原生能力。它最早由 OpenAI 在 2023 年 6 月提出，随后被 Google Gemini、Anthropic Claude、百度文心一言、阿里通义千问等主流模型厂商广泛采纳。

其核心思想是：开发者可以在 API 请求中，以 JSON Schema 的形式描述一组可用的函数（包括函数名、参数描述、参数类型等）。模型在理解用户意图后，会判断是否需要调用某个函数，并输出一个结构化的 JSON 对象，包含要调用的函数名和参数。开发者拿到这个 JSON 后，在自己的服务端执行该函数，并将结果返回给模型，模型再基于结果生成最终的回复。

2.2 工作原理

1. 定义工具：开发者定义一组工具（Tools），每个工具包含 name、description 和 parameters（JSON Schema）。
2. 发起请求：将用户消息和工具定义一起发送给 LLM API。
3. 模型决策：LLM 分析用户意图，如果认为需要调用工具，则返回一个 tool_calls 对象，而不是直接生成文本回复。
4. 执行工具：开发者收到 tool_calls 后，在自己的后端执行对应的函数（如查询数据库、调用第三方 API）。
5. 返回结果：将函数执行结果作为新的消息（tool role）发送回 LLM。
6. 生成回复：LLM 结合工具返回的结果，生成最终的、对用户友好的自然语言回复。

2.3 核心特点

• 标准化：JSON Schema 是业界广泛接受的描述格式，几乎所有主流模型都支持。
• 低延迟：由于是模型原生能力，无需额外的中间层或协议转换，调用链路最短。
• 灵活性：开发者可以定义任意复杂的函数，只要能用 JSON Schema 描述其输入输出。
• 局限性：函数定义和调用逻辑完全由开发者自行实现，缺乏统一的发现、认证和调用规范。每个 Agent 都需要硬编码其可用的工具集。

2.4 典型应用

• 构建一个能查询天气、设置提醒、发送邮件的个人助手。
• 让 Agent 能够调用内部 API 查询订单状态或客户信息。
• 实现一个能根据用户指令生成并执行 SQL 查询的数据分析助手。

3. MCP（Model Context Protocol）：标准化的工具连接层

3.1 定义与起源

MCP（Model Context Protocol）是由 Anthropic 在 2024 年底提出并开源的开放协议。它的目标不是取代 Function Calling，而是在其之上构建一个标准化的、去中心化的工具生态。

你可以将 MCP 理解为 AI 世界的“USB 协议”。USB 定义了设备（如键盘、鼠标、U盘）如何与主机（电脑）通信，而 MCP 定义了工具服务器（如文件系统、数据库、GitHub API）如何与 AI 客户端（如 Claude Desktop、VS Code 插件、自定义 Agent）通信。

3.2 工作原理

MCP 采用客户端-服务器（Client-Server）架构：

1. MCP Host：用户直接交互的 AI 应用，如 Claude Desktop、VS Code 中的 AI 插件。
2. MCP Client：运行在 Host 内部，负责与 MCP Server 建立一对一连接。
3. MCP Server：轻量级程序，每个 Server 暴露一组特定的工具、资源或提示。例如，一个 sqlite-server 可以暴露 query 和 execute 两个工具。

交互流程：

1. 发现（Discovery）：MCP Client 连接到 MCP Server 后，Server 会发送一个 listTools 响应，告知其所有可用的工具及其 JSON Schema 描述。
2. 调用（Invocation）：当 Host 中的 LLM 决定使用某个工具时，Client 会向 Server 发送 callTool 请求，Server 执行操作并返回结果。
3. 资源访问（Resources）：除了工具，MCP 还定义了 Resources（类似文件系统中的文件，用于向 LLM 提供上下文）和 Prompts（预定义的提示模板）。

3.3 核心特点

• 标准化与互操作性：任何遵循 MCP 协议的 Server 都可以被任何 MCP Client 使用。开发者只需编写一次工具 Server，就能被整个生态复用。
• 去中心化：工具不再需要硬编码在 Agent 代码中。用户或开发者可以自由安装、配置不同的 MCP Server，像安装 App 一样扩展 AI 的能力。
• 安全隔离：MCP Server 运行在独立的进程中，Host 可以通过配置权限（如允许访问哪些目录、哪些网络端点）来控制 Server 的行为，提高了安全性。
• 传输层抽象：MCP 支持多种传输方式，如 stdio（本地进程间通信）和 SSE（Server-Sent Events，用于远程服务器），底层通信细节对上层透明。

3.4 典型应用

• Claude Desktop：用户可以通过安装 MCP Server，让 Claude 直接读取本地文件、操作 SQLite 数据库、与 Figma 或 GitHub 交互。
• IDE 插件：VS Code 中的 AI 编程助手可以通过 MCP Server 访问项目文件、运行终端命令、调用代码分析工具。
• 企业级 Agent 平台：公司可以开发统一的 MCP Server 来封装内部微服务 API，让不同的 AI Agent 都能通过标准协议调用。

4. Skills：面向用户的任务封装

4.1 定义与起源

“Skills” 这个词在不同的平台（如 ChatGPT 的 GPTs、字节跳动的 Coze、百度文心智能体平台）中有不同的具体实现，但其核心思想是一致的：将一组指令、知识库和工具调用逻辑打包成一个可复用的、面向特定任务的“技能包”。

Skills 是比 Function Calling 和 MCP 更高层次的抽象。它不关心底层是用的 Function Calling 还是 MCP，它关心的是如何让非技术用户也能创建和分享一个能完成特定任务的 AI 助手。

4.2 工作原理

以 OpenAI 的 GPTs 为例：

1. 配置：用户通过自然语言界面，告诉 GPT Builder 自己想要创建一个什么样的助手（例如“一个能帮我写周报的助手”）。
2. 指令（Instructions）：系统会生成一组系统提示词，定义该 GPT 的行为、语气和限制。
3. 知识（Knowledge）：用户可以上传文档、PDF 等文件，作为 GPT 的额外知识库。
4. 能力（Capabilities）：用户可以选择开启哪些内置能力（如网页浏览、DALL·E 绘图、代码解释器）。
5. 动作（Actions）：这是 Skills 与 Function Calling/MCP 结合的地方。用户可以通过 OpenAPI Schema（Swagger）或 MCP 协议，为 GPT 配置自定义的外部 API 调用。

4.3 核心特点

• 用户友好：面向非开发者，通过配置而非编码来创建 AI 应用。
• 可复用与分享：创建好的 Skill（如 GPTs）可以发布到商店，供其他用户使用。
• 组合性：一个 Skill 可以包含多个工具、知识库和复杂的指令逻辑。
• 平台绑定：Skills 通常是特定平台（如 ChatGPT、Coze）的产物，跨平台迁移性较差。

4.4 典型应用

• 设计助手：一个 GPT，内置了设计规范文档（知识库），并能调用 Figma API（动作）来生成设计稿。
• 代码审查助手：一个 GPT，能读取 GitHub 仓库的 PR（动作），并根据团队编码规范（知识库）给出审查意见。
• 旅行规划师：一个 GPT，能调用航班、酒店、地图等多个 API（动作），并根据用户偏好（指令）生成旅行计划。

5. 三者对比：一张表看懂核心差异

特性	Function Calling	MCP	Skills
本质	LLM API 的原生能力	开放协议 / 标准	应用封装 / 产品形态
抽象层次	底层	中间层	顶层
核心目标	让模型能输出结构化函数调用	标准化工具与 AI 应用的连接方式	让用户能轻松创建和分享 AI 助手
使用者	开发者	开发者 / 平台	终端用户 / 开发者
工具发现	硬编码在代码中	运行时动态发现（listTools）	配置时定义
生态	模型厂商各自为政	开放、去中心化、跨平台	平台封闭生态
安全性	由开发者自行实现	协议层面支持隔离与权限控制	由平台实现
复杂度	低	中	高（对平台而言）
典型代表	OpenAI tool_calls	Anthropic MCP	OpenAI GPTs, Coze Bot

6. 如何选择：场景驱动的技术选型

6.1 什么时候用 Function Calling？

• 你正在构建一个独立的、功能单一的 Agent，例如一个只负责查询内部 CRM 系统的聊天机器人。
• 你对延迟和性能有极致要求，不希望引入额外的网络开销或协议转换。
• 你的工具集是固定的、有限的，不需要动态发现或用户自定义安装。
• 你希望获得最大的模型兼容性，因为几乎所有模型都支持 Function Calling。

6.2 什么时候用 MCP？

• 你正在构建一个通用的 AI 平台或框架，希望第三方开发者能轻松为其贡献工具。
• 你的 Agent 需要访问多种异构系统（如文件系统、数据库、云服务、SaaS 应用），且这些系统可能频繁变化。
• 你重视安全隔离，希望将工具运行在沙箱环境中，限制其权限。
• 你希望你的工具生态能够跨平台复用，一次开发，同时支持 Claude Desktop、VS Code 插件、自定义 Web App 等。

6.3 什么时候用 Skills？

• 你是一个非技术用户，希望快速创建一个能完成特定任务的 AI 助手，而不想写代码。
• 你是一个平台方，希望构建一个 AI 应用商店，让用户能发现、安装和使用他人创建的 AI 助手。
• 你需要将复杂的指令、知识库和多个工具组合成一个连贯的、面向特定场景的体验。

7. 三者关系：不是替代，而是互补

理解这三者关系的关键在于：它们处于不同的抽象层次，可以协同工作。

• MCP 可以基于 Function Calling 实现：MCP Client 在调用 LLM 时，底层使用的正是 Function Calling 能力。MCP 协议是对 Function Calling 的标准化封装。
• Skills 可以包含 MCP 或 Function Calling：一个 Skill（如 GPTs）的“Actions”功能，既可以配置为传统的 OpenAPI Schema（底层是 Function Calling），也可以配置为 MCP Server。
• 三者共同构建了 AI Agent 的完整生态：
  • Function Calling 提供了“让模型理解工具”的基础能力。
  • MCP 提供了“让工具可被发现和连接”的标准协议。
  • Skills 提供了“让能力可被组合和分享”的产品形态。

8. 未来展望

• MCP 有望成为行业标准：随着 Anthropic 的推动和社区的支持，MCP 正在被越来越多的工具和平台采纳。它有可能像 LSP（Language Server Protocol）统一代码编辑器生态一样，统一 AI Agent 的工具生态。
• Function Calling 将更加内化：模型对 Function Calling 的支持会越来越好，例如更精准的参数提取、更复杂的嵌套调用、甚至模型原生支持并行调用多个函数。
• Skills 将更加智能和自动化：未来的 Skills 可能不再需要用户手动配置，AI 可以自动分析用户需求，动态组合和编排工具，甚至自动生成新的工具调用逻辑。

9. 总结

概念	一句话总结
Function Calling	让 LLM 能“理解”并“请求”调用外部函数的原生 API 能力。
MCP	标准化 AI 应用与外部工具之间通信的开放协议，实现“即插即用”。
Skills	将指令、知识、工具打包成面向特定任务的、可分享的** AI 应用产品形态**。

对于开发者而言，理解这三者的区别至关重要。Function Calling 是基础，MCP 是生态，Skills 是产品。在实际项目中，它们往往不是非此即彼的选择，而是可以分层组合，共同构建出强大、灵活且安全的 AI Agent 系统。