文章目录Function Calling、MCP、Tool、Skill 四者的区别与联系开篇引言一、Function Calling大模型调用外部函数的基石定义与核心思想主要用途与应用场景核心特点与优缺点简单示例说明二、MCPModel Context Protocol标准化的大模型上下文协议定义与核心思想主要用途与应用场景核心特点与优缺点简单示例说明三、ToolAgent 的原子执行能力定义与核心思想主要用途与应用场景核心特点与优缺点简单示例说明四、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、股票 API、数据库查询等获取模型训练数据中没有的实时信息动作执行发送邮件、创建日历事件、提交表单等需要与外部系统交互的操作多轮工具编排在 Agent 场景中模型根据中间结果动态决定下一步调用哪个函数核心特点与优缺点优点厂商原生支持无需额外框架直接通过 API 使用响应速度快结构化输出模型生成的参数严格遵循 JSON Schema减少解析错误行业事实标准几乎所有主流大模型都支持跨模型迁移成本低并行调用新一代 API 支持模型在一次回复中生成多个函数调用请求提升效率缺点厂商耦合不同厂商的 Function Calling 实现细节存在差异Schema 格式、参数命名等跨厂商切换需适配上下文消耗所有函数定义的 Schema 需全量注入上下文函数数量多时 Token 消耗显著增加可靠性依赖模型模型可能产生幻觉调用调用不存在的函数、参数遗漏或顺序混乱缺乏标准化协议Function Calling 本身只是一个 API 特性不涉及服务发现、能力协商、传输层管理等工程化问题简单示例说明以下是一个 OpenAI Function Calling 的典型示例fromopenaiimportOpenAI clientOpenAI()# 1. 定义函数 Schematools[{type:function,function:{name:get_weather,description:获取指定城市的天气信息,parameters:{type:object,properties:{city:{type:string,description:城市名称}},required:[city]}}}]# 2. 模型决定是否调用函数responseclient.chat.completions.create(modelgpt-4o,messages[{role:user,content:北京今天天气怎么样}],toolstools)# 3. 模型返回结构化的调用请求tool_callresponse.choices[0].message.tool_calls[0]# tool_call.function.name get_weather# tool_call.function.arguments {city: 北京}# 4. 应用层执行函数将结果返回模型weather_resultget_weather(北京)# 实际执行# 5. 模型基于结果生成最终回复final_responseclient.chat.completions.create(modelgpt-4o,messages[{role:user,content:北京今天天气怎么样},response.choices[0].message,{role:tool,tool_call_id:tool_call.id,content:weather_result}])要点模型只负责决定调用什么和生成参数函数的实际执行由开发者代码完成。这是 Function Calling 最本质的特征。二、MCPModel Context Protocol标准化的大模型上下文协议定义与核心思想MCPModel 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本地进程通信和 HTTPSSE远程通信两种传输方式。协议包含生命周期管理连接初始化、能力协商、会话控制、授权框架、服务器特性Resources / Prompts / Tools和客户端特性Sampling / Roots等模块。截至本文撰写时MCP 规范已迭代至2025-11-25 版本2025-06-18 版本为已发布的稳定版社区生态快速发展OpenAI、Google、微软等厂商均已宣布支持或正在接入 MCP 协议。主要用途与应用场景场景说明统一工具接入一个 MCP Server 可以同时服务多个 AI 应用避免为每个模型/框架重复开发工具适配企业内部能力共享将企业内部 API、数据库、知识库封装为 MCP Server供不同团队的不同 AI 应用统一调用IDE 集成如 Claude Code、Cursor 等 AI 编程工具通过 MCP 连接本地文件系统、Git、数据库等跨模型互操作同一个 MCP Server 可被 Claude、GPT、Gemini 等不同模型的应用接入实现工具层的模型无关性核心特点与优缺点优点标准化解耦工具提供方与模型消费方彻底解耦一次开发处处可用能力协商机制客户端和服务器在连接初始化时协商各自支持的功能实现优雅降级丰富的特性类型不仅有 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 SDKimport{McpServer}frommodelcontextprotocol/sdk/server/mcp.js;import{StdioServerTransport}frommodelcontextprotocol/sdk/server/stdio.js;import{z}fromzod;constservernewMcpServer({name:weather-server,version:1.0.0});// 注册一个 Toolserver.tool(get_weather,获取指定城市的天气信息,{city:z.string().describe(城市名称)},async({city}){constweatherawaitfetchWeather(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([北京,上海,广州,深圳])}]}));// 启动服务consttransportnewStdioServerTransport();awaitserver.connect(transport);客户端如 Claude Desktop只需在配置文件中声明 MCP Server 的启动命令即可自动发现并连接无需编写任何适配代码{mcpServers:{weather:{command:node,args:[weather-server.js]}}}要点MCP 解决的不是模型怎么调用函数的问题那是 Function Calling 的事而是工具怎么被标准化地发现、描述和连接的问题。它是 Function Calling 之上的一层协议与工程化封装。三、ToolAgent 的原子执行能力定义与核心思想Tool工具是对 Function Calling 能力的上层封装指具有明确输入、输出和副作用的可执行原子函数。当 Agent 调用一个 Tool 时现实世界中会发生某些事情数据库被查询、API 被调用、文件被写入。在技术实现上Tool 本质是将函数签名 描述信息组织成模型可理解的 Schema模型根据用户意图自主选择合适的 Tool 并生成调用参数框架负责在同进程内执行函数并将结果返回模型。一句话理解Tool 扩展的是 Agent 的能力What it can do——让 Agent 能做事。Tool 是 Agent 的手负责执行具体动作。主要用途与应用场景场景说明轻量原子操作天气查询、翻译、计算、单位转换等单步即可完成的操作数据查询与操作查数据库、调 REST API、读写文件系统通信与通知发送邮件、推送消息、创建工单探索性任务模型需要根据中间结果动态决定下一步操作的场景如多轮搜索与分析核心特点与优缺点优点开发效率高新增能力只需编写一个函数并注册无需维护复杂目录结构灵活性强模型可动态组合多个 Tool应对开放式、探索性任务同进程调用响应速度快系统开销低无需额外的进程间通信生态成熟Function Calling 已成为行业标准各大模型和框架LangChain、AgentScope、OpenAI Agents SDK 等均原生支持 Tool 模式模型自主编排模型根据上下文动态规划调用顺序适合无法预设流程的复杂任务缺点流程可靠性依赖模型模型可能出现调用顺序混乱、参数漏传、幻觉调用等问题复杂多步骤场景下稳定性不足Token 消耗大所有 Tool 的 JSON Schema 定义需全量注入上下文。工具数量增多时上下文窗口被大量占用安全攻击面较大同进程执行意味着 Tool 可访问宿主环境的所有资源需要开发者自行实现认证、授权和权限控制缺乏场景化封装Tool 只解决单个动作怎么执行不解决一个业务场景包含哪些步骤、按什么顺序执行简单示例说明以 LangChain 为例使用tool装饰器即可将普通函数注册为 Toolfromlangchain_core.toolsimporttoolfromlangchain_openaiimportChatOpenAI# 定义 Tooltooldefsearch_database(query:str,limit:int10)-str:在数据库中搜索相关信息。 Args: query: 搜索关键词 limit: 返回结果数量上限 resultsdb.search(query,limitlimit)returnjson.dumps(results)tooldefsend_email(to:str,subject:str,body:str)-str:发送电子邮件。smtp.send(to,subject,body)returnf邮件已发送至{to}# 绑定 Tools 到模型modelChatOpenAI(modelgpt-4o)model_with_toolsmodel.bind_tools([search_database,send_email])# 模型自主决定调用哪个 Toolresponsemodel_with_tools.invoke(帮我搜索最新的AI论文并发送到testexample.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 如何高效完成特定场景的任务。主要用途与应用场景场景说明复杂业务流程审批流程、报表生成、客户回访等多步骤、需固定编排的场景领域专家能力GitHub 代码审查、SQL 性能优化、部署发布等需要专业知识的场景安全敏感操作涉及密钥、凭证等敏感数据的场景需要进程级隔离Token 敏感场景工具数量庞大、Schema 复杂需要大幅降低上下文消耗的场景核心特点与优缺点优点流程稳定可控执行步骤通过代码固化彻底避免模型导致的顺序混乱、步骤遗漏问题Token 极度节约模型仅需加载 SKILL.md 中的简短描述无需理解内部实现。Anthropic 团队实测将一个 150,000 token 的工作流通过 Skill 化改造后降至约 2,000 tokens安全隔离性强采用子进程执行敏感信息Cookie、密钥等通过环境变量或上下文透传不进入模型上下文实现进程级隔离无侵入式扩展新增业务场景仅需新增目录 编写 SKILL.md 脚本无需修改后端核心代码自然语言声明Skill 用自然语言描述何时使用、如何使用模型通过语义理解而非函数映射来匹配更贴近人类协作方式缺点灵活性受限流程固化意味着无法动态应对未预设的场景开放式探索性任务不适用开发维护成本较高需维护目录结构、声明文件和多个脚本文件工程复杂度高于 Tool当前生态局限Skill 模式目前主要由 AnthropicClaude 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语义理解 → 模型提取参数repomyproject, pr_number123 → 后端读取 SKILL.md 中的调用命令 → 启动独立子进程执行 scripts/main.py → 脚本内部按固定步骤获取PR → 运行测试 → 生成评论 → 结果返回给 Agent → Agent 用自然语言回复用户要点模型不参与流程编排仅负责选择技能 提取参数。Skill 内部的执行步骤、异常处理、数据流转全部由脚本代码控制。这正是 Skill 与 Tool 最核心的差异——Tool 让模型自己决定怎么做Skill 让开发者预先定义好怎么做。五、横向对比总结为帮助开发者建立系统认知以下从多个维度对四者进行全面对比对比维度Function CallingMCPToolSkill定义大模型原生能力生成符合 Schema 的结构化函数调用请求开放协议标准化 LLM 应用与外部数据源/工具之间的连接方式对 Function Calling 的上层封装可执行的原子函数封装领域专长的可组合资源包含指令、脚本、模板本质模型层面的机制协议层面的标准应用/框架层面的封装场景/领域层面的封装核心用途让模型能声明要调用什么函数、传什么参数让工具能被标准化地发现、描述和连接让 Agent 能执行具体动作查库、调 API、写文件让 Agent 会高效完成特定场景任务审批、对账、代码审查所属层级最底层——模型原生能力协议层——标准化连接框架中间层——原子能力封装最上层——场景化技能封装与大模型的关系模型直接生成调用请求是模型自身的特性模型不直接感知 MCP由客户端将 MCP 工具转为模型可理解的格式模型全量感知 Tool 的 Schema自主决定调用哪个、传什么参数模型仅感知 Skill 的名称和简短描述内部实现对模型黑盒运行载体模型推理过程 应用层执行独立进程Client-Server 架构同进程内函数调用独立子进程执行脚本流程控制模型动态规划不涉及流程编排仅提供能力发现与调用模型动态规划灵活但不稳定代码固化流程稳定但不灵活Token 经济性高消耗所有函数 Schema 全量注入高消耗Server 暴露的工具 Schema 全量注入高消耗所有 Tool Schema 全量注入极度节约仅加载简短声明按需披露安全隔离低同进程执行中进程隔离但有 Rug Pull / Shadowing 风险低同进程共享环境高进程级隔离敏感信息不进模型上下文跨平台可移植性高已成为行业标准高开放协议多厂商支持高基于 Function Calling 标准低目前主要为 Anthropic 生态尚无跨厂商标准扩展方式在 API 请求中定义函数 Schema编写 MCP Server 并注册注册新函数至 Agent新增目录 SKILL.md 脚本适用场景需要模型生成结构化输出的任何场景需要跨应用/跨模型共享工具能力的场景轻量、通用、单步原子能力复杂业务、多步骤、高安全要求场景典型代表OpenAI Tools API、Claude Tool UseAnthropic MCP 协议LangChain Tools、OpenAI Agents SDK ToolsClaude Code Skills、WorkBuddy Skills四者的层级关系┌─────────────────────────────────────────────────────┐ │ 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 并非四选一的互斥关系而是自下而上的技术栈分层在实际系统中往往协同工作Function Calling是地基——没有它模型无法生成结构化的调用请求上层的 Tool、MCP、Skill 都无从谈起Tool是基于 Function Calling 的工程化封装——开发者将业务逻辑封装为一个个原子 Tool注册给模型使用MCP是 Tool 的标准化连接层——通过 Client-Server 协议让 Tool 可以跨应用、跨模型共享实现一次开发处处可用Skill是 Tool 的场景化封装——将多个 Tool 按业务流程编排固化减少模型推理负担提升稳定性与 Token 效率一个成熟的生产级 AI 系统通常同时使用这四者底层用 Function Calling 驱动模型生成调用用 Tool 封装原子能力用 MCP 实现工具的标准化共享用 Skill 封装复杂业务流程。选型建议场景特征推荐方案理由只需让模型生成结构化输出Function Calling最轻量无需额外框架需要执行简单原子操作查天气、翻译等Tool开发效率高灵活性强需要跨应用/跨模型共享工具MCP标准化协议一次开发处处可用工具数量多、Token 消耗大Skill渐进式披露大幅降低上下文占用复杂多步骤业务流程审批、对账等Skill流程代码固化稳定可控涉及敏感数据的操作Skill进程级隔离敏感信息不进模型上下文生产级复杂系统混合架构底层 Tool MCP 共享上层 Skill 编排核心原则简单场景不过度设计如果只是让模型查个天气用 Function Calling 或 Tool 就够了引入 MCP/Skill 反而增加复杂度复杂场景不过度简化如果涉及多步骤业务流程、安全敏感操作仅靠 Tool 让模型自行编排会带来稳定性与安全隐患应使用 Skill 固化流程关注 Token 效率当工具数量超过一定规模如 20全量注入 Schema 的 Token 成本不可忽视应考虑 Skill 的渐进式披露机制关注生态与可移植性如果需要跨模型/跨框架使用优先选择基于开放标准的 MCP如果绑定单一生态如 ClaudeSkill 可提供更好的体验总结Function Calling 是能力Tool 是封装MCP 是协议Skill 是场景。理解四者的分层关系才能在合适的场景选择合适的方案构建出既灵活又稳定的 AI 应用。参考资料Model Context Protocol 官方规范OpenAI Function Calling 官方文档Anthropic MCP GitHub 仓库Skill 与 Tool 彻底分清Agent 能力的底层原理AI Agent 两大能力架构深度对比Tool 与 Skill 的本质差异