【大模型面试八股 2】Function Call、MCP、Skill的区别

[一、Function Call：模型与外部世界的"原子级"桥梁](#一、Function Call：模型与外部世界的“原子级”桥梁)
[二、MCP（Model Context Protocol）：AI 时代的"USB-C"通信协议](#二、MCP（Model Context Protocol）：AI 时代的“USB-C”通信协议)
- [2.1 MCP 协议的对象](#2.1 MCP 协议的对象)
- [2.2 MCP 详细工作流程五个阶段](#2.2 MCP 详细工作流程五个阶段)
三、Skill：面向业务场景的"能力封装体"
- [3.1 Skill 介绍](#3.1 Skill 介绍)
- [3.2 Skills 的"三层加载"机制](#3.2 Skills 的“三层加载”机制)
四、核心对比：一张表看懂差异

一、Function Call：模型与外部世界的"原子级"桥梁

🔹 本质

LLM API 层面的原子交互机制，用于让模型在对话过程中结构化地请求执行外部函数。

🔹 工作原理

开发者通过 JSON Schema 声明函数名、参数类型、描述。

模型在推理时判断是否需要调用，并输出结构化指令：

python 复制代码

{
  "name": "query_weather",
  "arguments": {
    "city": "北京",
    "date": "2026-05-16"
  }
}

宿主系统解析指令 → 执行真实逻辑 → 将结果回填给模型 → 模型生成最终回复

🔹 特点

✅ 轻量直接，聚焦"单次指令执行"

⚠️ 强依赖具体厂商 API 格式（OpenAI tools、Anthropic tool_use、Google function_declarations 等协议细节不同）

🔄 通常在同一会话内完成闭环，无长期状态管理

MCP 主机 (Host)：指的是 AI 应用程序本身，例如 Claude 桌面应用或是一个集成 MCP 的 VS Code 编辑器。它负责管理整个流程，决定何时连接到哪些服务器。
MCP 服务器 (Server)：这是一个提供数据或功能的程序。它可以是连接您本地文件系统的服务器，也可以是连接远程数据库或 Sentry、GitHub 等 API 的服务器。服务器可以运行在本地，也可以在远程云端。
MCP 客户端 (Client)：由主机为它连接的每一个服务器所创建的组件。它与一个服务器维持着一对一的专用连接，并负责两者之间的通信。

（整个流程是这样的：你的问题 → Claude Desktop (Host) → Claude 模型 → 需要文件信息 → MCP Client 连接 → 文件系统 MCP Server → 执行操作 → 返回结果 → Claude 生成回答 → 显示在 Claude Desktop 上。）

MCP 的详细工作流程基于客户端-主机-服务器架构，使用 JSON-RPC 2.0 协议通信，典型流程分为五个阶段：

初始化与握手 ：客户端发送 initialize 请求，包含协议版本和客户端能力；Server 返回支持的协议版本、服务器能力（如支持的工具、资源、提示列表）及元信息。随后客户端发送 initialized 通知，完成握手。
能力发现 ：客户端主动调用 tools/list、resources/list、prompts/list 方法，获取 Server 暴露的所有工具、资源和提示的详细定义（名称、描述、参数 schema 等）。Server 返回列表后，客户端将这些定义缓存并注入到 LLM 的上下文中。
请求处理 ：当用户输入后，LLM 根据工具定义决定调用哪个工具，并生成结构化参数。客户端将调用请求封装为 tools/call JSON 消息，发送给对应的 MCP Server。Server 执行实际操作（如查询数据库、调用 REST API），并将结果返回（以 text 或 resource 内容形式）。
响应与上下文更新：客户端接收 Server 返回的结果，将其作为新的消息追加到对话历史中，再次交给 LLM。LLM 根据结果生成最终回答或决定下一步调用。支持多轮工具调用链。
关闭与清理 ：会话结束时，客户端发送 shutdown 通知，然后关闭连接；Server 释放资源。对于 Stdio 传输，进程直接终止；对于 HTTP，连接关闭。

整个过程支持错误处理（如超时、参数错误返回 JSON-RPC 错误对象），并且 Server 可以主动发送资源更新通知（如 resources/updated）触发客户端重新拉取。MCP 通过标准化协议实现了 AI 与外部系统的动态、可互操作集成。

🔹 本质

产品或框架层的能力模块概念（非统一标准），将完成某项复杂任务所需的要素打包成可复用单元。

🔹 典型组成

一个 Skill 通常包含：

📦 常见载体：Agent 框架（LangGraph、CrewAI、Semantic Kernel）、Copilot Studio、GPTs 平台

🔹 特点

🎯 面向具体业务场景（如"生成月度财务报表"、"自动预订会议室"）

🧩 可组合、可编排、常带有工作流（Workflow）属性

🔒 通常绑定特定框架或产品生态，跨平台迁移成本较高

Skills 真正强大的地方在于它的渐进式加载（Progressive Disclosure）设计，业内常总结为"三层加载机制"：

启动注入层（Discovery，轻量级） ：Agent 启动时，扫描 Skills 目录（通常是 ~/.claude/skills/ 或自定义路径），只提取每个 Skill 的 name 和 description。这些信息被压缩后注入系统 Prompt（总 token 量可控，通常几百到一千多）。此时 LLM 只知道"我拥有这些能力"，但不了解细节。
意图匹配与激活层（Activation，按需加载）：用户输入任务后，LLM 根据 description 判断是否高度相关。一旦决定使用某个 Skill，就通过工具调用（tool calling）读取该 Skill 文件夹下的完整 SKILL.md。这时才把几千 token 的详细指令加载进上下文。
执行层（Execution，动态运行）：SKILL.md 里如果指定了脚本路径或执行命令，Agent 会动态运行 Python 脚本、调用外部 API、读取配置文件等。执行结果再回传给 LLM，继续后续推理或对话。

维度	Function Call	MCP	Skill
抽象层级	API 级（原子操作）	协议级（连接标准）	框架/产品级（能力模块）
解决什么问题	模型如何调用单个工具	模型如何标准化发现/调用/获取外部上下文	如何封装完整业务能力供 Agent/GPT 使用
互操作性	依赖具体厂商 API	跨模型、跨客户端、跨 Server	通常限定在特定框架或平台内
典型载体	JSON Schema + HTTP/Stream	Client/Server + JSON-RPC	YAML/Python 配置 + 工作流引擎
生命周期	单次请求/会话内	长期服务、可热更新、带权限管理	项目级配置，可版本化管理