Function Calling、MCP、Skill、Tool

先补一句术语说明：在 Anthropic / Claude 的官方文档里，更常见的说法是 Tool Use；而 Function Calling 更像是跨平台讨论时更常见的泛称。本文会把两者放在一起讨论，但默认都指“模型输出结构化调用请求”的这类机制。

最近看 AI Agent、Claude Code 和 MCP Server 相关内容时，我越来越觉得：这些概念本身并不难，难的是它们总在同一个场景里一起出现。

于是就很容易混成一团：

• 看到模型调用了一个能力，以为这就是 Function Calling。
• 看到一个 MCP Server 暴露了 tools，以为 MCP 就等于 Tool。
• 看到一个 /review-pr、/commit 这样的入口，又觉得 Skill 似乎也是 Tool。

它们表面上都在帮 AI “做事”，但拆开层级后，分工其实很清楚。

我现在更愿意先问一句：它们各自在回答什么问题？

先用一张表看清楚

如果只保留一个脑内速记版本，那就是：

Tool 是能力，Tool Use / Function Calling 是调用机制，MCP 是接入协议，Skill 是任务说明书。

为什么它们总让人觉得像一回事

因为在真实系统里，它们经常连着出现。

比如你对一个 Agent 说：

帮我读代码、查文档、修改文件、再顺手跑一下测试。

看起来是一句话，背后其实已经拆成了四层：

1. 系统先决定到底给模型开放了哪些 Tool。
2. 模型再用 Tool Use / Function Calling 的形式表达“我要调用哪个能力”。
3. 如果这些能力来自外部系统，它们可能是通过 MCP 接进来的。
4. 如果这类任务你经常做，还可以被封装成一个 Skill，以后直接复用。

也就是说，它们不是“同义词”，而是同一条链路里的不同零件。

用一个更顺手的比喻理解

如果把 AI Agent 想成一个刚入职的新同事，那这四个词会好理解很多：

• Tool：是你给他配的工具箱，里面有 IDE、终端、数据库查询器、浏览器。
• Tool Use / Function Calling：是他提交行动申请时用的标准表单，写清楚“我要用哪个工具、参数是什么”。
• MCP：是公司统一的接口标准，规定外部系统怎么接进来，谁都按这个标准说话。
• Skill：是团队内部沉淀出来的操作手册，比如“怎么做代码评审”“怎么发版本”“怎么排查线上问题”。

这个比喻不是百分之百严丝合缝，但足够帮助你在脑子里把四者分开。

它们之间到底是什么关系

可以把它们理解成一条从“抽象任务”到“真实执行”的链路：

用户提出任务
  ↓
Skill（可选）
把任务改写成一套更稳定的执行方法
  ↓
模型推理
判断要不要调用能力、调用哪个能力
  ↓
Tool Use / Function Calling
模型输出结构化参数，请求执行某个 Tool
  ↓
Tool
真正执行读文件、搜网页、查数据库、发请求等动作
  ↓
MCP（可选）
如果这个 Tool 来自外部系统，MCP 负责把它规范地接进来

这里之所以把 Tool Use 和 Function Calling 放在一起写，是因为不同平台的叫法并不完全一样。

• 在 Anthropic / Claude 的官方文档里，更常见的说法是 Tool Use。
• 在更泛化的跨平台语境里，很多人会用 Function Calling 来指代同一类机制。

两者在很多讨论里都指向同一件事：模型输出结构化调用请求，由外部系统去执行某个能力。

注意两点就够了：

• 不是每次都会同时出现四者。
• 它们不是互斥关系，而是组合关系。

一个很小的应用，也许只需要 Tool + Function Calling；一个更完整的 Agent 系统，则很可能四者一起上场。

1. Tool：模型真正能用的能力

先从最底层、也最容易理解的开始。

Tool 本质上就是“模型可请求使用的能力”。

它不一定非叫 tool，也可能叫函数、action、capability、operation，但只要本质是“给模型一项可执行能力”，那它就是同一类东西。

常见例子非常朴素：

• 读取本地文件
• 搜索代码
• 查询数据库
• 调用天气 API
• 发送邮件
• 打开网页
• 创建日历事件
• 执行 shell 命令

Tool 解决了什么问题

它解决的是一个根问题：

模型本身擅长生成文本，但不天然拥有“操作环境”的能力。

没有 Tool，模型通常只能：

• 解释
• 总结
• 推断
• 生成文本

有了 Tool，模型才从“会说”开始变成“能做”。

什么时候该优先想到 Tool

当你遇到下面这些需求时，几乎都应该先想到 Tool：

• 需要读取外部世界的信息，而这些信息不在上下文里
• 需要执行确定性的动作，而不是只靠模型猜
• 需要把“思考结果”落到真实环境中
• 需要让 Agent 真正完成任务，而不是停留在建议层

例如：

• “帮我找出项目里所有调用某个 API 的地方” → 需要搜索代码工具
• “帮我查询订单状态” → 需要查询业务系统的工具
• “帮我新建一个 issue” → 需要 GitHub 相关工具

Tool 的优势

Tool 的边界

Tool 只是“能力单元”，它本身并不回答这些问题：

• 模型怎么稳定地产生调用参数？
• 外部工具怎么统一接入？
• 一整类复杂任务怎么复用？

这三个问题，分别会继续走向 Tool Use / Function Calling、MCP、Skill。

2. Function Calling：让模型用结构化方式调用能力

很多人第一次接触 Function Calling 时，会把它和 Tool 混在一起。

这非常正常，因为它们总是一前一后出现。

但准确地说：

Function Calling 不是能力本身，而是模型表达“我要调用哪个能力、传什么参数”的机制。

也就是说：

• Tool 解决的是“你能做什么”。
• Function Calling 解决的是“你怎么把调用请求说清楚”。

一个最直观的例子

假设你给模型提供了一个天气查询能力：

{
  "name": "get_weather",
  "description": "查询城市天气",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string" },
      "date": { "type": "string" }
    },
    "required": ["city"]
  }
}

当用户说“帮我看看上海今天的天气”，模型理想情况下不应该只是回一句：

我建议调用天气接口，城市是上海，日期是今天。

因为这句话对人类友好，对程序却不够友好。

更理想的做法是，模型直接给出结构化调用请求：

{
  "tool": "get_weather",
  "input": {
    "city": "上海",
    "date": "today"
  }
}

这一步，就是 Tool Use / Function Calling 在发挥作用。

但如果把 Function Calling 只理解成“模型输出一段 JSON”，其实还差半步。

更完整的链路通常是：

1. 你先定义可用 tool 的名称、说明和参数 schema。
2. 客户端把这些定义提供给模型。
3. 模型判断当前问题要不要调用 tool。
4. 如果要调用，模型按 schema 生成结构化参数。
5. 客户端或 runtime 解析这次调用请求。
6. runtime 校验参数是否合法，再真正执行函数或 tool。
7. tool 执行结果返回给模型。
8. 模型基于结果继续回答，必要时进入下一轮调用。

所以更严谨的说法是：

Function Calling 不只是“生成结构化参数”，而是“模型和外部程序围绕一次工具调用协作完成任务”的整条链路。

这里再补一个容易混淆的点：

• schema 的作用是约束和引导模型怎么构造参数。
• 真正的严格校验，通常仍然发生在模型外部的 runtime。

也就是说，模型通常会尽量按 schema 生成参数，但并不是“有了 schema 就绝对不会出错”。

Function Calling 解决了什么问题

它真正带来的价值主要有三点：

• 让模型少自由发挥，多按格式输出
• 让参数更稳定、更可解析
• 让调用结果更容易进入程序流程

很多传统 prompt engineering 的痛点，本质上都和这里有关：模型会“理解你的意图”，但不一定“按程序需要的结构把事说清楚”。

Function Calling 的作用，就是把这一步从“靠猜”变成“靠 schema 引导 + runtime 校验”。

什么时候该优先想到 Function Calling

当你遇到这些情况时，它通常很值得上：

• 你已经有一组函数/工具，想让模型自动选择调用
• 你需要稳定拿到参数，而不是自然语言描述
• 你想降低 prompt parsing 的脆弱性
• 你在做 AI 应用后端，希望模型输出能直接进入业务逻辑

Function Calling 的优势

Function Calling 不是什么

它不是：

• 一个外部协议
• 一个工具市场
• 一个工作流系统
• 一个知识库接入方案

换句话说，Function Calling 只负责“怎么调用”，不负责“能力从哪来”和“整套任务怎么组织”。

3. MCP：把外部能力与上下文以统一协议接进来

如果说 Function Calling 解决的是“模型如何发起调用”，那 MCP 解决的就是另一个更工程化的问题：

这些外部能力与上下文，到底怎么被规范地接入模型客户端或 Agent 系统？

MCP（Model Context Protocol）本质上是一种标准化接入协议。

它的目标不是替代 Tool，也不是替代 Function Calling，而是让外部系统能以统一方式向 AI 客户端暴露：

• tools
• resources
• prompts
• 以及相关元数据

你可以把它理解成：

• Tool 是“具体能力”
• MCP 是“把这些能力和上下文接进来的标准插座”

也因此，下面这几个说法要分开看：

• Tool 是能力本身。
• MCP tool 是“通过 MCP 协议接进来的 tool”。
• MCP server 是提供这些 tool / resource / prompt 的服务端。

换句话说，MCP 不是 tool 的同义词，而是 tool 的一种接入方式。

MCP 里的 resources 和 prompts 到底是什么

前面说 MCP 不只会暴露 tool，这里最容易被忽略的其实是 resources 和 prompts。

可以先粗略记成：

• tool 负责“做事”
• resource 负责“给上下文”
• prompt 负责“给任务模板”

其中：

• resource 更像一份可读取的上下文对象，通常偏只读，比如文档、文件、数据库 schema、目录索引、某个对象详情。
• prompt 更像一个参数化的任务入口或提示模板，用来告诉模型“这类任务通常应该怎么开始”。

它们在链路里的位置也不一样：

1. prompt 更靠前，常常充当任务入口或模板化起手式。
2. resource 更像中途补充给模型的资料，让模型先看材料再决定回答或调 tool。
3. tool 则负责真正执行搜索、修改、查询、提交之类的动作。

举一个简单的假想例子，假设有一个 docs-mcp：

• tools：search_docs(query)、open_doc(doc_id)、ask_doc(question, doc_id)
• resources：docs://index、docs://api/auth、docs://db/schema
• prompts：summarize_doc(doc_id)、onboard_new_dev(topic)

如果用户问“这个项目的认证流程怎么走”，一个自然流程可能是：

1. 客户端先读取 docs://index 和 docs://api/auth 这些 resource。
2. 模型拿到资料后，必要时再调用 ask_doc 这类 tool 继续追问。
3. 如果用户要“把认证文档总结成 onboarding 风格”，那就可以从 onboard_new_dev 这样的 prompt 起手。

所以：

• resource 不是动作，而是资料。
• prompt 不是能力本身，而是模板化入口。

如果把它和 Skill 对比，最准确的说法通常是：

MCP prompt 更像一个轻量级任务模板，接近 skill 的一个组成件，但通常不等于完整的 skill。

为什么会需要 MCP

如果没有 MCP，不同工具提供方、不同客户端、不同集成方式，通常都各有一套：

• 认证方式不同
• 参数描述不同
• 工具发现方式不同
• 返回格式不同
• 接入代码大量重复

短期看，似乎都能跑；长期看，问题会越来越明显：

• 一个工具难以在多个客户端之间复用
• 客户端集成成本越来越高
• 工具生态很难扩展
• 每接一次新系统，都要重新打一遍胶水

MCP 的价值就体现在这里：它不是给你增加一个新概念，而是在帮你减少一堆私有概念。

MCP 和 Tool Use / Function Calling 的关系

这也是最常见的混淆点之一。

很多人会把 MCP 和 Function Calling 混在一起，原因很简单：它们经常前后脚出现。

但更准确地说：

• MCP 负责“把能力接进来”。
• Tool Use / Function Calling 负责“让模型把调用请求表达出来”。

一个很典型的调用链路是：

用户输入
  ↓
客户端把可用 tools（含 MCP 提供的 tools）告诉模型
  ↓
模型判断是否需要调用 tool
  ↓
模型按 schema 生成结构化参数
  ↓
客户端执行调用
  ↓
如果这是 MCP tool，就把请求转发给 MCP server
  ↓
MCP server 返回结果
  ↓
客户端再把结果喂回模型
  ↓
模型继续回答

所以更严谨的说法应该是：

MCP 决定能力怎么接入，Tool Use / Function Calling 决定能力怎么被调用。

二者不是替代关系，而是经常串联出现。

MCP server 的执行位置，不等于“是不是内置 tool”

在实际使用里，很多人还会把“本地 MCP”误听成“宿主内置 tool”，这也不太准确。

更准确的区分方式是：

• 内置 tool：由客户端自身实现和执行。
• stdio MCP tool：客户端启动一个本地 MCP server 子进程，通过 stdin/stdout 和它通信；tool 由这个 server 进程执行。
• 远程 HTTP / SSE MCP tool：客户端通过网络连接一个独立运行的 MCP server；tool 由远程 server 执行。

也就是说：

• stdio 和 HTTP / SSE 的主要区别是传输方式与 server 所在位置。
• 不管是哪种 transport，真正执行 MCP tool 的始终是 MCP server。

这点特别重要，因为它能帮你把下面两组概念彻底分开：

• 内置 tool vs MCP tool：这是“能力来源”的区别。
• stdio vs HTTP / SSE：这是“MCP server 怎么连接”的区别。

什么时候该优先想到 MCP

下面这些场景，很适合用 MCP 来组织能力接入：

• 你要把现有系统能力开放给 AI 客户端使用
• 你不只服务一个 Agent，而是希望多个客户端都能接
• 你要接第三方系统，希望用统一协议管理
• 你想做可插拔的工具生态，而不是维护一堆私有脚本

比如：

• 给数据库、文档库、内部知识库做统一 AI 接入
• 给 GitHub、Notion、Jira、浏览器自动化等系统做统一扩展层
• 让 Claude Code、桌面客户端、IDE 插件共享同一批外部能力

MCP 的优势

MCP 的边界

MCP 很强，但也不是“凡有工具就上 MCP”。

如果你的场景只是：

• 单个应用内部的 1~2 个函数
• 只有一个后端服务自己调用
• 不存在跨客户端复用需求

那直接本地定义 Tool + Function Calling，往往更简单。

所以我更愿意把 MCP 看成：

当工具体系开始长大时，用来把接入方式做标准化的一层。

它通常不是最小系统的第一步，但非常可能是中大型系统的必经之路。

stdio、SSE 与 Streamable HTTP 补充说明

如果你最近刚开始接触 MCP transport，还会经常看到 stdio、SSE、HTTP 这些词。

这里最容易产生的误解是：

SSE 是“外部执行”，stdio 是“宿主内部执行”。

这个说法并不准确。

更准确地说：

• stdio 通常表示：客户端把 MCP server 当作本地子进程启动，通过标准输入输出传输 JSON-RPC 消息。
• HTTP / SSE 通常表示：客户端通过网络和一个独立运行的 MCP server 通信。

但无论哪种：

执行 tool 的始终是 MCP server，不是模型本身。

你可以把三种常见情况放在一起理解：

顺手补一句：在较新的 MCP 文档里，远程传输更常看到 Streamable HTTP；而 SSE 更多出现在兼容或流式场景里。你可以先把它们粗略理解成“远程网络 transport”。

这样记最不容易乱：

• 内置 vs MCP：看能力是不是通过 MCP 接入。
• stdio vs HTTP / SSE：看 MCP server 是怎么连接的。

4. Skill：把一类任务沉淀成可复用指令封装

前面三个概念，基本都在讲“能力”和“接入”。

而 Skill 解决的，是另一个特别务实的问题：

同一种复杂任务我总在反复做，能不能不要每次都从头讲一遍？

Skill 本质上是面向某类任务的可复用指令封装。

它往往会把这些东西打包在一起：

• 一段面向特定任务的提示词
• 一套推荐执行顺序
• 一些约束与检查点
• 需要时调用哪些工具
• 任务完成时应该输出什么

在 Claude Code 这类环境里，你完全可以把 Skill 理解成：

某类任务的专用操作手册 / playbook + 快捷入口。

它更像是一份可复用的任务说明书：本身主要提供指令、约束和上下文，必要时再由 Claude 去调用工具、子代理或命令完成执行。

Skill 和 Tool 最大的区别

很多人会把 Skill 和 Tool 混掉，原因是它们最后都会“帮助模型完成任务”。

但两者关注的粒度并不一样：

一句更形象的话是：

• Tool 是螺丝刀。
• Skill 是“什么时候拿哪把螺丝刀、先拆哪、后装哪”的经验包。

什么时候该优先想到 Skill

当这些事情反复出现时，Skill 的价值就会非常高：

• PR review
• 代码重构检查
• 生成 release note
• 排查构建失败
• 按固定风格写文章
• 根据仓库规范执行一类常见任务

这类任务通常都有几个共同点：

• 不是一个动作就能完成
• 需要多步判断
• 有比较稳定的套路
• 每次从零写 prompt 很浪费

Skill 的优势

Skill 的边界

Skill 不是协议，也不是底层调用机制。

它不负责：

• 定义标准网络通信协议
• 替代工具调用 schema
• 凭空创造能力

如果没有 Tool，Skill 也可能只能指导模型“怎么想”，却不一定真的“怎么做”。

所以很多时候，Skill 是站在 Tool 之上的复用层，而不是它的替代品。

最容易混淆的几个点

放到 Claude Code 里看，就更不容易混了

如果你最近正好在用 Claude Code，那这四者的关系就很适合拿来做实战理解。

场景一：你让 Claude 帮你看代码

比如你说：

帮我找一下项目里处理文章 frontmatter 的地方。

Claude Code 可能会去调用：

• Glob 找文件
• Grep 搜关键词
• Read 读具体文件

这时候：

• Glob、Grep、Read 是 Tool。
• 模型决定“现在该调哪个工具、传什么参数”，这是 Tool Use / Function Calling。
• 如果这些工具都是本地内置的，那这里不一定涉及 MCP。
• 如果你把这类“代码定位 + 阅读 + 总结”的任务封装成一个固定入口，那它就可以继续抽象成 Skill。

场景二：你接了外部 MCP Server

比如你把 GitHub、Notion、Jira、数据库，或者某个内部平台，通过 MCP Server 接进 Claude Code。

那么这时：

• 这些外部系统暴露出来的查询能力、操作能力，仍然会以 Tool 的形式被模型看到。
• 但这些 Tool 的来源，不再只是 Claude Code 本地内置能力，而是通过 MCP 协议接进来的能力。
• 模型后续依然要通过 Tool Use / Function Calling 去调用它们。

也就是说，MCP 决定“工具怎么进来”，Tool Use / Function Calling 决定“工具怎么被调起来”。

这两个概念经常一起出现，但关注点并不相同。

场景三：你执行 /review-pr、/commit 这样的能力

在 Claude Code 里，这一类入口很适合拿来理解 Skill。

它们通常不是“单个动作”，而是某类任务经验的打包：

• 先检查当前状态
• 再读取必要信息
• 再决定要不要运行命令
• 最后按固定格式输出结果

这个过程中，它底层依然可能调用很多 Tool：

• 读文件
• 查 diff
• 跑 git 命令
• 搜代码

但你作为使用者，不需要每次都重新描述“先做什么、再做什么、输出要长什么样”。

这就是 Skill 的价值：它把重复出现的一整类任务，变成了一个可直接触发的复用入口。

需要注意的是，Claude Code 里以 / 开头的入口并不一定全都属于同一种机制：有些是内建命令，有些则是 skill 提供的入口。

把四者放进同一个 Claude Code 工作流

假设你要做一次完整的代码审查，过程可能像这样：

1. 你触发 /review-pr。
2. /review-pr 这个入口本身，可能体现的是 Skill。
3. Skill 执行过程中，Claude 会去调用 Read、Grep、Bash 等 Tool。
4. 每次调用具体 Tool 时，模型都要产生结构化调用请求，这对应 Tool Use / Function Calling。
5. 如果其中有一部分能力来自 GitHub MCP Server 或公司内部平台的 MCP Server，那么这些能力的接入方式就是 MCP。

到这里你会发现，四者不是竞争关系，而是正好拼成了一条完整链路。

再看一个更完整的 Claude Code 例子

如果把场景换成“帮我给这个博客写一篇新文章”，链路会更清楚。

假设我接到的任务是：

在 content/posts/2026 下新写一篇文章，先参考 runbook，再按现有博客风格输出。

一个比较自然的执行过程会是：

1. 先用 Glob 找到内容规范和同年份文章。
2. 再用 Read 阅读 docs/runbooks/content/... 和现有文章。
3. 如果需要补充定位某些字段，再用 Grep 查 frontmatter 或 schema。
4. 整理完结构后，用 Write 或 Edit 写入新文章。
5. 如果用户还要求继续润色，就再次读文件、编辑文件，循环完成。

把这套过程拆开看：

• Glob、Read、Grep、Write、Edit 都是 Tool。
• 模型每次决定“接下来用哪个工具、传什么路径、读哪些内容”，这是 Tool Use / Function Calling。
• 如果其中某个能力不是本地内置，而是来自外部接入的内容系统或知识库，那它可能通过 MCP 提供。
• 如果“按博客规范写文章”这件事被沉淀成一个固定入口，比如 /write-post，那这套写作流程就可以被抽象成 Skill。

也就是说，当你在 Claude Code 里感觉“它好像在一边思考一边调工具”，其实背后不是一个概念在工作，而是这四层可能同时在配合。

真正实战时，到底怎么选

如果你在做 AI 应用、Agent、Claude Code 扩展，最实用的不是背定义，而是学会按问题选层。

场景一：我只想让模型调用我写的几个函数

选：Tool + Tool Use / Function Calling

这是最常见、也最轻的起步方式。

适合：

• 业务系统里的结构化查询
• 简单自动化
• 单应用内部能力调用

场景二：我想把外部系统能力标准化接入

选：MCP + Tool + Tool Use / Function Calling

适合：

• 你要接多个系统
• 你想让不同客户端共享同一套能力
• 你不想每接一个工具都重新写私有集成

场景三：我总在重复做同一类复杂任务

选：Skill

如果这类任务还需要真实操作，再在 Skill 下面调用 Tool。

适合：

• 固定风格写作
• 固定流程审查
• 固定套路排障
• 团队内重复出现的高频任务

场景四：我在 Claude Code 里写个 MCP Server，该怎么理解

这时最适合用一组连贯关系来想：

• 你写出来的服务器，本质是在通过 MCP 暴露能力。
• 这个服务器暴露出来的某个“查 issue”“读知识库”“触发部署”的能力，会表现成 Tool。
• 模型实际调用这些能力时，仍然需要产生结构化参数，这对应 Tool Use / Function Calling。
• 如果你后来又把“发布前检查”“日报生成”“PR 初筛”这些常见流程封成固定入口，那就是 Skill。

换句话说，“我在写 MCP Server” 这句话，本身更偏接入层；“Server 里具体开放了哪些能力”，才是在讲 Tool。

场景五：我只是泛泛地说“AI 可以用哪些能力”

这时说 Tool 就够了。

因为这是最上层、也最通用的说法。

一个我自己觉得最好记的选型顺序

如果你是从零设计一个 Agent，可以按这个顺序思考：

1. 先问有没有真实执行能力需求 如果有，就先定义 Tool。
2. 再问是否需要稳定的结构化调用 如果需要模型自动选工具、自动传参，就考虑 Tool Use / Function Calling。
3. 再问是否需要跨客户端或外部系统统一接入 如果需要，就考虑用 MCP 做标准化接入。
4. 最后问是否存在高频重复任务需要沉淀 如果有，就把“提示词 + 步骤 + 工具选择经验”整理成 Skill。

这个顺序很重要，因为它说明：

• Skill 通常建立在 Tool 之上。
• MCP 通常服务于 Tool 的接入。
• Tool Use / Function Calling 通常服务于 Tool 的调用。

用一句话区分四者

如果你只想在脑子里留一个最短版本，可以记成下面这样：

推荐继续读什么

如果你准备继续往下看，我会建议按这个顺序读：

1. 先看 Tool use，把“模型怎么调用能力”这件事彻底搞明白。
2. 再看 MCP，理解“这些能力怎么被标准化接入”。
3. 然后看 Claude Code Skills，理解“任务是怎么被沉淀和复用的”。
4. 最后再回来看你自己的场景：你现在缺的到底是能力、调用、接入，还是复用。

很多时候，一旦顺序反了，就很容易在还没把 Tool 和 Tool Use / Function Calling 分清之前，先被 MCP 或 Skill 这些更上层概念绕晕。

最后

Function Calling、MCP、Skill、Tool 之所以总被混在一起，不是因为它们定义不清，而是因为它们经常在同一个系统里一起工作。

但只要你按层去看，就不会乱：

• Tool 负责提供能力。
• Tool Use / Function Calling 负责发起结构化调用。
• MCP 负责标准化接入外部能力。
• Skill 负责沉淀一类任务的复用流程。

所以它们不是四选一，而更像四块能拼在一起的积木。

系统越复杂，越可能四块都用上；系统越简单，越可能只需要其中两块。

真正重要的从来不是背下术语，而是判断清楚：你现在解决的，到底是能力问题、调用问题、接入问题，还是复用问题。

如果哪天你又把这四个词看混了，也不用慌，回到最朴素的四个问题就行：

• 我现在是在讨论“能做什么”吗？那大概率是 Tool。
• 我现在是在讨论“怎么调起来”吗？那大概率是 Tool Use / Function Calling。
• 我现在是在讨论“怎么接进系统里”吗？那大概率是 MCP。
• 我现在是在讨论“怎么把一整类任务复用起来”吗？那大概率是 Skill。

这样一来，基本就不会再乱了。