如果你最近在关注 AI 编程、Agent 开发或者 AI 应用落地那你大概率被三个概念轰炸过Tool Calling、Skills、MCP。打开技术社区有人教你写 function calling有人推荐各种 skill 仓库还有人在争论 MCP 是不是 AI 版的“USB-C”。很多人会陷入一个困惑这三个词看起来都在讲“让 AI 用工具”那它们到底是不是同一个东西如果我要做一个 AI Agent是学 Tool Calling 就够了还是必须上 MCPSkills 和它们两个又是什么关系为什么有的文章说“Skills 是 MCP 之上的一层”有的又说“Skill 和 MCP 根本不是一回事”我的判断很直接Tool Calling、Skills、MCP 不是三个互相替代的方案而是三个不同层级、解决不同问题的东西。Tool Calling 是模型调用外部工具的基础机制MCP 是连接和供给工具的标准化协议Skills 则是封装“完成一类任务的方法论”的技能包。你把它们放在同一个维度比较永远理不清一旦按层级理解整个 AI Agent 的工具生态就清晰了。这篇文章会从底层机制讲到工程落地先帮你把三个概念的定义彻底掰开再给出每一层的最小示例代码最后结合真实项目告诉你什么场景该用什么三者如何配合以及新人最容易踩的坑在哪里。文章篇幅较长建议先收藏再慢慢看。1. 这篇文章真正要解决的问题先说实话这三个概念之所以让人混乱是因为它们都出现在“让 AI 做更多事情”的语境里而且在实际产品中经常同时出现。比如你用 Claude Code 或者 Codex 做一个前端页面流程可能是这样的Agent 先读取你的 skill 文件中关于“如何画原型图”的说明然后调用 MCP Server 里的 Figma 工具把设计稿转换成代码。在这个过程中模型每一次真正执行外部操作靠的都是 Tool Calling 机制。三个概念在同一件事里同时出现自然容易让人糊涂。所以这篇文章要回答的核心问题是Tool Calling 到底是怎么工作的它为什么是所有 Agent 的基础MCP 出现的背景是什么它解决了工具集成的什么痛点Skills 是“技能文件”还是“工具集合”它和 Tool Calling、MCP 的边界在哪里实际项目里三者是互斥还是配合怎么选择如果你正在做 AI 应用开发、Agent 工具链建设或者准备学习 Claude Skills、MCP Server 开发这篇文章就是给你写的。读完你不仅能分清三个概念还能动手写出最小可运行的示例。2. 三个概念的最简理解调用机制、连接协议、任务配方先把结论摆出来后面再逐层拆解。Tool Calling工具调用是模型具备的一种能力机制。它解决的是“模型如何请求外部函数执行”的问题。你不需要让模型真正去执行代码只需要让它理解有哪些函数可用并根据用户意图输出一个结构化的调用请求由你的应用去执行再把结果拿回来给模型继续推理。MCPModel Context Protocol模型上下文协议是一个标准化的连接协议。它解决的是“工具如何被发现、如何接入不同 AI 应用”的问题。在没有 MCP 之前每个 AI 应用都要专门写适配代码去对接每个工具有了 MCP工具开发者只需要实现一个 MCP Server任何支持 MCP 的客户端都能使用它。Skills技能包是一种面向任务的封装。它解决的是“模型如何稳定地完成一类复杂任务”的问题。一个 Skill 通常包含一份 SKILL.md 文件里面写清楚目标、步骤、注意事项、代码模板、文件结构甚至相关的工具使用方式。当模型遇到匹配任务时会主动加载这个 Skill按照其指导来工作。用一个生活类比来理解Tool Calling 相当于“你能打电话”这个能力。MCP 相当于“电话号和通讯录的统一标准”——只要遵循这个标准任何电话都能接通任何号码。Skills 相当于“一套标准沟通话术”——比如“如何做一次客户回访”它约定你要用什么工具、按什么流程、说什么内容。所以Tool Calling 是地基MCP 是水管Skills 是装修方案。三者不在一个层面但可以完美配合。3. Tool Calling 拆解模型如何调用外部函数3.1 Tool Calling 解决了什么问题在早期的对话模型里模型只能“回答问题”不能“做事”。你想让它查一下明天的天气它只能尴尬地告诉你“我无法实时获取天气数据”。后来有人想到了一个聪明的办法把天气查询 API 封装成一个函数把函数说明告诉模型模型不直接调用 API而是输出 JSON 格式的调用参数——比如{city: 北京}——你的后端代码拿到这个 JSON 后再去调真实 API最后把结果放回对话里。这就是 Tool Calling也叫 Function Calling。它让模型从一个“纯文本生成器”变成了“能发号施令的调度器”。它的核心价值在于让模型不用真正执行代码也能调用外部世界的能力。这既是安全设计也是工程需要。模型不可控但你的代码可控模型只负责决定“要调用哪个函数、参数是什么”你的代码负责执行并校验结果。3.2 Tool Calling 的标准流程一个标准的 Tool Calling 流程如下你定义函数列表包括函数名、描述、参数 JSON Schema把列表发给模型。模型分析用户输入判断是否需要调用工具。如果需要模型返回一个结构化的函数调用请求而不是最终回复。你的代码执行该函数拿到执行结果。把执行结果作为新消息回传给模型。模型基于工具结果生成最终回复。注意第 3 步是模型输出不一定每次都会触发。如果用户问题不需要任何外部数据模型会直接正常回答不会强行调用工具。3.3 最小实现OpenAI 风格 Function Calling下面用一个最常见的 Python 示例演示 OpenAI 风格的 Function Calling。这里使用的是 OpenAI SDK 的通用写法重点看流程不依赖特定框架。from openai import OpenAI client OpenAI() # 1. 定义天气查询函数并告诉模型这个函数的存在 tools [ { type: function, function: { name: get_weather, description: 查询指定城市的实时天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如 北京 } }, required: [city] } } } ] messages [{role: user, content: 北京今天天气怎么样}] # 2. 第一次请求只传工具定义不执行任何本地函数 response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools ) assistant_message response.choices[0].message # 3. 判断模型是否发起了工具调用 if assistant_message.tool_calls: tool_call assistant_message.tool_calls[0] function_name tool_call.function.name function_args tool_call.function.arguments print(f模型请求调用函数: {function_name}, 参数: {function_args}) # 4. 在本地安全执行函数这里是模拟实际应调用真实天气 API import json args json.loads(function_args) if function_name get_weather: result {city: args[city], weather: 晴, temperature: 25} # 5. 把工具执行结果回传给模型 messages.append(assistant_message) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 6. 第二次请求模型基于工具结果生成最终回复 second_response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools ) print(second_response.choices[0].message.content)这段代码的核心逻辑是把函数定义传给模型模型返回“调用意图”你负责执行再把结果回传。真正执行函数的是你的代码不是模型。这一点很重要也是很多人写 Tool Calling 时容易搞反的地方。如果你看到这里还不太理解没关系。你只需要记住Tool Calling 是一个机制它决定了“模型如何描述它想调用的东西”。接下来讲的 MCP 和 Skills都是围绕这个机制做出来的上层设施。4. MCP 拆解AI 世界的标准化连接协议4.1 MCP 出现的背景Tool Calling 虽然解决了“模型能调用工具”的问题但很快暴露出一个工程痛点每接一个工具都要写大量胶水代码。比如你的 AI 应用要接数据库、接 Git、接浏览器、接设计稿每个工具都要单独写适配层把工具 API 包装成函数定义、处理参数格式、处理鉴权、处理错误。如果明天换一个 AI 客户端又要全部重写。这种“N 个工具 × N 个客户端”的集成矩阵很快就让人崩溃。MCP 就是为了解决这个痛点。它由 Anthropic 在 2024 年底提出设计目标很朴素像 USB-C 接口一样让工具和 AI 应用之间统一连接方式。一个 MCP Server 实现一次任何支持 MCP 的客户端Claude Desktop、Claude Code、Codex、Cursor 等都能直接用。从架构上看MCP 属于客户端-服务端模型MCP Host运行 AI 的宿主程序比如 Claude Desktop。MCP Client宿主程序内部与 Server 通信的组件负责发起连接和转发请求。MCP Server独立的服务程序负责暴露工具、提示词、资源给 AI 使用。通信协议基于 JSON-RPC 2.0传输方式目前主要有 stdio标准输入输出和 HTTP/SSE 两种。stdio 适合本地工具的进程通信HTTP 适合远程服务。4.2 MCP 中工具的发现与调用流程在 MCP 协议里工具发现的流程大致是客户端向 Server 发送tools/list请求。Server 返回工具列表包括每个工具的名称、描述和参数 Schema。AI 应用把工具列表注入上下文背后还是转换为 Tool Calling 的格式。模型决定调用某个工具时客户端发送tools/call请求。Server 执行工具逻辑返回结果。客户端把结果回传给模型继续生成回复。看到这里你应该能明白MCP 并没有改变 Tool Calling 的本质它只是把工具的“供给方式”标准化了。MCP Server 暴露出来的工具最终在模型那里仍然是以 Tool Calling 的形式被调用。4.3 一个最小 MCP Server 示例下面用一个 Python 示例演示 MCP Server 的最小实现。这里使用官方 SDK 提供的FastMCP抽象它把协议细节封装得很干净适合初学者快速上手。# 文件路径weather_mcp_server.py from mcp.server.fastmcp import FastMCP # 创建一个 MCP Server 实例 mcp FastMCP(WeatherServer) mcp.tool() def get_weather(city: str) - str: 查询指定城市的实时天气 Args: city: 城市名称例如 北京 # 这里是模拟实现真实项目中可替换为第三方天气 API return f{city}晴25°C if __name__ __main__: mcp.run()这是一个完整的 MCP Server运行起来后它对外暴露了一个get_weather工具。任何支持 MCP 的客户端都能发现并调用它。要运行这个 Server你需要先安装 SDKpip install mcp然后启动python weather_mcp_server.py默认情况下FastMCP 会通过 stdio 方式运行也就是说客户端通过标准输入输出与该进程通信。你可以把这段代码理解为一个“工具服务”它把天气查询能力封装成了一个标准接口。4.4 MCP 与 Tool Calling 的分工这里需要明确一个很容易混淆的点MCP Server 中不需要写 Tool Calling 的代码。模型是否调用工具、调用哪个工具仍然是靠后端的 Tool Calling 机制完成的。MCP 只负责两件事告诉客户端“我有哪些工具”以及“执行某个工具并返回结果”。所以更准确的类比是Tool Calling 是“模型的大脑与手之间的通信协议”。MCP 是“工具提供者与 AI 应用之间的标准化接口”。一个是模型内部的机制一个是系统之间的协议。5. Skills 拆解面向任务的技能包5.1 Skills 到底是什么如果说 Tool Calling 是“能力”MCP 是“接口”那 Skills 就是“操作手册”。所谓 Skills在 Claude Skills、Codex Skills 等体系中本质上是一套目录结构。每个 Skill 目录里包含一个SKILL.md文件以及若干辅助文件脚本、模板、示例代码、参考文档。当 Agent 遇到的任务匹配某个 Skill 的描述时就会读取这个 Skill 的内容按里面的指导执行。Skills 解决的是什么问题是**“AI 知道怎么调用工具但不知道该怎么完成一个复杂任务”**的问题。举个例子一个模型知道浏览器工具有哪些函数但它不一定知道“如何系统地审查一个前端项目的可访问性问题”。而一个名为accessibility-review的 Skill可以在SKILL.md里写清楚审查目标。审查步骤。需要打开哪些文件。使用哪些工具MCP Server 里的浏览器工具。遇到什么情况判定为问题。输出什么格式的报告。这样模型就能按照这套方法论稳定地完成任务而不是每次随机发挥。5.2 SKILL.md 的组织方式下面是一个典型的 Claude Skills 目录结构示例my-skill/ ├── SKILL.md ├── scripts/ │ └── analyze.py └── templates/ └── report_template.mdSKILL.md通常包含 Frontmatter 格式的元信息以及正文。下面是一个简化的示例--- name: code-review description: 用于执行代码审查的技能。当用户要求审查代码、查找 bug 或评估代码质量时使用。 --- # Code Review Skill ## 目标 系统审查指定代码输出结构化审查报告。 ## 步骤 1. 阅读目标代码文件梳理核心逻辑。 2. 检查是否存在以下问题逻辑错误、异常处理缺失、安全隐患、性能隐患。 3. 使用 scripts/analyze.py 辅助静态分析。 4. 按照 templates/report_template.md 格式输出报告。 ## 注意事项 - 项目根目录可能在 /workspace不要局限于当前目录。 - 如果代码依赖配置文件先阅读配置文件再下结论。 - 发现疑似 bug 时应同时说明复现条件。当你让 AI “帮我 review 一下某个项目的代码”时AI 会识别到这个任务匹配code-reviewSkill于是自动加载SKILL.md按照里面的步骤和注意事项执行。5.3 Skills 和工具的关系经常有人问Skills 是不是一种 MCP答案是否定的。Skills 和 MCP 的层次完全不同MCP 提供“工具”比如“调用浏览器”“查询数据库”“操作 Figma”。Skills 提供“任务配方”它告诉你什么时候该用哪个工具按什么顺序用中间有哪些注意事项。一个 Skill 可以引用 MCP 工具。比如一个“前端开发 Skills”可以告诉 AI当需要将设计稿转换为代码时应该先通过 MCP 接入 Figma 获取设计稿再使用代码生成工具完成转换。Skill 自己能写提示词、流程、模板但它不能直接替代 MCP 去连接外部服务。更准确地说Skills 和 MCP 是互补关系不是竞争关系。一个 Skill 内部完全可能挂载多个 MCP Server 下的工具。6. 三者统一理解机制、协议、配方现在可以把三个概念放在同一张表里对比了对比维度Tool CallingMCPSkills本质模型调用外部函数的机制工具连接与供给的协议复杂任务的封装与指导解决的核心问题模型如何表达“我要调用某函数”工具生态如何标准化接入模型如何稳定完成复杂任务是否需要写代码需要定义函数和调用解析逻辑需要实现 Server 端或客户端环境主要通过编写 Markdown 文档使用方模型推理引擎应用/客户端与工具服务之间Agent 运行时,由模型动态加载典型产物function_call 的 JSON 请求MCP Server 服务SKILL.md 辅助脚本依赖关系其他方案的基础最终仍走 Tool Calling 机制可引用 MCP 工具,但不依赖 MCP适用范围所有 LLM 应用跨客户端共享工具的标准化场景强调方法论的复杂业务任务三句话总结没有 Tool Calling模型连“调工具”的能力都没有MCP 和 Skills 都无从谈起。没有 MCP每接一个工具都要写一套适配代码工具生态会很碎片化。没有 Skills模型可能会调用工具但缺少做事的章法任务质量不稳定。用一句话串起来就是Tool Calling 是模型的手MCP 是连接手和工具的标准化管道Skills 是握着手教模型怎么干活的老师傅。7. 实际项目中使用三者的分层策略7.1 什么时候只用 Tool Calling如果只是做一个简单的单用户 AI 应用调用一两个固定的外部 API那不需要引入 MCP也不需要 Skills。比如做一个“AI 客服助手”它需要查询订单状态那你只用定义query_order这一个函数走标准 Function Calling 流程就好。引入 MCP 反而会增加维护成本杀鸡焉用牛刀。适合场景调用数量少1-5 个工具。工具由你的应用自己实现不需要共享给其他应用。追求最小依赖和最快开发速度。7.2 什么时候引入 MCP当工具开始膨胀或者你想让多个 AI 应用共享同一套工具集时MCP 是值得认真考虑的选择。比如你的团队有统一的数据查询工具、Git 操作工具、浏览器自动化工具同时你希望这些能力能同时被 Claude Desktop、Codex、自研应用使用。那么把这些工具封装成 MCP Server一次开发多处复用能省下大量胶水代码。同时像 Figma MCP、Playwright MCP、数据库 MCP 这类社区生态已经很丰富很多工具直接安装即可使用这比手动对接工具 API 要方便得多。适合场景工具需要被多个 AI 客户端共享。工具由独立团队维护希望统一接口。需要使用社区现成的 MCP Server 生态。7.3 什么时候引入 SkillsSkills 适合需要“方法论沉淀”的场景。如果你的团队希望 AI 每次都按统一标准执行代码审查、接口测试、需求拆分、报告生成等任务那就应该把方法论写成 Skill。举个例子测试团队可能有一个api-testingSkill里面记录了测试流程、断言规范、用例模板并挂载了一个 MCP 工具用于发送请求。AI 拿到测试任务后先加载 Skill 获取规范再通过 MCP 工具执行实际操作最终输出规范测试报告。适合场景任务流程复杂且需要固定步骤。需要沉淀团队经验、统一交付标准。希望 AI 在面对同一类任务时表现更稳定。实际项目中三者通常不是二选一而是组合使用底层用 Tool Calling 机制对接模型。中间用 MCP 对接外部工具。上层用 Skills 定义任务方法论。8. 常见问题与排查思路刚接触这三个概念的开发者经常遇到下面这些问题问题现象可能原因排查方式解决方案模型不调用工具直接瞎回答工具描述不清晰模型不知道何时该用检查函数 description 是否明确说明触发条件重写描述加入“当用户询问……时”的触发条件工具调用报参数格式错误参数 JSON Schema 定义与实际函数签名不一致打印模型输出的 arguments 与本地函数签名对比统一参数类型必要时增加参数校验和转换MCP Server 启动后客户端连接不上stdio 路径配置错误或依赖缺失先单独运行 Server确认进程能启动检查运行命令和 Python 环境确认 SDK 正确安装客户端能看到 MCP 工具列表但调用失败Server 端缺少实际执行能力或者权限不足查看 Server 端日志确认 tools/call 是否返回异常检查工具实现代码和网络权限确保工具可独立执行Agent 加载 Skill 后没有按步骤执行SKILL.md 结构不规范或模型上下文过长被忽略检查 frontmatter 中的 description 是否匹配任务类型精简 SKILL.md 步骤描述写得更具体减少无关内容Skills 指定了 MCP 工具名但 Agent 找不到当前会话未挂载对应的 MCP Server检查 MCP Server 是否已配置并启动在客户端配置中挂载所需 MCP Server确认工具列表可见工具调用结果很大模型输出被截断上下文窗口不足查看 token 用量和上下文长度对工具结果做截断或摘要减少冗余数据这里重点提醒一个最容易踩的坑很多人把“模型工具调用失败”归结为模型笨其实大部分时候是工具定义写得不够清楚。工具的 description 写得越具体模型判断是否调用的准确率越高。这是 Tool Calling 实践中最重要的一条经验。9. 最佳实践与工程建议基于上面的分析再给出几条工程上的建议。9.1 先明确层级再动手在设计 AI Agent 工具链时先回答三个问题模型如何知道有哪些工具可用——这是 Tool Calling 机制要处理的。工具从哪里来是自己写模块还是对接标准服务——这决定要不要上 MCP。复杂任务如何保证质量——这决定要不要写 Skills。不要一上来就堆 MCP Server。如果工具数量极少直接写函数调用是更快的路径。9.2 工具描述要面向模型编写编写 Tool Calling 的函数描述时要记住阅读者是模型不是人。描述应该包含这个函数是做什么的。什么情况下应该触发它。参数的取值范围和格式。有什么副作用或注意事项。描述要具体不要写“查询天气”这样模糊的描述而是写“根据城市名称查询实时天气适用于用户询问天气、温度、降雨概率等场景”。9.3 MCP Server 要注意安全边界MCP Server 本质上是一个本地或远程服务它暴露的每个工具都可能被 AI 调用。如果工具包含高风险操作删除文件、修改数据库、推送代码必须加权限校验、操作确认和操作审计。在 MCP 工具实现中建议对工具入参做白名单校验。所有操作记录日志。高风险操作要求二次确认。Server 运行使用最小权限账号。9.4 Skills 要轻量化、可迭代Skill 文件不是越厚越好。SKILL.md 超过太长内容后模型容易忽略关键步骤。建议每个 Skill 只聚焦一类任务。步骤控制在 3-10 步以内。把大量细节拆到辅助脚本和模板里而不是塞进 SKILL.md。定期根据实际使用效果迭代比如发现 AI 总漏掉某一步就把这一步前置加粗。写 Skills 的核心思路是把你希望 AI “每次都记得做”的事情写进去把“偶尔才用到的细节”放到附件里按需加载。9.5 监控和评估要跟上不管用哪个方案都要评估 AI 的工具调用效果。建议至少记录工具调用成功率。参数校验失败率。模型判断是否准确该调用时不调用、不该调用时乱调用。端到端任务完成质量。只有持续观测才能知道是工具定义的问题、MCP 配置的问题还是 Skill 编写的问题。10. 总结与后续学习方向Tool Calling、Skills、MCP是 AI Agent 工程化中绕不开的三个概念。它们的核心区别可以归结为一句话Tool Calling 是模型调用工具的底层机制MCP 是工具供给和连接的标准化协议Skills 是面向复杂任务的轻量级方法论封装。三者不是替代关系而是在不同层级上相互配合。如果你想继续深入我的建议是按照这个顺序学习先把 Tool Calling 彻底跑通。用 Python 写一个调用函数的最小示例把“定义工具-模型请求-本地执行-结果回传”这条链路背下来。这是所有 Agent 开发的基础。再去了解 MCP。用 FastMCP 写一个自己的 MCP Server然后接进 Claude Desktop 或 Codex体验一次真正的客户端-服务端调用。最后上手 Skills。找一份优质的 SKILL.md 研究它的写法再尝试把自己团队的执行规范写成 Skill放到实际任务中验证效果。在实践过程中你还会遇到很多细节问题比如“MCP 传输层怎么选”“Skill 的 frontmatter 有哪些必填字段”“多个 MCP Server 的工具命名冲突怎么办”。这些问题在官方文档和社区里都有对应讨论带着问题去搜索比泛泛刷文章高效得多。建议你现在就把第一个 Tool Calling 示例跑起来。十分钟之后你再看 MCP 和 Skills 的文档会发现一切清晰很多。