从 API 调用看清楚：MCP、Skill、Function Calling、Tools 三者什么关系

Open Table of contents

一句话结论
1. 背景与问题
2. 核心概念
- 2.1 概念总表
- 2.2 三层结构图
3. 主体内容
4. 实践案例
- 4.1 案例一：企业知识助手怎么组合这三层
- 4.2 案例二：什么时候根本不需要 MCP
5. 对视频的精炼改写版结论
6. 核心结论
- 6.1 最值得记住的 5 句话
- 6.2 面向实践的使用建议
7. 可继续长大的知识节点
8. 参考与检索来源

一句话结论

这四个词经常一起出现，但并不处在同一层级。
更稳妥的理解方式是：

执行层：Function Calling / Tools / tool use

接入层：MCP

策略层：Skill

视频的主线判断 基本成立，但按 2026 年的官方资料补齐后，需要做三处关键修正：

Skill 不只是“一份 Markdown 策略文档”，更准确地说，它已经演进为一种可复用的工作流/能力包，可包含指令、资源、脚本与元数据。[^anthropic-skills][^openai-skills]
MCP 不只接“工具”，还可暴露 tools / resources / prompts，并带有 transport、auth、approval、security 等协议层能力。[^mcp-intro][^mcp-arch][^mcp-tools]
“模型只返回调用意图，宿主程序负责执行” 对“自定义函数”是对的，但放到 2026 的平台语境里要补一句：有些工具会在平台侧执行，例如 Anthropic 的 server tools，以及 OpenAI 的 built-in tools / remote MCP。[^openai-fc][^anthropic-tool-use][^openai-responses]

1. 背景与问题

这段视频试图回答一个很典型的问题：

为什么大家总把 Function Calling、Tools、MCP、Skill 混在一起谈？
为什么会出现 “MCP vs Skill 谁更强” 这种看起来很热闹、其实不太对位的争论？
从模型 API 调用视角看，这几个概念到底分别解决什么问题？视频给出的核心判断是：这些概念混乱，不是因为定义太难，而是因为层级混了。

📡 扩展
OpenAI 现在把 function 明确视为 tool 的一种；Anthropic 则统一使用 tool use 这一术语。与此同时，MCP 官方把自己定义为“连接 AI 应用与外部系统的开放标准”，而不是“模型能力增强器”。这说明今天更稳妥的说法已经从“函数调用”逐渐转向更宽的“工具调用 / tool use”。[^openai-fc-guide][^anthropic-tool-use][^mcp-intro]

2. 核心概念

2.1 概念总表

概念	所属层级	它解决的问题	模型直接看到什么	谁负责真正执行	更准确的理解
Function Calling	执行层	让模型产出结构化调用意图	工具名、描述、参数 schema	你的应用，或平台侧工具运行时	一种“让模型发起动作”的机制
Tools / tool use	执行层	对“可调用能力”的更通用称呼	tool 定义、tool schema、tool result	同上	`function` 往往只是 `tool` 的一个子类
MCP	接入层	把外部能力标准化接入模型系统	来自 MCP 的工具/资源/提示模板	Host / Client / Server 协同	是协议与接入标准，不是推理增强剂
Skill	策略层	让模型按既定方法做事	技能元数据、被加载的技能内容	模型按技能指引决策，必要时再调工具	是可复用工作流/能力包，不是新协议

2.2 三层结构图

flowchart TD
    U([用户任务]) --> S[策略层：Skill<br>决定怎么思考、如何拆解任务]
    S --> A[接入层：MCP / 直接工具注册<br>把外部能力接进系统]
    A --> E[执行层：Tools / Function Calling<br>发出结构化调用]
    E ==> R[运行时执行<br>应用侧 或 平台侧]
    R ==> M([结果回流模型])
    M ==> O([最终回答])

    style S fill:#ede7f6,stroke:#673ab7,stroke-width:2px
    style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style E fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style R fill:#ffebee,stroke:#e53935,stroke-width:2px
    style O fill:#e8f5e9,stroke:#43a047,stroke-width:2px

读图方式：

Skill 决定“怎么干”

MCP 决定“怎么把能力接进来”

Tools / Function Calling 决定“模型怎样发起调用”

3. 主体内容

3.1 执行层：Function Calling / Tools 到底是什么

视频对最底层的解释是对的：模型本身并不直接“动手”，它先看到你提供的工具定义，然后返回一个结构化调用请求。
在最经典的调用回路里，顺序是：

你的程序把 tools 发给模型
模型返回某个工具调用意图
你的程序执行这个调用
你的程序把结果再喂回模型
模型继续推理并输出回答

这就是最标准的 tool calling / function calling loop。

sequenceDiagram
    participant User as User
    participant App as Host App
    participant Model as Model
    participant Tool as Tool Runtime

    User->>App: 提出任务
    App->>Model: messages + tools
    Model-->>App: tool call（结构化调用意图）
    App->>Tool: 按参数执行工具
    Tool-->>App: tool result
    App->>Model: tool result 回传
    Model-->>App: 最终回答
    App-->>User: 输出结果

这也是为什么视频会强调：模型负责决策，不一定负责执行。

但这里有一个需要补强的 2026 版细节：

对 OpenAI custom functions、Anthropic client tools 来说，执行方通常确实是你的应用。[^openai-fc-guide][^anthropic-tool-use]
但对 Anthropic server tools、OpenAI built-in tools、OpenAI remote MCP 等情况，执行方可以是平台侧。[^anthropic-tool-use][^openai-fc-guide][^openai-responses]

因此，更精确的说法应当是：

工具调用的本质是：模型发起结构化调用；执行可以发生在应用侧，也可以发生在平台侧。

📡 扩展
OpenAI 文档现在明确区分：function 是一种特定类型的 tool，而平台还存在 built-in tools 与 remote MCP；Anthropic 也区分了 client tools 与 server tools。也就是说，今天的 Tools 是总称，Function Calling 更像历史上更具体的一支。[^openai-fc-guide][^anthropic-tool-use]

3.2 Function Calling 和 Tools 是不是两回事

视频的判断方向是对的：在很多讨论里，这两个词指向的是同一类机制，只是厂商命名与时代上下文不同。

但把它说得更严格一些：

在 OpenAI 当前文档里，function 是 tool 的一个具体类型。[^openai-fc-guide]
在 Anthropic 文档里，整体概念通常叫 tool use。[^anthropic-tool-use]
因而实务上可以说：
- 广义：大家在谈的通常都是“工具调用能力”
- 狭义：function calling 是 tools 体系里的某一种具体实现/命名

这能解释为什么很多人会觉得两个词“像一回事”，但在官方定义上又并非完全同义。

说法	更适合的语境	备注
Function Calling	讨论 OpenAI 历史 API、结构化函数参数时	术语更窄
Tools / Tool Use	讨论通用 agent 架构、跨厂商比较时	术语更宽、更现代

📡 扩展
OpenAI 还提供了 strict: true 的结构化输出能力，用于保证函数参数严格匹配 JSON Schema；Anthropic 也提供 strict tool use。说明今天“工具调用”已不只是“能不能调”，而是进入了“能否稳定、可验证、可生产化地调”的阶段。[^openai-fc][^anthropic-tool-use]

3.3 接入层：MCP 解决的不是“调用”，而是“接入标准化”

视频最重要的贡献之一，是把 MCP 放回了它更合适的位置：接入层。

没有 MCP 的时候，一个应用如果要把外部系统接给模型，往往要自己维护这些事情：

工具定义
参数 schema
执行逻辑
认证方式
多个系统之间的重复接线

结果就是：工具提供方 与 工具消费方 强耦合。

而 MCP 的价值在于：它把这些连接动作标准化了。
MCP 官方的定义是：它是一个开放协议，用来把 AI 应用连接到外部系统。[^mcp-intro][^mcp-spec]

更进一步，按官方文档，MCP 不只覆盖“工具”：

tools：供模型发起动作
resources：供模型获取上下文数据
prompts：供系统复用提示模板/交互模板

flowchart TD
    H[Host 应用<br>如 ChatGPT / Claude / IDE] --> C[MCP Client]
    C <--> S[MCP Server]
    S --> T[Tools]
    S --> R[Resources]
    S --> P[Prompts]

    style H fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style S fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
    style T fill:#e8f5e9,stroke:#43a047,stroke-width:2px
    style R fill:#e8f5e9,stroke:#43a047,stroke-width:2px
    style P fill:#e8f5e9,stroke:#43a047,stroke-width:2px

官方架构还补上了视频里没展开的几件关键事：

MCP 采用 JSON-RPC 2.0 风格的数据交换层。[^mcp-arch]
支持 stdio 与 streamable HTTP 两类 transport。[^mcp-arch]
MCP server 可声明工具能力、列出工具、通知工具列表变化。[^mcp-tools]
安全上强调 用户同意、最小暴露、批准执行、人类在环。[^mcp-spec][^mcp-tools]

因此，把 MCP 简化成“工具同步机制”并不算错，但还不够完整。
更准确的说法是：

MCP 是一套把外部能力与上下文，以标准协议方式接入 AI 应用的机制。

📡 扩展
Anthropic 的 Managed Agents 文档给出了更具体的接法：你可以在 agent 定义里声明 mcp_servers，再通过 mcp_toolset 暴露给 agent；OpenAI 的 Responses API 和 Apps SDK 也已经把 remote MCP / MCP server 纳入官方能力面。[^anthropic-mcp-connector][^openai-responses][^openai-apps]

3.4 策略层：Skill 影响的是“怎么做”，不是“怎么连”

视频把 Skill 解释为“策略文档”，这是一个很适合入门理解的说法。
但如果你要把它写进长期知识库，建议升级为：

Skill 是一种可复用的工作流封装/能力包，用来告诉模型：面对某类任务，应该按什么方法、顺序、规则和边界来处理。

为什么要这么改？

因为到 2026 年，官方资料已经明显超出了“只有一个 Markdown 文件”的范围：

Anthropic Agent Skills：可作为 pre-built skills 或 custom skills 使用；依托 Claude 的 VM/container 环境运行，内容可包含 instructions、可执行代码、参考材料等。[^anthropic-skills]
OpenAI Codex Agent Skills：技能目录可包含 SKILL.md、scripts、references、assets、agents/openai.yaml 等；而且采用 progressive disclosure，先加载元数据，需要时再加载全文。[^openai-skills]

所以，视频说 Skill“通常就是一个 Markdown 文件”并不是完全错，而是把当前更成熟的形态说得过于朴素了。

flowchart TD
    A([任务到来]) --> B{是否匹配某个 Skill}
    B -- 是 --> C[加载 Skill 元数据/正文]
    C --> D[按 Skill 拆解步骤]
    D --> E[必要时调用 Tools / MCP 能力]
    E --> F([完成任务])
    B -- 否 --> G[直接按通用推理处理]
    G --> F

    style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style B fill:#fff8e1,stroke:#f9a825,stroke-width:2px
    style C fill:#ede7f6,stroke:#673ab7,stroke-width:2px
    style D fill:#ede7f6,stroke:#673ab7,stroke-width:2px
    style E fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style F fill:#e8f5e9,stroke:#43a047,stroke-width:2px
    style G fill:#f5f5f5,stroke:#616161,stroke-width:2px

📡 扩展
Anthropic 文档把 Skill 描述为能“specialize Claude”“reduce repetition”“compose capabilities”的机制；OpenAI Codex 则明确写到：skill 打包 instructions、resources、optional scripts，用来让工作流可复用且可靠。由此看，Skill 的本质更接近“流程知识 + 执行约束 + 可选辅助资源”的组合。[^anthropic-skills][^openai-skills]

3.5 为什么 “MCP vs Skill” 是个错位问题

如果用视频的三层框架看，“MCP vs Skill” 之所以常常越聊越乱，是因为它们回答的是不同问题：

你在问什么	该看哪一层	更相关的概念
模型怎么发起外部动作？	执行层	Function Calling / Tools
外部系统怎么统一接入？	接入层	MCP
模型该按什么方法完成任务？	策略层	Skill
为什么同一套工具在不同团队里表现差异很大？	策略层 + 执行层	Skill + Tool definition
为什么工具一多就贵、还容易乱调？	接入层 + 上下文管理	MCP / Tool Search / Skill progressive disclosure

所以更准确的对比不是 “MCP vs Skill”，而是：

MCP：偏“能力接线层”
Skill：偏“方法论沉淀层”

两者常常叠加，但不是替代关系。

📡 扩展
OpenAI Codex 文档甚至直接写了 “Skills + MCP together”：skills 定义可复用工作流，MCP 连接外部工具与系统；如果 skill 依赖 MCP，还可以在元数据里声明这种依赖。这个表述几乎就是对视频主张的官方背书。[^openai-skills]

3.6 Token 成本与上下文管理：为什么这件事在工程上很重要

视频提到一个很实务的点：MCP 工具多了以后，schema、description、tool name 会持续占上下文。

这个判断在 2026 年不但成立，而且更明显了。Anthropic 官方工程文章给出的数据是：

一个五服务器场景下，58 个工具定义可吃掉约 55K tokens
实际项目里甚至见过 134K tokens 的工具定义开销
他们的优化方向之一，就是按需发现工具，而不是一上来全量塞入上下文[^anthropic-advanced-tools]

OpenAI 这边也已经把 tool search 明确成官方能力：
模型可以先搜索、再按需加载工具，从而避免一次性把所有工具定义都塞进上下文。[^openai-tool-search]

而在 Skill 侧，OpenAI Codex 也明确采用了 progressive disclosure：

常驻上下文的是 skill metadata
真正需要时再加载 SKILL.md 详细内容[^openai-skills]

因此，视频关于“Skill 常常更省 token”的结论方向是对的，但建议改写得更严谨一点：

当一类知识主要是“流程经验 / 决策规范 / 方法模板”而不是“外部能力定义”时，Skill 往往更适合做上下文管理；当你需要真正连接外部系统时，仍然需要 tools / MCP。

3.7 一张决策图：什么时候该用 Tool、MCP、Skill

flowchart TD
    A([新需求]) --> B{是否需要访问外部数据<br>或执行外部动作}
    B -- 否 --> C{是否存在可复用流程/规范}
    C -- 是 --> D[优先建 Skill]
    C -- 否 --> E[普通 Prompt / Agent Instructions 即可]

    B -- 是 --> F{外部能力是否需要标准化接入<br>跨应用复用 / 动态发现}
    F -- 是 --> G[优先考虑 MCP]
    F -- 否 --> H[直接注册 Tools / Functions]

    G --> I{是否还需要稳定的方法论<br>触发规则 / 步骤约束}
    H --> I
    I -- 是 --> J[在 Tool/MCP 之上叠加 Skill]
    I -- 否 --> K[只保留接入与调用层]

    D ==> L([结果：方法优先])
    E ==> L
    J ==> L
    K ==> L

    style D fill:#ede7f6,stroke:#673ab7,stroke-width:2px
    style G fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style H fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
    style J fill:#e8f5e9,stroke:#43a047,stroke-width:2px

4. 实践案例

4.1 案例一：企业知识助手怎么组合这三层

任务：
“帮我总结过去一周线上事故，并给出一份对业务方可读的简报。”

一种常见落地方式：

Skill：定义“事故复盘简报”的方法
- 先查事故
- 再抽取影响范围
- 再生成面向业务方的摘要
- 最后输出固定模板
MCP：连接 Jira、Slack、Confluence、监控系统
Tools / Function Calling：实际发起 search_incidents、read_postmortem、fetch_metrics 等调用

sequenceDiagram
    participant User as 用户
    participant Agent as Agent / Model
    participant Skill as Skill
    participant MCP as MCP Client/Runtime
    participant Sys as Jira/Slack/Confluence

    User->>Agent: 总结过去一周事故并输出简报
    Agent->>Skill: 命中“事故复盘简报”技能
    Skill-->>Agent: 给出步骤、模板、输出标准
    Agent->>MCP: 请求访问相关系统能力
    MCP->>Sys: 调用搜索/读取接口
    Sys-->>MCP: 返回事故记录、文档、指标
    MCP-->>Agent: 返回可用上下文与结果
    Agent-->>User: 输出结构化简报

这个案例里：

没有 Skill，模型也许能做，但输出风格与步骤不稳定
没有 MCP，你可能要手写大量接线代码
没有 Tools / tool use，模型就拿不到外部数据

三者不是互斥，而是叠加分工。

4.2 案例二：什么时候根本不需要 MCP

如果你只有 2～3 个内部函数，例如：

search_docs
create_ticket
send_email

而且这些工具只在单个应用里使用、不会跨多个客户端复用，那么：

直接在应用里注册 tools
再写一个 skill 告诉模型何时查文档、何时提单、何时发邮件

通常就够了。

这也是视频里那句“MCP 不是唯一接入方式”的工程化版本。

📡 扩展
Anthropic 与 OpenAI 的官方资料都已经呈现出同一趋势：先判断你需不需要外部系统接入标准化，再决定是否引入 MCP。MCP 适合跨系统、跨客户端、权限与认证更复杂的场景；工具少、边界清晰时，直接 tool registration 会更轻。[^anthropic-mcp-connector][^openai-apps][^mcp-intro]

5. 对视频的精炼改写版结论

如果把视频内容压缩成一版更贴近 2026 官方资料的表述，可以写成：

Function Calling / Tools 是模型发起外部动作的执行机制。

MCP 是把工具、资源、提示模板等外部能力标准化接进 AI 应用的协议层。

Skill 是复用型工作流/能力包，用来告诉模型在某类任务中该如何思考、按什么步骤做事。

它们常常配合使用，但不在同一平面上比较。

真正的问题不是 “MCP vs Skill”，而是：你现在缺的是执行机制、接入标准，还是方法论沉淀？

6. 核心结论

6.1 最值得记住的 5 句话

不要把“能不能连上外部系统”和“模型该怎么做事”混为一谈。
Tools / Function Calling 管的是调用；MCP 管的是接入；Skill 管的是方法。
Tools 是更宽的术语；Function Calling 往往是其中一种具体实现。
Skill 在 2026 年已不只是 Markdown 文档，而是更完整的工作流封装。
当系统变复杂时，真正影响质量与成本的，往往不是“有没有工具”，而是：工具怎样接入、怎样命中、怎样按需加载。

6.2 面向实践的使用建议

工具少、单应用、快速试验：直接 tools/functions
跨系统、跨客户端、权限与认证复杂：引入 MCP
流程稳定、经验可复用、希望输出一致：补 Skill
复杂 agent 系统：通常是 Skill + MCP + Tools 三层并用

7. 可继续长大的知识节点

Function Calling
Tools
Tool Use
MCP
Agent Skills
Tool Search
JSON Schema
JSON-RPC
Host / Client / Server
上下文管理
Agent Engineering

8. 参考与检索来源

OpenAI

[^openai-fc] OpenAI Help Center, Function Calling in the OpenAI API
https://help.openai.com/en/articles/8555517-function-calling-in-the-openai-api
[^openai-fc-guide] OpenAI Docs, Function calling
https://developers.openai.com/api/docs/guides/function-calling
[^openai-responses] OpenAI Docs, Migrate to the Responses API
https://developers.openai.com/api/docs/guides/migrate-to-responses
[^openai-apps] OpenAI Apps SDK Quickstart
https://developers.openai.com/apps-sdk/quickstart
[^openai-tool-search] OpenAI Docs, Tool search
https://developers.openai.com/api/docs/guides/tools-tool-search
[^openai-skills] OpenAI Codex Docs, Agent Skills
https://developers.openai.com/codex/skills

Anthropic

[^anthropic-tool-use] Claude Docs, Tool use with Claude
https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
[^anthropic-skills] Claude Docs, Agent Skills
https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
[^anthropic-advanced-tools] Anthropic Engineering, Introducing advanced tool use on the Claude Developer Platform
https://www.anthropic.com/engineering/advanced-tool-use
[^anthropic-mcp-connector] Claude Docs, MCP connector
https://platform.claude.com/docs/en/managed-agents/mcp-connector

MCP Official

[^mcp-intro] MCP Docs, What is the Model Context Protocol (MCP)?
https://modelcontextprotocol.io/docs/getting-started/intro
[^mcp-arch] MCP Docs, Architecture overview
https://modelcontextprotocol.io/docs/learn/architecture
[^mcp-tools] MCP Spec, Tools
https://modelcontextprotocol.io/specification/2025-06-18/server/tools
[^mcp-spec] MCP Spec, Specification
https://modelcontextprotocol.io/specification/2025-11-25