一个越来越清晰的共识：Function Calling 是底层通电能力，MCP 是标准化的插头与插座，而 Skills 则是给模型塞进去的那本岗位操作手册。

在构建大语言模型（LLM）应用的过程中，开发者经常会碰到几个容易混淆的概念：Tool Use（或称 Function Calling）、MCP（模型上下文协议），以及最近越来越受关注的 Skills（技能）。

它们看起来都在做同一件事——让模型“调用外部能力”——但彼此之间的层级关系、设计目标和适用场景却截然不同。最近在一次技术探讨中，我得到一个非常精辟的类比，帮我彻底厘清了这三者的关系：

• Tool Use 是底层的通电机制
• MCP 是把电线做成标准化的插头与插座
• Skills 则是给模型塞进去的那本“操作说明书”

下面我们一层层拆解。

一、Tool Use / Function Calling：唯一的原生握手协议

无论是 OpenAI 最早提出的 function calling，还是 Anthropic 后来使用的 tool use，它们在本质上是同一件事：让大模型输出一个结构化、可被机器直接解析的调用请求，而不是输出纯文本。

• 解决问题：模型无法直接执行代码或调用 API，只能输出文字。Tool Use 让模型能够“说出一句标准格式的话”，例如 {"name": "get_weather", "arguments": {"city": "Beijing"}}。
• 作用位置：LLM 推理层的输出格式。
• 层级：最底层、最基础的交互机制。没有它，模型与外部世界之间就是一堵墙。

可以说，Tool Use 是整个工具调用生态的基石。但它只解决了“模型如何表达一个调用意图”，至于这个意图如何被执行、如何连接成百上千个不同工具、如何管理上下文——这些都不是它的职责。

二、MCP：把基石铺成标准化的轨道

MCP（模型上下文协议） 正是为了解决 Tool Use 留下的“连接与管理”问题而诞生的。

在实际工程中，每接入一个新工具（比如数据库、API、本地文件），都需要在应用层手写大量胶水代码：解析模型的 tool_calls、调用对应函数、处理异常、再将结果塞回模型。更麻烦的是，不同工具的参数格式、鉴权方式、返回结构千差万别，导致代码越写越臃肿，难以复用。

MCP 的做法是：在 Tool Use 之上，定义一套统一的协议规范。

• 它规定了如何描述一个工具（名称、参数、输入输出模式）
• 它规定了如何发现、连接、调用工具（类似 LSP 之于编辑器）
• 它让模型、MCP 客户端、MCP 服务端三方能够“即插即用”

用类比来说：Tool Use 是金属导线，MCP 则是 USB-C 接口标准。有了 MCP，开发者不再需要为每一个新工具重写对接逻辑；任何一个符合 MCP 协议的工具服务，都可以被任何兼容 MCP 的客户端（包括支持 Tool Use 的模型应用）直接调用。

所以你的判断非常准确：MCP 是构建在 Tool Use 基石之上的框架层与协议层。它没有替代 Tool Use，而是让它变得可规模化、可标准化。

三、Skills：塞给模型的岗位操作手册

如果说 Tool Use 和 MCP 解决的是连接外部能力的问题，那么 Skills 解决的是一个更高层的问题：如何让模型像一位熟练员工一样，按流程、按规范、按经验去完成一个复杂任务。

一个 Skill 往往包含：

• 一段精心设计的系统提示词（比如“你是 Excel 高级分析师，请按以下步骤处理数据……”）
• 一个或多个预定义的工具调用流程（比如先调用 read_table，再调用 clean_missing_values，最后调用 plot_chart）
• 以及约束、范例、错误处理策略等

Skills 并不引入新的底层调用机制——它底层仍然依赖 Tool Use 和 MCP 去实际执行函数。Skills 的本质是一份结构化的“操作说明书”，被注入到模型的上下文或系统消息中，用来引导模型的推理路径和工具选择策略。

你可以这样理解：

一个没有 Skill 的模型，就像一个刚入职、什么都会一点（有 Tool Use 能力）但不知道该先做哪一步的新人。
你给他一个 Skill，就相当于递给他一本《XX岗位标准作业流程手册》——里面写清楚了遇到什么问题该调哪个工具、先调谁后调谁、输出格式要怎样。
模型本身并没有获得“新能力”，但它获得了一份行为规范与任务拆解模板。

这也是为什么很多人把 Skills 看作 Agent 的轻量级实现，或者更准确地说——将专家经验以文本形态注入模型，从而复现可控、稳定、可复用的工作流。

四、一张表看清三者关系

层级	名称	核心作用	你的比喻（已升华）
底层机制	Tool Use / Function Calling	定义模型 如何输出调用指令	基础通电能力
框架协议	MCP	标准化 工具的描述、发现与连接	统一的插头与插座标准
应用策略	Skills	封装 任务流程、专家经验与行为约束	塞给模型的岗位说明书

五、为什么这个区分很重要？

在实际开发中，很多人会犯两类错误：

1. 过度抽象：认为 MCP 可以完全取代 Tool Use，试图在模型层绕过 function calling —— 这不可能，因为模型最终只认那几种结构化输出格式。
2. 混淆职责：把复杂的任务编排逻辑全部塞进 Tool Use 的参数定义中，导致工具列表极其臃肿，模型选错工具的概率飙升。

正确的做法是：

• 用 Tool Use 定义原子能力（例如 get_weather、query_database）。
• 用 MCP 统一管理这些原子能力的接入与生命周期，降低耦合。
• 用 Skills 将多个原子能力组合成面向业务的高阶行为，同时用提示词约束模型的执行顺序与判断逻辑。

底层能力靠 Tool Use，连接标准靠 MCP，智能行为靠 Skills——三者各司其职，共同构成当代 LLM Agent 系统的主干。

写在最后

技术术语的演变常常令人困惑：OpenAI 说 Function Calling，Anthropic 说 Tool Use，社区又冒出 MCP，紧接着 Skills 又开始被热炒。但当我们拨开命名的迷雾，会发现它们不过是在同一根技术树的不同分支上，生长出来的不同层次的解决方案。

你的发现——“Tool Use 是基石，MCP 是框架层，Skills 是说明书”——恰恰点出了这根技术树的完整结构。希望这篇博文能帮助更多开发者，在构建自己的 AI 应用时，不再被术语绕晕，而是清晰地知道：我到底应该在哪一层做哪件事。

---

如果你也有类似的洞察或在实际项目中遇到困惑，欢迎留言讨论。