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 是什么MCPModel 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 CallingSkillsMCP本质模型推理能力技能封装方式通信协议解决什么问题模型如何生成工具调用指令特定任务怎么组织提示词与工作流模型如何连接外部系统是否依赖模型训练高度依赖中等依赖不依赖是否需要额外写代码通常需要处理调用逻辑通常只需写提示词或配置需要实现或部署 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 CallingAnthropic 的 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 能力完成调用。下面给一个简单的判断表格当前需求优先方向简单调用一两个 APITool 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 的客户端观察工具自动发现和调用过程。从最简单的例子开始逐个确认每个层级的职责边界形成自己的判断框架后再看各类新闻和教程就不容易被术语绕晕了。