1. 核心概念拆解：先分清三个词各管什么
近年来 Agent 类应用大量出现，大家总会看到三个高频词：Tool Calling、Skills、MCP。不少初接触的人会把它们混为一谈：都是“让模型调用外部工具”的东西，到底有什么区别？这次我们不绕弯子，直接用一句话先给出结论：
- Tool Calling 是能力，解决“模型怎么按照要求调用函数”的问题；
- Skills 是封装，解决“特定任务的工作流和提示词怎么组织”的问题；
- MCP 是协议，解决“模型与外部系统之间怎么标准化通信”的问题。
三者解决的问题不一样，但可以协作使用，也可以不依赖彼此独立存在。下面逐个拆开讲，再给对比表和选型建议。
1.1 Tool Calling 是什么
Tool Calling 通常指大语言模型在推理过程中，根据用户输入和系统提示，生成一个结构化的“工具调用请求”的能力。例如用户在对话框中问“北京今天天气怎么样”，模型本身不具备实时获取天气的能力，但它可以在输出结果中返回类似：
调用函数：get_weather(city="北京")然后由外部执行逻辑去请求天气服务，再把返回结果交给模型生成最终回答。
这个能力的核心不在“模型真正去执行了工具”，而在于模型学会了在什么时候调用什么工具，以及怎么把参数填对。很多模型在训练阶段就加入了 Function Calling / Tool Calling 数据，因此它可以输出符合函数签名的 JSON 结构化调用指令。
实际使用中，开发者通常会先把各个工具的函数定义（包括函数名、参数类型、参数说明）传给模型，模型再判断“这道题需要调用哪个函数”。这就是最常见的 Tool Calling 使用流程。
在代码层面，OpenAI 风格接口中的tools参数，Anthropic 风格接口中的tools参数，都是 Tool Calling 的一种承载方式。因此我们需要明确：Tool Calling 更多是模型侧的推理能力，它依赖模型训练效果和推理参数，需要开发者提前把“有哪些工具”告诉模型，但模型本身不关心工具背后的实现细节。
1.2 Skills 是什么
Skills 是近期被广泛讨论的概念，尤其是 Claude Skills、Codex Skills 等场景出现之后。我们可以把 Skills 理解为一组可复用、可保存、可分享的“技能包”。
一个 Skill 通常会包含：
- 一段系统级提示词或指令，描述该技能的使用场景；
- 可能包含参考示例、代码片段、规则说明；
- 有的 Skill 还会附带脚本、配置文件或工作流定义。
从功能上看，Skills 解决的是“如何让模型在特定任务上表现更好、更稳定”的问题。它本质上是对模型行为的一种工程化封装。例如你希望模型帮你写前端页面，可以准备一个“前端开发 Skill”，里面写入：
- 项目技术栈说明；
- 代码风格规范；
- 组件拆分原则；
- 常用目录结构。
当用户开启这个 Skill 后，模型会在回答时自动参考这些规范，而不是每次都要在对话里重复描述。
Skills 与 Tool Calling 并不冲突。如果 Skill 中需要调用外部数据，它也可以依赖 Tool Calling 或 MCP 完成实际数据获取；但如果 Skill 只是改变模型的回答风格和思考方式，那它不一定需要调用任何外部工具。
需要注意，不同产品对 Skills 的定义有所差异。有些实现里 Skills 是一份 Markdown 文档，有些实现里是一个目录，里面包含脚本和配置。所以在阅读各种资料时要确认语境，不能只看词面。
1.3 MCP 是什么
MCP（Model Context Protocol）是一种标准化协议，目标是让大模型应用与外部数据源、工具、服务之间的连接方式统一起来。如果把 Tool Calling 理解为“模型能调用工具的能力”，那 MCP 就是“工具怎么被统一暴露给模型”的通信标准。
一个 MCP Server 可以暴露若干工具，例如数据库查询工具、文件读取工具、GitHub 操作工具、Figma 设计稿读取工具等。客户端（比如 Claude Desktop、Codex、自研 Agent 应用）通过 MCP 协议与 Server 通信，自动发现可用工具、调用工具并获取结果。
MCP 的典型价值在于：
- 不用为每个外部系统单独写一套集成代码；
- 工具方只需要实现一次 MCP Server，就能对接多个支持 MCP 的客户端；
- 工具发现、参数校验、请求响应都有统一格式。
实际项目里，MCP Server 可以用 Python、TypeScript、Java 等语言开发，通过 stdio 或 HTTP 方式与客户端通信。很多常用工具（如数据库、浏览器、设计软件）的开源 MCP Server 已经出现，落地门槛明显降低。
2. 核心区别对比表
下面用一个表格直接对比 Tool Calling、Skills、MCP 三个概念。注意这里对比的是“核心定位”，实际产品中它们可以组合出现。
| 对比维度 | Tool Calling | Skills | MCP |
|---|---|---|---|
| 本质 | 模型推理能力 | 技能封装方式 | 通信协议 |
| 解决什么问题 | 模型如何生成工具调用指令 | 特定任务怎么组织提示词与工作流 | 模型如何连接外部系统 |
| 是否依赖模型训练 | 高度依赖 | 中等依赖 | 不依赖 |
| 是否需要额外写代码 | 通常需要处理调用逻辑 | 通常只需写提示词或配置 | 需要实现或部署 Server |
| 与外部系统通信 | 不直接负责 | 一般不负责 | 直接负责 |
| 典型承载形式 | API 参数 tools | 目录、文档、脚本 | MCP Server + 客户端 |
| 是否可独立使用 | 可以 | 可以 | 可以 |
| 是否能组合使用 | 可被 Skill 调用 | 可包含 Tool Calling 逻辑 | 可被客户端自动发现并调用 |
从上表可以看出，三者并不在同一个层级上，不是非此即彼的关系。更准确地说：
- Tool Calling 是“模型的技能底子”；
- Skills 是“应用层的技能封装”；
- MCP 是“工具接入层的通信标准”。
3. 实际工作流程对比
为了帮助理解，我用三个具体场景来说明它们在真实项目中分别长什么样。
3.1 只使用 Tool Calling 的场景
假设你在做一个问答机器人，它需要查询订单状态。此时你只需要在模型 API 请求中传入工具定义，例如在类 OpenAI 接口中：
{ "tools": [ { "type": "function", "function": { "name": "query_order", "description": "查询订单状态", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号" } }, "required": ["order_id"] } } } ] }模型在对话中如果判断需要查询订单，会返回类似：
{ "name": "query_order", "arguments": "{\"order_id\":\"20250101001\"}" }开发者的代码收到这个结构化输出后，去执行真实查询。这就是 Tool Calling 的最小闭环。
这种方式的优点是简单直接；缺点是当工具数量很多、参数复杂时，开发者需要手动维护大量函数定义，每次请求都要把全部工具定义传给模型，Token 消耗也会上升。
3.2 使用 Skills 的场景
假设你在维护一个基于 Claude Code 或类似工具的开发环境，希望模型在写 Python 代码时遵守固定的工程规范。你可以把规范写成一份 Skill 文件，例如：
# Python 工程 Skill ## 适用场景 所有 Python 后端开发任务。 ## 代码规范 1. 使用 type hints。 2. 注释使用 docstring。 3. 新代码必须包含单元测试。 ## 目录结构 - src/ - tests/ - docs/当这个 Skill 被启用后，模型在回答 Python 开发问题时，会主动参考上述规范。它不一定调用外部工具，只是“改变了行为方式”。实际项目中，可以给不同任务创建不同 Skill，例如：
- “前端开发 Skill”
- “代码审查 Skill”
- “数据库表结构设计 Skill”
- “接口文档生成 Skill”
当你积累了较多 Skill 后，可以形成自己的技能库，不同项目按需加载。这个能力与 MCP 没有必然关系，你可以只通过提示词实现，也可以用 MCP Server 来动态加载 Skill 内容。
3.3 使用 MCP 的场景
假设你需要在 Agent 中读取本地数据库，传统做法是写一段数据库操作代码，把查询函数直接注册为 Tool Calling 的工具。如果接入了 MCP，则流程变为：
- 部署一个 MCP Server，暴露
query_database方法； - 客户端通过 MCP 协议连接到该 Server；
- 客户端自动发现 Server 暴露的工具列表；
- 模型根据用户问题决定是否调用该工具；
- Server 执行查询后把结果返回给客户端。
这种方式带来的好处是：同一个数据库 MCP Server 可以被不同 Agent 客户端复用，不需要每个客户端都单独实现数据库连接逻辑。后续想增加一张表的查询能力，只需要修改 Server 端暴露的工具，客户端无需重新开发。
所以 MCP 更像一种“插件化”思路，它不替代 Tool Calling，而是把 Tool Calling 所依赖的工具接入方式标准化。
4. 容易混淆的原因分析
为什么很多人会把这三个概念搞混？主要有几个原因。
第一个原因是它们经常同时出现。比如一个 MCP Server 暴露了工具，模型调用这些工具时又需要工具调用能力，而具体调用方式和提示词又可以封装成 Skill。所以在实际代码中，三者会同时出现在同一条链路里。
第二个原因是各家产品的命名和实现不统一。OpenAI 早期叫 Function Calling，后来统称 Tool Calling；Anthropic 的 Agent SDK 里有 Tool 和 Skill 的概念；MCP 又是独立的协议标准。不同文档的术语使用习惯不同，导致对照起来很困难。
第三个原因是官方示例里常常把三者混在一起演示。Claude Skills 可以通过 MCP 加载，MCP Server 内部又依赖模型 Tool Calling 能力完成调用。表面看起来“差不多”，实际上职责分工不同。
从落地选型的角度看，不需要纠结“哪个取代哪个”，更应该关注“我的项目需要哪一层”。
5. 选型建议：什么时候该用哪个
根据实际项目阶段给出参考建议。
如果只是给现有聊天机器人增加几个简单函数调用，优先研究 Tool Calling。你只需要写清楚函数定义和调用逻辑，模型能力够强时效果就很直观，不需要引入额外协议。
如果有多个研发人员协作，希望模型在特定任务上表现稳定，适合引入 Skills。把提示词和规范沉淀为技能包，可以降低每次对话的“重新解释成本”，也便于团队共享。
如果要做工具生态集成，比如连接数据库、蓝湖、Figma、GitHub、内部系统等，适合引入 MCP。MCP 能减少点对点集成的重复劳动，让同一套工具能力在不同 Agent 客户端中复用。
如果是企业级 Agent 项目，大概率需要组合使用。先用 Skills 封装业务知识与流程规范，再用 MCP 接入内部系统，最后底层依赖模型的 Tool Calling 能力完成调用。
下面给一个简单的判断表格：
| 当前需求 | 优先方向 |
|---|---|
| 简单调用一两个 API | Tool Calling |
| 模型回答不稳定，需要约束风格/流程 | Skills |
| 多个 Agent 都要接同一套外部系统 | MCP |
| 企业级复杂 Agent 项目 | 三者组合 |
6. Skills 与 MCP 常见混淆：最需要单独说清楚的一组
从近期的技术社区讨论来看，很多人特别在意“Agent Skill 和 MCP 有什么区别”。这里单独展开讲一下。
Skills 的核心是“技能内容”，它描述的是模型该怎么做事情。它可以是一段提示词、一份规范、一组示例。Skills 不解决“怎么获取实时数据”的问题，但可以告诉模型“获取数据后该怎么处理”。
MCP 的核心是“系统接入”，它描述的是模型怎么连上外部系统。一个 MCP Server 不关心模型怎么组织回答，只负责把工具能力和数据暴露出来。
举个例子：假设你要做一个“前端开发”Agent。
- 如果你写了一个“前端开发 Skills”，里面规定项目用 Vue 3 + TypeScript，组件风格使用组合式 API，代码提交前必须跑 ESLint 等，这就是在约束模型行为。
- 如果你接入了一个“Figma MCP Server”，模型就能实时读取设计稿信息，获取图层结构、颜色值、标注数据等，这就是在打通外部系统。
两者可以同时使用：先用 Skills 定规则，再通过 MCP 拿设计稿数据，最后模型综合这些信息生成代码。
所以更精准的对比是：
- Skills 影响模型“怎么想”；
- MCP 解决模型“怎么连”。
两者不冲突，也不是同一个层级的概念。
7. 落地实践：一个最小组合案例
为了帮助理解三者如何协作，这里给出一个简化的技术方案，不绑定具体项目代码，只描述设计思路。
假设我们要做一个会议纪要 Agent，要求是：模型读取会议邀请信息，自动生成会议纪要和待办事项。
第一步，收集会议材料。这里可以通过一个“会议系统 MCP Server”暴露get_meeting_notes(meeting_id)工具，客户端通过 MCP 协议调用它获取原始材料。
第二步，定义调用逻辑。在 Agent 应用里，把获取到的会议内容传给模型，模型利用 Tool Calling 能力决定是否继续调用其他工具，比如查询参会人信息。
第三步，沉淀 Skills。我们可以把“会议纪要格式规范”写成一个 Skill，里面规定：
- 必须包含会议主题、时间、参会人、结论、待办事项；
- 待办事项必须明确负责人和截止时间；
- 待办事项使用 Markdown 列表输出。
当模型开始生成纪要时，会自动参考这个 Skill 的规范。
在这个案例里：
- MCP 负责提供会议系统数据；
- Tool Calling 负责模型在需要时调用工具获取数据；
- Skills 负责确保最终输出格式符合要求。
三者职责清晰，各管一段。
8. 常见误区与避坑建议
根据社区常见问题，罗列几个容易踩的坑。
第一个误区：把 MCP 当成了 Tool Calling 的替代品。实际上 MCP 不负责模型推理，它只是传输协议。如果你的模型本身工具调用能力差，即使接入了 MCP，调用成功率依然不会高。
第二个误区：盲目下载大量 Skill，不验证效果。很多开源 Skill 只是提示词集合，不一定适合你的业务场景。使用前应该先在小范围测试，确认输出质量稳定后再推广到团队。
第三个误区：忽略 Token 消耗。调用 Tool Calling 时如果工具定义过多，每次请求都会占用大量 Token。MCP 虽然能自动发现工具，但也要控制暴露给模型的范围，否则大而全的工具列表反而会降低模型选择准确性。
第四个误区：安全意识不足。MCP Server 一旦暴露敏感系统数据，必须做好鉴权与访问控制。特别是企业内部数据库、设计稿、用户信息等场景，要遵循最小权限原则。
第五个误区：认为 Skills 能解决所有问题。Skills 本质是提示词和行为规范，它无法突破模型能力上限。如果模型本身逻辑能力弱，再好的 Skill 也难以让输出质量有质的提升。
9. 总结与下一步建议
Tool Calling、Skills、MCP 是三个不同维度的重要概念。它们简单说就是：
- Tool Calling 是模型能调用工具的“内功”；
- Skills 是让模型按规范做事的“操作手册”；
- MCP 是让模型接入外部系统的“插线板”。
实际项目里可以根据需求单独使用，也可以组合使用。当前更值得关注的是 MCP 生态的快速扩展，以及 Skills 在编程助手场景中的落地效果。
如果打算亲自上手验证，建议按下面顺序展开：
- 先跑通一个 Tool Calling 最小示例，理解函数定义、参数传递和结果返回流程；
- 再写一个简单的 Skill，验证提示词对模型输出行为的约束效果；
- 最后部署一个 MCP Server，把它接入支持 MCP 的客户端，观察工具自动发现和调用过程。
从最简单的例子开始，逐个确认每个层级的职责边界，形成自己的判断框架后，再看各类新闻和教程就不容易被术语绕晕了。
