一文搞懂 Function Calling、MCP、Tool、Skill：大模型能力扩展技术栈深度对比

Function Calling、MCP、Tool、Skill 四者的区别与联系

导读：在 AI 与大模型应用开发中，Function Calling、MCP、Tool、Skill 是四个频繁出现却又极易混淆的概念。它们分别处于不同的抽象层级，从底层的函数调用机制到上层的场景化技能封装，共同构成了大模型能力扩展的完整技术栈。本文将逐一剖析四者的定义、特点与应用场景，并通过横向对比帮助开发者建立清晰的认知框架，在实际项目中做出合理选型。

开篇引言

随着大语言模型（LLM）从"纯文本生成"迈向"智能体（Agent）行动"，如何让模型调用外部能力成为核心工程挑战。围绕这一问题，业界先后诞生了Function Calling、MCP、Tool、Skill四个概念，它们分别从不同层面回答了同一个问题：大模型如何与外部世界交互？

然而，这四个概念在命名上高度相近，语义边界模糊，常常令开发者困惑：

• Function Calling 和 Tool 有什么区别？OpenAI 的tools参数不就是 Function Calling 吗？
• MCP 是一种协议还是一种工具？它和 Tool 是什么关系？
• Skill 又是什么？它和 Tool 不是一回事吗？

事实上，这四者并非互斥的竞争关系，而是处于不同抽象层级的互补概念。理解它们的差异，是构建高质量 AI 应用的前提。

一、Function Calling：大模型调用外部函数的基石

定义与核心思想

Function Calling是大模型厂商提供的一种原生能力，允许模型根据用户意图，生成符合预定义 Schema 的结构化函数调用请求（函数名 + 参数），由应用层负责实际执行函数并将结果返回模型，模型再基于结果继续推理。

其核心思想是：模型不直接执行代码，而是"声明"它想调用什么函数、传什么参数，执行权交还给应用层。这既保证了安全性（模型无法越权操作），又实现了模型与外部世界的连接。

OpenAI 在 2023 年 6 月率先推出 Function Calling，初始 API 参数为functions和function_call；随后在 2023 年 11 月演进出Tools API，用tools和tool_choice参数取代了旧的functions参数，支持并行调用多个工具。如今，Function Calling 已成为主流大模型（OpenAI、Anthropic、Google、阿里通义、智谱等）的标配能力。

主要用途与应用场景

核心特点与优缺点

优点：

• 厂商原生支持：无需额外框架，直接通过 API 使用，响应速度快
• 结构化输出：模型生成的参数严格遵循 JSON Schema，减少解析错误
• 行业事实标准：几乎所有主流大模型都支持，跨模型迁移成本低
• 并行调用：新一代 API 支持模型在一次回复中生成多个函数调用请求，提升效率

缺点：

• 厂商耦合：不同厂商的 Function Calling 实现细节存在差异（Schema 格式、参数命名等），跨厂商切换需适配
• 上下文消耗：所有函数定义的 Schema 需全量注入上下文，函数数量多时 Token 消耗显著增加
• 可靠性依赖模型：模型可能产生幻觉调用（调用不存在的函数）、参数遗漏或顺序混乱
• 缺乏标准化协议：Function Calling 本身只是一个 API 特性，不涉及服务发现、能力协商、传输层管理等工程化问题

简单示例说明

以下是一个 OpenAI Function Calling 的典型示例：

fromopenaiimportOpenAI client=OpenAI()# 1. 定义函数 Schematools=[{"type":"function","function":{"name":"get_weather","description":"获取指定城市的天气信息","parameters":{"type":"object","properties":{"city":{"type":"string","description":"城市名称"}},"required":["city"]}}}]# 2. 模型决定是否调用函数response=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"北京今天天气怎么样？"}],tools=tools)# 3. 模型返回结构化的调用请求tool_call=response.choices[0].message.tool_calls[0]# tool_call.function.name = "get_weather"# tool_call.function.arguments = '{"city": "北京"}'# 4. 应用层执行函数，将结果返回模型weather_result=get_weather("北京")# 实际执行# 5. 模型基于结果生成最终回复final_response=client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":"北京今天天气怎么样？"},response.choices[0].message,{"role":"tool","tool_call_id":tool_call.id,"content":weather_result}])

要点：模型只负责"决定调用什么"和"生成参数"，函数的实际执行由开发者代码完成。这是 Function Calling 最本质的特征。

二、MCP（Model Context Protocol）：标准化的大模型上下文协议

定义与核心思想

MCP（Model Context Protocol，模型上下文协议）是由 Anthropic 于 2024 年 11 月开源发布的一项开放协议，旨在为 LLM 应用与外部数据源、工具之间提供标准化的连接方式。其地位常被类比为"AI 应用层的 USB-C 接口"——不管什么工具、什么模型，只要遵循 MCP 协议，就能即插即用。

MCP 的核心思想是客户端-服务端（Client-Server）架构：

• MCP Server：暴露能力方，将工具（Tools）、资源（Resources）、提示词（Prompts）以标准化方式发布
• MCP Client：消费能力方，通常是 AI 应用或 Agent 框架，连接 Server 并将能力注入模型上下文

所有通信基于JSON-RPC 2.0规范，支持 STDIO（本地进程通信）和 HTTP+SSE（远程通信）两种传输方式。协议包含生命周期管理（连接初始化、能力协商、会话控制）、授权框架、服务器特性（Resources / Prompts / Tools）和客户端特性（Sampling / Roots）等模块。

截至本文撰写时，MCP 规范已迭代至2025-11-25 版本（2025-06-18 版本为已发布的稳定版），社区生态快速发展，OpenAI、Google、微软等厂商均已宣布支持或正在接入 MCP 协议。

主要用途与应用场景

核心特点与优缺点

优点：

• 标准化解耦：工具提供方与模型消费方彻底解耦，一次开发，处处可用
• 能力协商机制：客户端和服务器在连接初始化时协商各自支持的功能，实现优雅降级
• 丰富的特性类型：不仅有 Tools（可执行函数），还有 Resources（只读数据源）和 Prompts（预设提示模板），覆盖面广
• 传输层灵活：支持本地 STDIO 和远程 HTTP 传输，适配不同部署场景
• 生态发展迅速：已有数百个社区 MCP Server 覆盖 GitHub、Slack、数据库、文件系统等常见场景

缺点：

• 架构复杂度增加：引入 Client-Server 架构带来额外的进程管理、连接维护开销，对于简单场景可能过重
• 性能开销：相比同进程直接函数调用，JSON-RPC 序列化/反序列化和进程间通信存在延迟
• Token 消耗问题：一个 MCP Server 可能暴露数十甚至上百个工具，全量注入 Schema 严重消耗上下文窗口（Anthropic 工程团队实测单个 GitHub MCP Server 的工具 Schema 可消耗超过 50,000 tokens）
• 安全风险：已知风险包括Rug Pull（工具安装后篡改定义）和Tool Shadowing（恶意服务器劫持可信工具调用），需配合严格的权限管控
• 规范仍在演进：协议版本频繁迭代，不同实现之间可能存在兼容性问题

简单示例说明

以下是一个简单的 MCP Server 定义示例（基于 TypeScript SDK）：

import{McpServer}from"@modelcontextprotocol/sdk/server/mcp.js";import{StdioServerTransport}from"@modelcontextprotocol/sdk/server/stdio.js";import{z}from"zod";constserver=newMcpServer({name:"weather-server",version:"1.0.0"});// 注册一个 Toolserver.tool("get_weather","获取指定城市的天气信息",{city:z.string().describe("城市名称")},async({city})=>{constweather=awaitfetchWeather(city);return{content:[{type:"text",text:`${city}当前天气：${weather}`}]};});// 注册一个 Resource（只读数据源）server.resource("city-list","cities://supported",async()=>({contents:[{uri:"cities://supported",mimeType:"application/json",text:JSON.stringify(["北京","上海","广州","深圳"])}]}));// 启动服务consttransport=newStdioServerTransport();awaitserver.connect(transport);

客户端（如 Claude Desktop）只需在配置文件中声明 MCP Server 的启动命令，即可自动发现并连接，无需编写任何适配代码：

{"mcpServers":{"weather":{"command":"node","args":["weather-server.js"]}}}

要点：MCP 解决的不是"模型怎么调用函数"的问题（那是 Function Calling 的事），而是"工具怎么被标准化地发现、描述和连接"的问题。它是 Function Calling 之上的一层协议与工程化封装。

三、Tool：Agent 的原子执行能力

定义与核心思想

Tool（工具）是对 Function Calling 能力的上层封装，指具有明确输入、输出和副作用的可执行原子函数。当 Agent 调用一个 Tool 时，现实世界中会发生某些事情：数据库被查询、API 被调用、文件被写入。

在技术实现上，Tool 本质是将函数签名 + 描述信息组织成模型可理解的 Schema，模型根据用户意图自主选择合适的 Tool 并生成调用参数，框架负责在同进程内执行函数并将结果返回模型。

一句话理解：Tool 扩展的是 Agent 的"能力"（What it can do）——让 Agent 能做事。Tool 是 Agent 的"手"，负责执行具体动作。

主要用途与应用场景

核心特点与优缺点

优点：

• 开发效率高：新增能力只需编写一个函数并注册，无需维护复杂目录结构
• 灵活性强：模型可动态组合多个 Tool，应对开放式、探索性任务
• 同进程调用：响应速度快，系统开销低，无需额外的进程间通信
• 生态成熟：Function Calling 已成为行业标准，各大模型和框架（LangChain、AgentScope、OpenAI Agents SDK 等）均原生支持 Tool 模式
• 模型自主编排：模型根据上下文动态规划调用顺序，适合无法预设流程的复杂任务

缺点：

• 流程可靠性依赖模型：模型可能出现调用顺序混乱、参数漏传、幻觉调用等问题，复杂多步骤场景下稳定性不足
• Token 消耗大：所有 Tool 的 JSON Schema 定义需全量注入上下文。工具数量增多时，上下文窗口被大量占用
• 安全攻击面较大：同进程执行意味着 Tool 可访问宿主环境的所有资源，需要开发者自行实现认证、授权和权限控制
• 缺乏场景化封装：Tool 只解决"单个动作怎么执行"，不解决"一个业务场景包含哪些步骤、按什么顺序执行"

简单示例说明

以 LangChain 为例，使用@tool装饰器即可将普通函数注册为 Tool：

fromlangchain_core.toolsimporttoolfromlangchain_openaiimportChatOpenAI# 定义 Tool@tooldefsearch_database(query:str,limit:int=10)->str:"""在数据库中搜索相关信息。 Args: query: 搜索关键词 limit: 返回结果数量上限 """results=db.search(query,limit=limit)returnjson.dumps(results)@tooldefsend_email(to:str,subject:str,body:str)->str:"""发送电子邮件。"""smtp.send(to,subject,body)returnf"邮件已发送至{to}"# 绑定 Tools 到模型model=ChatOpenAI(model="gpt-4o")model_with_tools=model.bind_tools([search_database,send_email])# 模型自主决定调用哪个 Toolresponse=model_with_tools.invoke("帮我搜索最新的AI论文并发送到test@example.com")

要点：Tool 是 Function Calling 的工程化封装。Function Calling 是模型层面的原生能力，Tool 是框架/应用层面的组织方式。可以说，没有 Function Calling 就没有 Tool，但 Tool 不等于 Function Calling——Tool 还包含了注册管理、生命周期、结果处理等框架级逻辑。

四、Skill：场景化的专家技能包

定义与核心思想

Skill（技能）是封装了领域专长的可组合资源包，包含指令、脚本、模板和参考资料。Skill 不直接暴露函数签名给模型，而是通过一个声明文件（如SKILL.md）定义技能名称、用途和调用方式，模型仅需感知"这个技能存在、能做什么、怎么触发"，内部实现对模型完全黑盒。

这种设计契合 Anthropic 提出的“渐进式披露”（Progressive Disclosure）原则：不一次性将所有细节灌给模型，而是按需加载，让模型专注于决策而非理解实现。

一句话理解：Skill 扩展的是 Agent 的"专长"（What it knows）——让 Agent 会做事。Skill 是 Agent 的"经验"，封装了领域知识、流程编排和行为模式，指导 Agent 如何高效完成特定场景的任务。

主要用途与应用场景

核心特点与优缺点

优点：

• 流程稳定可控：执行步骤通过代码固化，彻底避免模型导致的顺序混乱、步骤遗漏问题
• Token 极度节约：模型仅需加载 SKILL.md 中的简短描述，无需理解内部实现。Anthropic 团队实测，将一个 150,000 token 的工作流通过 Skill 化改造后，降至约 2,000 tokens
• 安全隔离性强：采用子进程执行，敏感信息（Cookie、密钥等）通过环境变量或上下文透传，不进入模型上下文，实现进程级隔离
• 无侵入式扩展：新增业务场景仅需新增目录 + 编写 SKILL.md + 脚本，无需修改后端核心代码
• 自然语言声明：Skill 用自然语言描述"何时使用、如何使用"，模型通过语义理解而非函数映射来匹配，更贴近人类协作方式

缺点：

• 灵活性受限：流程固化意味着无法动态应对未预设的场景，开放式探索性任务不适用
• 开发维护成本较高：需维护目录结构、声明文件和多个脚本文件，工程复杂度高于 Tool
• 当前生态局限：Skill 模式目前主要由 Anthropic（Claude Agent Skills、Claude Code 等）推动，尚未形成跨厂商标准，可移植性不如 Tool/MCP
• 测试挑战：传统单元测试无法验证 Skill 是否会在"正确的时候"被调用，因为激活取决于 LLM 的非确定性推理

简单示例说明

一个标准 Skill 的目录结构如下：

skills/ └── github-pr-review/ # 一个场景一个目录 ├── SKILL.md # 声明文件（模型只看这个） └── scripts/ # 执行脚本（内部逻辑，模型黑盒） ├── main.py # 统一入口 ├── fetch_pr.py # 获取 PR 信息 ├── run_tests.py # 运行 CI 测试 └── post_comment.py # 发布审查评论

SKILL.md声明文件示例：

--- name: github-pr-review description: 审查 GitHub 拉取请求 —— 获取 PR 详情、运行 CI 检查、发布审查评论。 --- ## 何时使用此技能 当用户要求审查、检查或评论 GitHub 拉取请求时使用。 ## 如何运行 执行命令： python scripts/main.py --repo {repo} --pr {pr_number} --action review ## 约束与限制 - 发布审查评论前必须征得用户确认。 - 仅审查当前用户拥有写入权限的仓库中的 PR。

执行链路：

用户："帮我审查 PR #123" → 模型匹配到 github-pr-review Skill（语义理解） → 模型提取参数：repo=myproject, pr_number=123 → 后端读取 SKILL.md 中的调用命令 → 启动独立子进程执行 scripts/main.py → 脚本内部按固定步骤：获取PR → 运行测试 → 生成评论 → 结果返回给 Agent → Agent 用自然语言回复用户

要点：模型不参与流程编排，仅负责"选择技能 + 提取参数"。Skill 内部的执行步骤、异常处理、数据流转全部由脚本代码控制。这正是 Skill 与 Tool 最核心的差异——Tool 让模型自己决定怎么做，Skill 让开发者预先定义好怎么做。

五、横向对比总结

为帮助开发者建立系统认知，以下从多个维度对四者进行全面对比：

四者的层级关系

┌─────────────────────────────────────────────────────┐ │ Skill（场景层） │ │ 封装领域知识与流程编排，内部可编排多个 Tool │ ├─────────────────────────────────────────────────────┤ │ Tool（能力层） │ │ 原子执行函数，基于 Function Calling 实现 │ ├─────────────────────────────────────────────────────┤ │ MCP（协议层） │ │ 标准化工具发现与连接，可暴露 Tool / Resource / Prompt │ ├─────────────────────────────────────────────────────┤ │ Function Calling（模型层） │ │ 模型原生能力：生成结构化函数调用请求 │ └─────────────────────────────────────────────────────┘

从下往上看：Function Calling 是基石，Tool 基于它构建，MCP 标准化了 Tool 的发现与连接，Skill 在 Tool 之上进一步封装场景化流程。

从上往下看：Skill 内部可以编排多个 Tool 的调用顺序，Tool 可以通过 MCP 协议被远程发现和调用，MCP Server 暴露的 Tool 最终依赖模型的 Function Calling 能力来触发执行。

结语

四者的协作关系

Function Calling、MCP、Tool、Skill 并非四选一的互斥关系，而是自下而上的技术栈分层，在实际系统中往往协同工作：

1. Function Calling是地基——没有它，模型无法生成结构化的调用请求，上层的 Tool、MCP、Skill 都无从谈起
2. Tool是基于 Function Calling 的工程化封装——开发者将业务逻辑封装为一个个原子 Tool，注册给模型使用
3. MCP是 Tool 的标准化连接层——通过 Client-Server 协议，让 Tool 可以跨应用、跨模型共享，实现"一次开发，处处可用"
4. Skill是 Tool 的场景化封装——将多个 Tool 按业务流程编排固化，减少模型推理负担，提升稳定性与 Token 效率

一个成熟的生产级 AI 系统通常同时使用这四者：底层用 Function Calling 驱动模型生成调用，用 Tool 封装原子能力，用 MCP 实现工具的标准化共享，用 Skill 封装复杂业务流程。

选型建议

核心原则：

• 简单场景不过度设计：如果只是让模型查个天气，用 Function Calling 或 Tool 就够了，引入 MCP/Skill 反而增加复杂度
• 复杂场景不过度简化：如果涉及多步骤业务流程、安全敏感操作，仅靠 Tool 让模型自行编排会带来稳定性与安全隐患，应使用 Skill 固化流程
• 关注 Token 效率：当工具数量超过一定规模（如 20+），全量注入 Schema 的 Token 成本不可忽视，应考虑 Skill 的渐进式披露机制
• 关注生态与可移植性：如果需要跨模型/跨框架使用，优先选择基于开放标准的 MCP；如果绑定单一生态（如 Claude），Skill 可提供更好的体验

总结：Function Calling 是能力，Tool 是封装，MCP 是协议，Skill 是场景。理解四者的分层关系，才能在合适的场景选择合适的方案，构建出既灵活又稳定的 AI 应用。

参考资料：

• Model Context Protocol 官方规范
• OpenAI Function Calling 官方文档
• Anthropic MCP GitHub 仓库
• Skill 与 Tool 彻底分清：Agent 能力的底层原理
• AI Agent 两大能力架构深度对比：Tool 与 Skill 的本质差异