最近很多做 Agent 开发的同学都在同一段时间里反复遇到三个词Tool Calling、Skills、MCP。尤其在 Claude Code、Codex、Cursor 这些工具之间切换时你会同时看到 MCP Server 配置、Skills 目录、工具注册报错。很多人第一反应是“这不都是给模型加能力吗”实际并不是。三个概念分工完全不同如果混着理解后面排查问题会非常痛苦。这篇文章先把三个概念放到同一张图里讲清楚再拆开讲各自的底层逻辑最后给出对比表格和一套可以照做的落地排查顺序。适合刚开始接触 Agent 开发、在本地或云端折腾各类编程助手、或者正在研究“为什么工具注册不上”“为什么 Skill 不生效”的同学。1. 先用一张图理解三者的分工在进入细节之前先记住三句话Tool Calling 是模型与外部函数之间的调用机制。Skills 是模型可以按步骤执行的能力说明书。MCP 是外部工具接入模型的统一接口协议。这三句话分别回答三个问题模型怎么调用工具、模型怎么学会一套做事流程、工具怎么接到模型上。很多人把这三种东西混在一起是因为它们都出现在 Agent 的“工具链”配置里但实际作用层次完全不同。1.1 Tool Calling模型输出里的函数调用指令Tool Calling 最早被大家熟悉是从 Function Calling 开始的。它让大模型在生成文本之外额外输出一个结构化调用指令比如“调用 get_weather参数 city北京”。这个指令会被应用程序解释并执行执行结果再返回给模型形成一轮完整的多步推理。它本质上是模型在 API 层的一种输出能力。你不需要自己定义协议只需要在请求里声明有哪些工具模型自主决定要不要调用、以什么参数调用。这是所有 Agent 应用最底层的那块砖。1.2 Skills给模型看的一套流程文件Skills 是最近一年里被 Claude Code、Codex 等工具带火的概念。你可以把它理解成一个文件夹里面有一个 SKILL.md 文件记录某个任务怎么做、输出格式是什么、要不要调用脚本、有哪些注意事项。模型遇到相关任务时会读取这个文件然后按文件里的步骤执行。Skill 不是代码层面的工具而是一份给模型看的操作手册。它本身不会像 MCP Server 那样暴露接口但它可以在步骤里要求模型去调用工具或执行脚本。1.3 MCP把工具变成统一接口MCP 全称 Model Context Protocol是一套开放的协议。它解决的核心问题是过去每个工具都要为每个客户端单独开发适配层现在只要写一个 MCP Server就能被 Claude Desktop、Claude Code、Codex、Cursor 等多个客户端共用。MCP Server 会通过标准接口向客户端暴露三类内容Resources资源、Tools工具、Prompts提示模板。客户端通过 MCP 协议把这些内容提供给模型模型再通过 Tool Calling 机制去调用 MCP Server 里的工具。2. 深入理解 Tool Calling模型怎么从“会聊天”变成“会干活”Tool Calling 是所有 Agent 功能的地基。没有它模型最多只能基于上下文生成回答无法真正操作系统、访问数据、改变外部状态。2.1 核心流程拆解一次完整的工具调用通常包括五步应用把系统提示和工具定义一起发给模型。模型根据用户问题决定是否调用某个工具。模型返回结构化调用结果而不是直接返回最终文本。应用执行工具把结果作为新的消息发给模型。模型结合工具结果生成最终回答。这里最容易忽略的是第四步。模型本身不会执行任何代码它只负责“决定调什么、参数是什么”。真正执行工具的是你的应用程序。所以如果工具执行容器的权限、路径、环境变量有问题模型再聪明也没用。2.2 两种主流的工具定义方式以 OpenAI 风格为例一个工具定义大致是这样{ type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: { type: string } }, required: [city] } } }以 Claude 的 tool use 为例模型返回的是一个 tool_use block包含 tool_use_id、name、input 三部分。应用把工具结果返回给模型时要带上对应的 tool_use_id模型才能把这个结果对应到当时那一次调用上。2.3 判断 Tool Calling 是否正常在实际项目中判断工具调用是否正常不要只看模型有没有返回工具名称要看三个点返回值是否正确参数有没有缺失、类型对不对。回传结构是否完整tool_use_id、结果内容是否都带上。多轮调用是否连贯模型可能连续调用多个工具需要在循环里正确处理。我一般会先用一条最简单的问题测试“单工具单轮调用”。确定没问题后再测试连续调用和并发调用。不要一上来就把十几个工具塞给模型工具太多时模型反而容易选错。3. 深入理解 Skills把经验沉淀成模型能读的说明书Skills 解决的是“模型知不知道这件事应该怎么做”。工具可以给它执行能力但怎么组织执行顺序、按什么标准判断结果、输出成什么格式这些是 Skill 的内容。3.1 一个 Skill 到底包含什么一个完整的 Skill 通常包含任务描述、使用条件、执行步骤、输出规范、常见误区、依赖脚本和资源文件。它把散落在文档、对话、个人经验里的做事方法固化成模型可以直接读取的文件。Skill 的最大价值是复用。你不需要每次对话都把同一套工作流重新写一遍只要让模型知道在什么场景下加载哪个 Skill 即可。很多团队把测试流程、代码审查规范、接口文档生成标准做成 Skill效果比单纯在系统提示里塞一堆规则要稳定得多。3.2 SKILL.md 的标准结构以 Claude Code 的 skills 目录为例一个 Skill 通常是这样组织的my-skill/ ├── SKILL.md ├── scripts/ │ └── check.py └── assets/ └── template.mdSKILL.md 的开头包含 YAML frontmatter用于声明 name 和 description。description 是整个 Skill 是否会被模型激活的关键通常要求写清楚“在什么情况下使用”。如果 description 写得太宽泛模型可能在任何时候都尝试加载它导致上下文被浪费写得太窄模型又根本不会调用。正文部分是给模型看的操作手册建议按顺序写清楚步骤、输出格式、边界条件和错误处理方式。下面是一个很简化的示例--- name: code-review description: 当用户要求审查 Python 代码、检查潜在 bug 或安全问题时使用 --- 1. 先列出需要审查的文件。 2. 按可读性、性能、安全性三个维度检查。 3. 输出 Markdown 清单每条必须标注严重度。这里“描述”决定了模型什么时候触发这个 Skill正文决定了模型具体怎么做。两部分的颗粒度要均衡不能前面写得很细、后面很空。3.3 Skill、Prompt、Tool 三者的边界这里非常容易混。我见过两种常见的理解错误。第一种是把 Skill 当成普通 Prompt。Prompt 是对话里的角色和任务说明Skill 更像一整套可复用的方法论文件通常还带脚本资源和工具调用建议。第二种是把 Skill 当成 Tool。Tool 是运行在宿主进程里的具体函数或外部接口Skill 只是模型按流程执行的文字说明。不过 Skill 内部可以调用 Tool两者不是对立关系而是协作关系。4. 深入理解 MCP统一接入层的设计思路MCP 是这三个概念里最“工程化”的一个。它不改变模型能力而是改变外部工具接入模型的方式。4.1 为什么需要 MCP在没有 MCP 之前每个客户端接入外部数据源都要写一套自己的适配逻辑。拿 Figma 来说Claude 要接一个 Figma 插件Codex 也要接一个 Figma 插件两套代码完全不一样。MCP 出现后你只需要启动一个 Figma MCP Server它就能同时被多个客户端复用。从工程角度看MCP 做的事很接近标准化接入层客户端负责协商和调用服务端负责提供资源和工具底层用 JSON-RPC 通信。设计思路和数据库驱动、打印机驱动类似用统一协议屏蔽底层差异。4.2 MCP Server 暴露的三类能力MCP Server 通常暴露三类内容Tools可执行的函数类似 Tool Calling 里的工具由模型决定调用。Resources服务器提供的数据资源类似文件、数据库记录、项目文档。Prompts预设的提示模板客户端可以直接复用。日常开发里接触最多的是 Tools。你在配置 MCP 后客户端会自动发现这些工具并加入模型可用的工具列表。之后仍然是靠 Tool Calling 机制去调用MCP 本身不替代 Tool Calling而是让工具的接入变得统一。4.3 一个典型的 MCP 配置长什么样常见客户端的 MCP 配置是一个 JSON 片段里面声明了服务名称、启动命令、参数和环境变量。下面是一个示例具体包名和参数要以你实际使用的 Server 为准{ mcpServers: { figma: { command: npx, args: [-y, figma-mcp-server, --stdio], env: { FIGMA_API_KEY: your-key } } } }MCP 的传输方式常见有两种stdio 和 HTTP/SSE。stdio 模式适合本地命令行工具客户端直接启动子进程并通过标准输入输出通信HTTP/SSE 模式适合远程服务也更容易和团队共享。典型场景包括文件系统访问、浏览器自动化、数据库查询、Figma 设计稿读取、Playwright 页面操作等。热词里那些“figma mcp”“playwright mcp”“chat2db mcp”都属于这一类通过一个标准 Server把特定领域能力开放给模型。5. 三者的核心区别和协作方式理解了各自定义再看区别就很清楚了。不过很多人还是会在实际选型时犹豫所以这里把对比和协作关系一起说。5.1 一份直白的对比表维度Tool CallingSkillsMCP本质模型的输出能力与运行时机制模型可读取的执行手册工具接入的统一协议关注点模型如何请求调用函数模型如何按流程做事工具如何被客户端发现和调用由谁执行宿主应用执行函数主要由模型执行流程可调用脚本服务端执行工具逻辑是否需要定义协议不需要API 层已支持不需要但需约定文件格式需要基于 JSON-RPC典型产物工具定义 JSON、回调处理SKILL.md 文件夹MCP Server 程序适用范围所有支持函数调用的模型支持 Skills 的客户端支持 MCP 的客户端5.2 三者如何协作一个比较典型的工作流是这样的你启动了一个 MCP Server暴露了 get_figma_design 工具。客户端通过 MCP 协议发现了这个工具把它加进模型可用的工具列表。模型通过 Tool Calling 机制决定调用 get_figma_design。在调用的过程中模型读取了某个 Skill 里的设计稿审查流程文件。模型按 Skill 步骤检查设计稿并把结果按指定格式输出。换句话说MCP 负责“把工具送进来”Tool Calling 负责“让模型调得动工具”Skills 负责“让模型知道怎么用工具做成一件事”。三者正好组成一条完整链路。5.3 场景选择建议如何决定优先用哪个如果你的目标是让模型能查询数据库、操作文件、打开浏览器优先配置 MCP Server。如果你的目标是让模型按固定流程产出某种格式的内容优先写 Skill。如果你的目标是开发自己的 Agent 应用你需要自己实现 Tool Calling 流程MCP 和 Skills 只是不同的输入和扩展来源。这里没有“谁替代谁”的关系只有“当前缺哪一层”的问题。6. 实操中最容易踩的坑和排查顺序概念讲完之后落地才是重点。根据大家在社区里遇到的典型问题我整理了三个高频场景的排查思路。6.1 Skill 写好了但模型不用优先检查这几点description 是否写清楚触发条件。模型靠 description 决定要不要加载 Skill。文件路径是否正确。Claude Code 里 Skill 通常放在 .claude/skills 目录Codex 里不同版本位置不一样要先确认版本。任务描述是否含糊。你写“审查代码”模型不一定知道从哪个文件开始如果你写“读取 src 目录下所有 Python 文件并输出按严重度排序的问题清单”就明确很多。Skill 是否要求了模型没有权限执行的操作比如访问某个受保护目录。如果以上都没问题用一条最简单、最典型的任务测试并打开日志看模型是否真的读取了 Skill 文件。很多时候不是 Skill 写得不对而是根本没有被触发。6.2 MCP Server 配好了但工具注册不上这是热词里出现频率非常高的问题尤其是 Figma MCP 在 Codex 里注册不上。排查顺序一般是这样先确认 Server 进程是否真的启动了。可以在本地单独启动 MCP Server看看有没有报错输出。再确认配置文件的命令和参数是否完整。stdio 模式下命令路径、参数、环境变量每一个都要核对。检查客户端是否支持该传输模式。有的客户端对 SSE 的支持有版本差异。查看客户端日志。注册失败一般会给出具体的握手错误或 JSON-RPC 错误信息。最后才怀疑工具本身的兼容性比如 Node 版本、Python 版本、依赖是否安装齐全。我自己的习惯是先单独启动 Server 验证再接入客户端。不要在客户端里反复重启那样很难判断是配置问题还是服务问题。6.3 建议的学习和落地顺序给刚接触这些概念的同学一个建议顺序先学 Tool Calling。用一个支持函数调用的模型 API写一个最简单的“查询天气”Demo。再学 MCP。把别人写好的 MCP Server 接入 Claude Code 或 Codex观察工具列表和调用日志。最后学 Skills。写一个属于自己的 SKILL.md从一个具体小任务开始比如“输出周报”“做代码审查”“生成接口文档”。每一步都要先跑通最小用例再扩展到复杂场景。不要同时开十几个工具、多个 Skill、多套 MCP Server那样出了问题根本不知道从哪查起。踩过几次之后我发现很多问题不是模型能力不够而是接入层和流程层没有分开理解。Tool Calling、Skills、MCP一个管运行时调用一个管做事方法论一个管工具接入标准。把这三个层次拆开看配置和调参的很多困惑都会自动消失。