最近在梳理 AI Agent 应用时有个问题经常被问到Tool Calling、Skills、MCP 到底分别是什么它们之间有什么区别很多同学在看 Claude Code、Codex、OpenAI 相关文档时会发现这三个概念经常同时出现一会儿说“模型通过 Tool Calling 调用函数”一会儿说“为 Agent 添加 Skills”一会儿又说“通过 MCP 接入外部服务”如果只看名词解释很容易绕晕。这篇文章会把这套概念彻底讲清楚。我会先用通俗的话解释每个概念是什么再给出完整的代码和配置示例最后用一张对比表总结它们的边界与联系。不管你是刚接触大模型应用开发的新手还是已经在做 Agent 项目的开发者这篇文章都能帮你建立一个清晰的认知框架。先说结论三者其实不在同一个层级。Tool Calling 是模型的一种输出能力Skills 是 Agent 的能力封装方式MCP 是连接外部工具的标准化协议。它们可以组合使用但解决的问题各不相同。1. 背景为什么大模型应用突然需要这么多“新概念”1.1 模型不只会“聊天”还需要“动手办事”大语言模型本身是一个文本生成模型它的输入是文本输出也是文本。早期的 ChatGPT 类产品用户问什么模型就答什么两者之间只有“对话”这一层交互。但在真实的业务场景中我们往往希望模型不只是回答而是能帮我们完成实际操作。例如查询天气时模型需要调用天气服务 API而不是靠训练数据里的旧信息硬答。查询订单状态时模型需要访问数据库或业务系统。写代码时模型需要读取项目文件、执行命令、运行测试。画原型图时模型需要操作 Figma 中的画板和图层。这些需求已经不是“生成文本”能覆盖的了模型必须有能力与外部系统发生交互。于是工具、技能、标准协议这些概念被陆续引入到大模型应用开发中。1.2 三个概念为什么会同时出现如果你把 AI Agent 类比成一个新入职的员工就很好理解这三者的关系Tool Calling工具调用解决的是“模型能不能调用工具”。它像员工拿到一个电话知道拨号就能联系到外部的人。Skills技能解决的是“模型怎么把一件事做好”。它像员工的岗位手册里面写了做事的步骤、规范、注意事项。MCP模型上下文协议解决的是“如何标准化地连接工具”。它像公司统一的工位接口标准无论是显示器、键盘还是网线插上就能用。现在很多项目把这三个词放在一起讨论是因为一个完整的 Agent 应用往往同时需要它们用 Skills 定义任务流程用 Tool Calling 让模型触发具体操作用 MCP 统一接入外部工具。2. Tool Calling让模型学会“输出调用请求”2.1 什么是 Tool CallingTool Calling在国内常被称为“工具调用”或“函数调用Function Calling”指的是大模型在生成回复时输出一个结构化的“调用请求”请求中包含了需要调用的函数名和参数然后由外部程序真正执行这个函数并把结果返回给模型模型再基于结果组织最终回答。这里有一个关键点模型本身并不执行函数它只负责输出“我要调用什么函数、参数是什么”。真正执行函数的是你的应用程序代码。例如模型接到用户提问“北京今天多少度”模型内部判断需要调用天气查询工具于是输出类似下面的结构化内容{ name: get_weather, arguments: {\city\: \北京\, \date\: \今天\} }你的后端程序解析这个 JSON调用真实的天气 API拿到结果后把它作为一条新的消息返回给模型模型再回答“北京今天 24 摄氏度晴”。2.2 Tool Calling 的工作流程一次完整的 Tool Calling 流程通常分四步第一步开发者预先定义工具。你需要告诉模型有哪些函数可用、每个函数的参数结构是什么。这个过程通常通过 JSON Schema 完成。第二步模型判断是否调用工具。当用户的问题需要外部数据或操作时模型会在回复中携带 tool_calls 字段而不是直接输出文本。第三步应用程序执行工具。你拿到模型输出的工具名称和参数后在本地代码中调用对应的函数得到真实的结果。第四步把结果回传给模型。工具执行结果会以一个新的消息角色通常是 tool返回给模型模型结合原始问题和工具结果生成最终的用户答复。2.3 代码示例OpenAI 风格的 Tool Calling下面我们用一个最简单的天气查询示例来演示这种模式。这个例子中我们定义了 get_weather 函数模型会返回需要调用它的请求然后我们手动执行并返回结果。# 文件路径tool_calling_demo.py import json # 第一步定义工具 tools [ { type: function, function: { name: get_weather, description: 查询指定城市当天的天气情况, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如 北京、上海 } }, required: [city] } } } ] # 模拟模型返回的工具调用请求 def mock_model_response(user_query): # 实际项目中这里会调用 OpenAI / Claude / 通义千问等模型的接口 # 为方便演示我们直接返回一个模拟的工具调用结果 if 天气 in user_query: return { tool_calls: [ { id: call_001, type: function, function: { name: get_weather, arguments: json.dumps({city: 北京}) } } ] } return None # 第二步真正执行工具 def execute_tool_call(tool_call): func_name tool_call[function][name] args json.loads(tool_call[function][arguments]) if func_name get_weather: # 模拟真实天气接口返回 return json.dumps({city: args[city], weather: 晴, temperature: 24℃}) raise ValueError(f未知工具: {func_name}) # 第三步主流程 user_query 北京今天天气怎么样 response mock_model_response(user_query) if response and response.get(tool_calls): for tool_call in response[tool_calls]: result execute_tool_call(tool_call) print(工具执行结果:, result) else: print(模型直接回答:, response)运行结果如下工具执行结果: {city: 北京, weather: 晴, temperature: 24℃}在实际项目中你还需要把工具执行结果回传给模型模型会基于这个结果输出给用户的最终文案。示例中为了聚焦 Tool Calling 的核心流程我们简化了这一步。2.4 Tool Calling 的边界Tool Calling 虽然很强大但它本身有几个明显的限制工具需要预先注册。每接入一个新工具都要写函数定义和参数 Schema集成成本高。模型只负责输出意图不感知执行细节。例如网络超时、参数格式出错、返回结果异常模型都无法自动处理。工具之间的协议不统一。有的工具走 REST API有的工具是本地命令有的工具需要数据库连接接入方式五花八门。它只是“能力开关”。模型知道可以调用某个函数但并不知道什么时候该用、怎么组合多个函数完成复杂任务。这些限制催生了另外两个概念Skills 解决“怎么做好一件事”MCP 解决“工具接入标准化”。3. Skills把“做事的方法”封装成能力3.1 什么是 SkillsSkills 这个词在不同产品里含义略有差异但核心思想是一致的Skills 不是单个函数接口而是一套可复用的“能力包”里面包含任务流程说明、提示词规则、参考文档、脚本等用来指导 Agent 如何完成某类特定任务。以 Claude Code 和 Codex 中的 Skills 为例它的表现形式通常是一个包含 SKILL.md 文件的目录。这个文件里描述了技能的名称、适用场景、执行步骤、注意事项有时还附带一些脚本和参考文档。当 Agent 遇到相关任务时会读取这个目录中的内容按照里面的指导去工作。可以这样理解Tool Calling 回答的是“我能调用什么”Skills 回答的是“我该怎么把这件事做好”。Skills 更像是把人类的项目经验、操作规范、领域知识沉淀下来变成 Agent 可以使用的方法论。3.2 Skills 的典型目录结构下面是一个常见的 Skills 目录结构以“代码审查”技能为例code-review-skill/ ├── SKILL.md # 技能主文件描述技能做什么、怎么用 ├── scripts/ │ └── run_lint.sh # 辅助脚本例如执行代码检查 ├── reference/ │ ├── rule_1.md # 参考规则安全审查清单 │ └── rule_2.md # 参考规则性能优化检查项 └── examples/ ├── good-review.md # 好的审查示例 └── bad-review.md # 不好的审查示例在这个结构中SKILL.md 是核心Scripts 目录存放可执行的辅助脚本Reference 目录存放供 Agent 查询的领域知识Examples 目录则提供示例。3.3 SKILL.md 里写什么SKILL.md 通常使用 Markdown 格式用 YAML front matter 声明元信息再用正文描述技能的详细说明。下面是一个简化示例--- name: code-review description: 对 Python 项目进行代码审查重点关注安全性、性能和可维护性。 --- # 代码审查技能 当用户要求“审查代码”或“Review 代码”时使用本技能。 ## 执行步骤 1. 首先阅读待审查的代码文件理解功能逻辑。 2. 使用 scripts/run_lint.sh 执行静态检查记录问题。 3. 依据 reference/rule_1.md 的安全清单检查输入校验、SQL 注入等风险。 4. 依据 reference/rule_2.md 的性能清单检查循环、查询、内存使用。 5. 输出审查报告按严重程度分级。 ## 注意事项 - 不要修改源代码只输出审查意见。 - 如果要运行命令必须先向用户确认。 - 如果代码量较大优先审查 diff而不是全部文件。当 Agent 被要求做代码审查时如果它加载了这个 Skills就会按照上面定义的步骤来执行。这就是 Skills 的价值它把“怎么做代码审查”这种经验知识变成机器可遵循的流程。3.4 Skills 与 Tool Calling 的区别Skills 和 Tool Calling 很容易混淆因为它们都跟 Agent 完成任务有关。但它们的层级不同维度Tool CallingSkills本质模型的输出能力任务执行方法封装回答的问题能调用哪个函数怎么把事情做好是否包含提示词一般不含通常包含大量提示词和流程说明是否包含脚本不含只有函数签名可能包含辅助脚本示例查询天气函数代码审查流程、测试编写流程可以这样理解Tool Calling 是“手”Skills 是“大脑中的操作手册”。手能执行动作但怎么高效、规范地执行动作需要手册来指导。4. MCP统一外部工具连接的标准化协议4.1 什么是 MCPMCPModel Context Protocol模型上下文协议是由 Anthropic 提出的开放协议用于标准化 AI 应用与外部数据源、工具之间连接方式。它解决的核心痛点是每个工具接入都要单独开发适配器非常碎片化。在 MCP 出现之前如果要在 AI 应用里接入 GitHub、Google Drive、Figma、数据库等工具每个都需要单独写集成代码。每换一个 AI 客户端又要重新适配一遍。MCP 的目标就是制定一个统一的标准让工具提供商只需要按协议实现一次就能被所有兼容的 AI 应用使用。可以把 MCP 理解成 AI 世界的“USB-C 接口”过去的工具接入像各种不同的充电线互不兼容MCP 之后大家统一用同一个接口标准插上就能用。4.2 MCP 的角色与架构MCP 采用客户端-服务器架构涉及三个角色MCP Host主机AI 应用程序例如 Claude Desktop、支持 MCP 的 IDE 插件、自定义 Agent 程序。MCP Client客户端运行在 Host 内部负责与 MCP Server 建立一对一的连接完成协议通信。MCP Server服务器向 Client 暴露工具Tools、资源Resources和提示词Prompts。它负责真正访问外部系统并把能力、数据提供给 AI 应用。在 MCP 中工具Tool被定义为“可供模型调用的函数”。每个工具都有名称、描述和输入 Schema。客户端可以通过协议标准能力发现这些工具并在需要时触发调用。4.3 最小 MCP Server 示例下面是一个基于 Python 的 MCP Server 最小示例使用官方 Python SDK 中的 FastMCP 类。该示例会暴露一个 add 工具供支持 MCP 的客户端调用。# 文件路径mcp_demo_server.py from mcp.server.fastmcp import FastMCP # 创建 MCP Server名称是 demo-server mcp FastMCP(demo-server) mcp.tool() def add(a: int, b: int) - int: 求两个整数之和 return a b mcp.tool() def get_today_weather(city: str) - str: 查询城市天气用于演示自定义工具 # 这里可以替换成真实天气 API 调用 return f{city}晴24℃ if __name__ __main__: # 启动 MCP Server默认走 stdio 传输方式 mcp.run()运行这个脚本后MCP Server 会监听标准输入输出。支持 MCP 协议的客户端例如 Claude Desktop、自研 Agent可以连接到这个服务自动发现 add 和 get_today_weather 两个工具并按需调用。需要注意示例中 FastMCP 的写法依赖于当前版本的 mcp Python 包如果版本更新导致 API 变化请以官方文档为准。4.4 MCP 解决了什么问题MCP 的核心价值主要体现在三个方面标准化连接。所有工具都通过同一套协议接入不需要为每个工具定制集成逻辑。工具自动发现。根据协议客户端可以发现服务器上所有可用的工具、资源和提示词无需手工配置工具清单。上下文管理。MCP 不仅仅是函数调用它还可以暴露“资源”给模型读取。例如让模型读取一个文档、一段日志、一个数据库 schema这些都属于“上下文资源”的范畴。目前 MCP 生态已经在快速增长Figma、GitHub、Playwright、SQLite、各类数据库都有对应的 MCP Server社区热度非常高。5. 三者区别与组合方式5.1 核心对比表为了帮助快速理解我整理了一张对比表维度Tool CallingSkillsMCP定位模型输出能力任务方法封装连接协议核心问题模型能否调用外部函数模型如何把事情做好工具如何统一接入层级模型层应用层连接层表现形式函数 Schema 结构化输出SKILL.md 目录 脚本 文档MCP Server 协议是否需要写代码需要定义函数和 Schema主要是提示词、流程和脚本需要实现 Server 或配置现成 Server典型使用方式定义 get_weather 函数供模型调用写一个 code-review skill配置 GitHub MCP Server 让 Agent 操作仓库能否独立存在可以可以可以实际项目中的关系Agent 执行动作的基础能力指导 Agent 怎么编排和操作为 Agent 提供标准化的工具访问渠道5.2 三者如何协作在实际项目中三者往往是协作关系。我们用一个实际场景来说明。假设我们要做一个“自动化代码审查 Agent”用户的诉求是给定一个 GitHub PRAgent 自动审查代码并给出修改建议。在这个项目中MCP 负责连接 GitHub。通过 GitHub 的 MCP ServerAgent 可以获得读取 PR 内容、读取文件 diff、提交评论的能力。Tool Calling 负责触发具体操作。当 Agent 判断需要读取文件时它会输出调用 get_pull_request_files 工具的请求由 MCP 的 Client 执行。Skills 负责定义审查流程。我们编写一个 code-review-skill告诉 Agent 审查顺序、关注哪些风险点、如何输出报告。执行流程大致如下用户提交 PR 链接。Agent 加载 code-review-skill获得审查流程和规则。Agent 通过 MCP 连接 GitHub Server发现可用的工具列表。Agent 通过 Tool Calling 触发读取 PR 文件、获取 diff 等操作。Agent 按 Skills 中的规则分析代码生成审查报告。可以看到三者在这个流程中各司其职MCP 提供通道Tool Calling 提供动作触发Skills 提供任务方法论。5.3 实际产品中的组合形态在 Claude Code 和 Codex 中这种组合已经比较成熟。Claude Code 支持通过配置安装各种 Skills。例如你可以把项目里“前端开发规范”“测试用例编写流程”封装成 SkillsAgent 在相应场景下自动加载。同时Claude Code 也支持配置 MCP Server接入内部数据库、文件系统、外部 API 等。Codex 也有类似能力。社区里一个很常见的用法是配置 Figma MCP Server让 Codex 能读取设计稿信息再结合“设计稿转页面”相关的 Skills实现从设计到代码的半自动开发。这类场景在社区里的热门话题包括“figma mcp 在 codex 中总是工具注册不上”“codex 如何接入 mcp”这些都是典型的集成期问题后面常见问题部分会提到。6. 常见问题与排查思路6.1 常见问题结合社区里的高频反馈这里整理一些典型的踩坑场景。问题现象可能原因解决思路模型没有触发工具调用工具描述和参数 Schema 不够清晰优化工具名称和描述让模型更容易理解何时该调用模型调用工具时参数格式错误Schema 中对参数约束不足在 parameters 中明确类型、必填项和枚举值Skills 没有生效SKILL.md 目录结构不符合要求或放在错误路径检查 Skills 目录位置、文件名和 front matter 格式Agent 不按照 Skill 中的步骤执行Skill 描述不明确或与用户指令冲突增强 SKILL.md 中的执行步骤描述明确适用条件MCP Server 连接失败依赖库缺失、传输方式不匹配、服务未启动检查 MCP Server 日志确认 stdio 或 SSE 配置一致Figma MCP 在 Codex 中工具注册不上MCP Server 启动失败、Token 无效、或协议版本不兼容先在本机独立测试 MCP Server再确认 Codex 的 MCP 配置和权限Skills 与 MCP 概念混淆不清楚两者差异在聊天中问“这俩是不是一回事”参考本文第 5 节对比表按各自边界设计6.2 排查 MCP 工具的通用步骤如果你在某个 Agent 产品中配置了 MCP Server但发现工具总是注册不上可以按以下顺序排查第一步确认 MCP Server 能独立启动。在终端直接运行 MCP Server 脚本看是否报错。第二步检查依赖安装。如果是 Python 项目确认 mcp、fastmcp 等依赖已正确安装。第三步检查配置格式。不同客户端对 MCP 配置的 JSON 格式要求略有不同注意检查命令、参数、环境变量的写法。第四步查看客户端日志。大多数 AI 编程工具都支持开启调试日志日志中会显示 MCP 初始化的过程定位失败原因。第五步换一个简单的 MCP Server 测试。例如先用官方仓库里的 Example Server 测试配置是否正常排除是自定义 Server 代码的问题。7. 基于实际项目的设计建议7.1 工具设计规范在使用 Tool Calling 时工具的命名和描述直接影响模型调用的准确性。建议遵循以下规范工具名使用动词开头的英文例如 get_user_info、send_email、create_task避免模糊的 do_stuff。描述字段写清楚“什么时候该调用”“参数代表什么含义”。例如“当用户查询订单物流信息时调用此工具”比“查询订单”更容易让模型理解。参数 Schema 尽量约束严格。必填参数放到 required 数组中可选参数加默认值枚举类型用 enum 限制。一个工具只做一件事。不要把多个功能塞进一个工具里否则模型会困惑该传哪些参数。7.2 Skills 设计建议Skills 的内容质量决定了 Agent 执行任务的稳定性。编写 SKILL.md 时要注意在 Front Matter 中写清楚技能名称和适用场景方便 Agent 判断何时加载该技能。正文中的执行步骤要足够具体最好能细化到“读哪个文件”“跑什么命令”“按什么顺序输出”。把容易变化的规则、清单放到 Reference 目录下的独立文档中避免 SKILL.md 过长影响 Agent 的读取效果。对需要执行的命令必须在 Skills 中明确“需要用户确认”的边界避免 Agent 擅自执行危险操作。7.3 MCP 落地建议MCP 在项目的落地过程中需要关注以下几点优先选用社区维护成熟的 MCP Server。例如 GitHub、Figma、Playwright、Postgres 等都有官方或社区高赞实现不要重复造轮子。MCP Server 单独部署通过配置接入。不要把 MCP Server 的逻辑和业务代码耦合在一起。注意权限控制。MCP 负责连接外部工具必须有清晰的权限边界不能让 Agent 通过 MCP 无限制地执行写操作。生产环境使用 MCP 时需要对 Server 的调用记录做日志审计方便追溯 Agent 对工具的每一次访问。7.4 安全边界无论使用哪种方式接入工具安全都是重要问题。建议始终遵循以下原则最小权限原则。只为 Agent 开放的 API 或数据库账号配置执行任务所需的最小权限。写入操作二次确认。涉及删除、更新、发送消息等高危操作必须在代码中增加确认环节。输入校验。调用工具的入参必须经过校验防止 Agent 生成恶意参数污染业务数据。审计日志。所有工具调用都应该记录日志包含调用时间、调用参数、返回结果方便回溯问题。8. 总结用一张图分清三者的关系如果用一句话总结三者的关系可以这样记Tool Calling 让模型能调用工具。Skills 让模型知道怎么做事。MCP 让工具可以统一接入。拿 Agent 做代码审查来举例MCP 是让 Agent 能访问 GitHub 的通道Tool Calling 是 Agent 触发“读取文件”“提交评论”的动作开关Skills 是指导 Agent 怎么一步步完成审查的方法手册。三者配合才能让 Agent 真正稳定地完成一个端到端任务。在实际工程中建议你先根据业务场景选择技术路线如果只是给聊天机器人加一个查询天气的功能直接用 Tool Calling 就够了不需要硬上 MCP如果要做一套能接入多种外部系统的 Agent 平台MCP 是更值得投入的标准化方案如果希望 Agent 能高质量地完成某类专业任务比如代码审查、测试编写、前端开发那么把经验和流程沉淀成 Skills 是非常有效的做法。三个概念并不冲突更不是替代关系。理解清楚了你就不会再被各种新名词绕晕也能在合适的场景用上正确的方法。如果你也在做 Agent 开发建议近期动手试一下把一个常用工具封装成 MCP Server再写一个简单的 Skill然后在你的 Agent 里跑通一个真实任务这样比只看文档理解得深刻得多。