Tool Calling、Skills、MCP 这三个词最近几乎是 AI 开发群里讨论最多的一组概念。看了几个教程你会发现一个现象有的教程说“让模型学会用工具”有的说“把技能打包塞给 Agent”还有的说“用一套协议连接所有服务”。如果只看结论很容易把三者当成同一个东西。实际上它们处于完全不同的层次解决的是不同问题而且在真实项目里往往会同时出现。一句话先把关系理清Tool Calling 是模型调用外部功能时使用的“执行机制”Skills 是打包好的“技能包/工作流文件”MCP 是标准化工具接入的“通信协议”。这篇文章我会从开发者视角逐个拆解讲清楚运行过程、典型实现、适用场景最后再演示三者如何配合落地。1. 核心概念速览在展开细节之前先把三者的基本规格列出来。后面所有内容都围绕这张表展开。维度Tool CallingSkillsMCP本质定位模型层的执行机制Agent 层的能力包工具层通信协议核心问题模型如何生成结构化函数调用如何让 Agent 按需加载复杂流程如何统一接入外部工具和数据源是否需要模型支持需要依赖模型训练和 API 支持部分需要依赖客户端和模型的理解能力不需要服务端与模型无关典型实现OpenAI Function Calling、Anthropic Tool UseClaude Skills、Codex Skills 等Model Context Protocol、MCP Server开发者要写什么函数定义 schema 函数本体SKILL.md 说明文件 脚本/资源MCP Server 服务端 客户端配置主要解决痛点模型只会输出文本不会执行动作长提示词塞满上下文能力不可复用每个工具一套 API适配代码重复上手复杂度低中中高当前生态状态主流模型 API 均支持较稳定多厂商各自推进未完全统一开源协议生态增长很快这个表格可以当快速判断依据如果你的诉求只是“让模型能调一个函数”用 Tool Calling如果希望 Agent 掌握一整套流程比如“代码审查”“分镜脚本生成”“自动化测试”可以研究 Skills如果希望多个客户端共享一套工具服务直接做 MCP Server。2. Tool Calling 是什么模型侧的工具调用机制Tool Calling 是 AI Agent 最底层的基础机制。它的目标很简单大模型默认只输出文本但应用程序常常需要模型输出“我要调用哪个函数参数是什么”。Tool Calling 就是模型在生成回复时额外输出结构化工具调用指令的能力。2.1 底层流程拆解完整流程可以拆成五步第一步开发者向模型 API 提供工具描述列表。每个工具包括名称、描述、参数 JSON Schema。这些只用于让模型理解模型并不会执行函数。第二步用户发送 Prompt模型根据对话内容和工具描述判断是否需要调用工具。如果需要返回一个tool_calls结构而不是直接回答。第三步应用层收到tool_calls后执行真正的外部函数比如查天气、读写数据库、调用内部服务。此时模型已经下线。第四步将函数执行结果以tool角色的消息回传给模型。第五步模型基于结果继续推理输出最终答案。多轮工具调用同理循环进行。2.2 最小可运行示例下面以 OpenAI 旧版chat.completions接口为例写一个最小闭环。新版responsesAPI 结构类似逻辑不变。import json 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. 第一轮推理模型返回 tool_calls response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, ) # 3. 执行工具调用 msg response.choices[0].message messages.append(msg) if msg.tool_calls: for tool_call in msg.tool_calls: args json.loads(tool_call.function.arguments) if tool_call.function.name get_weather: result query_weather(args[city]) # 真实业务函数这里需要自己实现 messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 4. 第二轮推理得到最终回答 final_response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, ) print(final_response.choices[0].message.content)注意一个关键点模型只负责生成“该调用什么、参数是什么”真正执行的是你的应用代码。所以 Tool Calling 是“消息协议”不是“运行时”。权限校验、参数校验、结果缓存都要在应用层做。2.3 容易踩的坑模型不返回 tool_calls常见原因是工具描述不清晰、参数 schema 过于复杂或者模型版本本身不支持该能力。参数解析失败JSON 生成偶尔会带多余文本需要做容错解析。工具描述过长每个工具的 schema 都会占用输入 token工具数量多了会对成本和上下文长度带来压力。3. Skills 是什么可复用的能力包Skills 是比 Tool Calling 更高一层的抽象。它解决的是“复杂流程的知识和脚本怎么复用”的问题。一个 Skill 可以理解为一个自包含的文件夹里面包含说明文档、脚本、资源文件通过描述性文件告诉 Agent“什么时候用、怎么用”。3.1 Skills 和提示词的区别传统 Agent 扩展方式是把所有指令写进 system prompt缺点是提示词越长模型理解成本越高。多个能力的规则混在一起容易互相干扰。无法在运行时按需加载只能一次性全塞进去。Skills 的思路是“按需加载”。Agent 根据用户任务判断需要某个能力时再读取对应的 Skill 文件。这样上下文占用更低能力边界也更清楚。3.2 典型文件结构不同厂商实现有差异但大体思路一致。以常见的 Claude Skills 和 Codex Skills 风格为例目录结构大概是my-skill/ ├── SKILL.md ├── scripts/ │ ├── run.sh │ └── preprocess.py └── assets/ └── templates/其中SKILL.md是核心入口用结构化 Markdown 描述技能的用途、触发条件、执行步骤和输出格式。--- name: code-review-skill description: 用于对 PR 代码进行系统审查检查安全性、可读性和边界问题 --- # 代码审查技能 ## 使用时机 当用户要求审查一段代码或一个 PR diff 时使用本技能。 ## 执行步骤 1. 先读取 scripts/preprocess.py将 diff 转成统一格式。 2. 按顺序检查安全性、异常处理、可读性、性能。 3. 输出格式问题清单 严重级别 修改建议。 ## 注意事项 - 不执行代码只做静态审查。 - 所有建议必须注明具体行号和原因。模型读到这份文件后会按照里面的流程执行任务。脚本的作用是把重复动作自动化减少模型自主探索的随意性。3.3 Skills 为什么不等于 Tool CallingTool Calling 是“模型表达调用意图”的机制强调参数怎么传。Skills 是“模型按流程使用一套方法”的包强调流程怎么跑。一个 Skill 内部完全可以包含多个 Tool Calling 步骤也可以直接写脚本执行。两者不是同级概念自然不能直接二选一。3.4 当前生态状态目前 Skills 还处在快速演变期Anthropic 生态在推 Claude SkillsCodex 生态也在推类似的自定义技能各种社区项目如“skills 下载”“skills 开发”“playwright MCP 测试 Skill”等概念频繁出现。这意味着正式立项前要仔细看所选 Agent 框架的官方文档不同实现的SKILL.md字段约定和加载机制可能不兼容。4. MCP 是什么工具接入的统一协议MCPModel Context Protocol是目前三者中“工程味道”最重的一个。它由 Anthropic 开源目标是把“模型如何连接外部工具和数据源”这个老问题标准化。MCP 解决的是集成成本问题以前每个数据源或工具都要单独写一套适配代码现在通过统一协议接入一次多个 AI 客户端都能用。4.1 MCP 的运行架构一个最小 MCP 架构包含三部分MCP Host运行 Agent 或应用的进程比如 Claude Desktop、Claude Code、Cursor、VS Code Copilot 等。MCP ClientHost 内部用来与 Server 建立连接、发送请求的组件。MCP Server提供工具、资源和提示词的独立服务可以通过 stdio 或 HTTP 方式启动。协议层基于 JSON-RPC 2.0。核心方法包括initialize握手确认协议版本。tools/list获取服务端已经注册的工具清单。tools/call调用某个工具。resources/list、resources/read读取可暴露的资源文件。一次工具调用在协议层的表现大概是这样{ jsonrpc: 2.0, id: 1, method: tools/call, params: { name: get_weather, arguments: { city: 北京 } } }返回结果也是标准结构客户端拿到结果后再交给模型继续生成回复。4.2 最小服务端思路创建 MCP Server 的方式取决于所用 SDK。以 Python 官方 SDK 为例安装依赖的方式通常是# 常见安装模板按官方文档确认包名和版本 pip install mcp服务端代码一般需要完成三件事声明 Server 名称和版本、注册工具函数并给出描述、启动 stdio 或 HTTP 传输层。用新版 SDK 时社区更推荐 FastMCP 这类简化 API因为它把“注册函数、自动生成 schema、启动服务”封装得很短。具体字段以项目当前依赖的 SDK 版本为准。这里给一个更保守、更偏协议理解的服务端伪代码# 伪代码展示 MCP Server 的逻辑骨架不代表任何特定版本的完整 SDK API server create_mcp_server(nameweather-server) server.tool() def get_weather(city: str) - str: 查询城市天气 return query_weather_service(city) server.run(transportstdio)实际开发中你会先看所选 SDK 文档确认server.tool的注册方式再启动服务最后在 Host 配置里加上对应命令。4.3 对开发者的意义MCP 最有价值的地方在于“一次实现多端复用”。团队把内部工具封装成 MCP Server 后无论是 Codex、Claude Code还是自研 Agent都能用同一套协议调用。搜索热词里大量出现“figma MCP”“playwright MCP”“chat2db MCP”“IDA Pro MCP”“Unity MCP”等项目都是这个思路的体现把原本独立的软件能力统一暴露给 AI 客户端。5. 三者对比区别和组合关系5.1 最容易混淆的原因三个概念都经常出现在“让 AI Agent 更强大”的语境中很多教程标题又喜欢缩写导致读者很容易把“工具调用”“技能包”“协议”混为一谈。但它们的层次差异非常明显。对比维度Tool CallingSkillsMCP一句话定位模型怎么表达“我要用工具”Agent 怎么“按手册干活”工具怎么“统一接口接入”作用对象模型 APIAgent 运行时外部服务是否产生执行否只生成调用请求有一部分脚本会自动执行否只负责通信和调度标准统一程度各厂商有细微差异但大同小异多实现并存未完全统一协议开源相对统一单独使用效果能接一个或多个函数能复用一套复杂流程能统一接入多个服务项目落地难点参数校验、容错、安全流程设计、模型理解能力服务部署、权限、生命周期5.2 用生活场景理解Tool Calling 像“打电话的时候把话说清楚”你告诉对方“请帮我查北京天气城市名是北京”对方听完后再去执行动作。Skills 像“员工手册”新员工上岗时不清楚流程可以去翻对应的手册按步骤完成标准化工作。MCP 像“统一插座标准”原来每个电器都用自己的插头现在国际标准统一只要设备按标准生产任何房间都能接入。5.3 组合关系实际 Agent 项目里三者是配合关系不是替代关系模型 API 负责理解用户意图通过 Tool Calling 输出工具调用参数。Agent 编排层加载 Skills决定执行哪套流程。底层工具通过 MCP Server 统一接入客户端使用 MCP Client 调用。一个文件操作助手的例子你用 Tool Calling 让模型返回“复制文件、删除文件、压缩目录”等动作你写一个“目录清理技能”的 SKILL.md规定先扫描再确认再删除的顺序文件系统操作本身通过一个 MCP Server 暴露给 Agent避免直接让模型生成长串命令行。6. 实战建议先跑通 Tool Calling再封装 Skills最后上 MCP对于第一次接触这三个概念的开发者最优路径不是三个一起学而是按依赖关系递进。6.1 阶段一先用 Tool Calling 跑通最小闭环目标是让模型成功返回一次tool_calls并且应用层能正常执行、回填、输出最终回复。建议选择最简工具比如查询当天日期、计算两个数相加。不要一上来接数据库。验证清单模型是否返回 tool_calls。参数 schema 是否与真实函数一致。工具执行结果是否回填正确。多轮对话中工具调用是否稳定。6.2 阶段二把重复流程封装成 Skills当你发现某个场景每次都要写很长引导提示词时就有必要封装 Skills。先列出步骤再写 SKILL.md最后把可自动化部分写成脚本。脚本要能独立运行不要依赖模型推理才能执行。判断一个流程是否适合做成 Skill可以问三个问题这个流程是否频繁出现是否可以用固定步骤标准化模型的任意发挥是否会引入风险如果三个答案都是“是”优先做 Skill。6.3 阶段三多工具、多客户端场景再上 MCP如果你只做一个单体应用直接用 SDK 内置函数即可不需要先引入 MCP。当出现以下信号时再考虑 MCP多个 AI 客户端需要复用同一批工具。工具服务由独立团队维护。工具需要更细粒度的生命周期管理。MCP 的部署方案要先确认 transport。本地场景用 stdio 最稳远程服务需要 HTTP/SSE并且必须加认证和访问控制避免把内部工具裸奔到公网。7. 接口调试、批量任务与可观测性概念讲完落到工程侧不管用哪种方案调试和监控是绕不开的。7.1 接口调试的通用思路Tool Calling 调试可以分三层模型层、执行层、回填层。模型层主要看模型是否生成了合法的 tool_calls使用接口本身的日志或打印完整响应即可。执行层要单独为每个函数写单元测试确保输入输出稳定。回填层要验证 tool 消息是否正确关联tool_call_id这是多轮工具调用最容易出错的地方。MCP Server 调试时优先单独启动服务用协议客户端手动发tools/list和tools/call确认服务本身没有问题再去排查 Host 配置。7.2 批量任务接入 Agent 的注意点批量任务通常不是单个工具调用而是一组 Agent 任务。如果任务数量多建议每个任务独立记录请求 ID 和上下文。设置单次工具调用超时。对失败任务做重试但重试次数要有限制。限制并发数量避免把下游接口打爆。输出结果按目录或表格汇总便于人工复核。# 伪代码批量调用工具任务时记录状态 tasks [{city: 北京}, {city: 上海}] results [] for task in tasks: log_id create_task_log(task) try: result call_tool_with_timeout(get_weather, task, timeout10) results.append({task: task, status: ok, data: result}) except Exception as exc: results.append({task: task, status: failed, error: str(exc)}) finally: update_task_log(log_id, statusdone) print(results)7.3 可观测性在日志中至少记录四个信息模型请求上下文、模型返回的 tool_calls 完整内容、每个函数执行耗时、MCP 请求和响应的耗时。这样一旦 Agent 行为异常你能快速定位是模型判断错了、函数执行错了还是底层服务连接失败。8. 常见问题与排查方法下表总结了三种技术最常见的问题现象和排查思路。遇到问题时先对照表格定位环节再翻官方文档复查。问题现象可能原因排查方式解决方案模型完全不返回 tool_calls工具描述不清、模型不支持、tools 参数未传打印模型完整响应检查 tools 是否传入精简 schema补充工具描述换支持 Tool Calling 的模型tool_calls 返回但参数解析失败JSON 含多余文本或字段类型不匹配打印原始arguments字符串加 JSON 容错解析补充 pydantic/typed dict 校验多轮工具调用结果错乱tool_call_id 没有正确回填比对 tool 消息与 tool_call_id按 API 规范回填消息顺序和 IDSkills 一直不生效文件名、目录结构或描述字段不符合约定检查 Agent 日志里 Skill 加载路径按当前客户端文档调整 SKILL.md 字段和目录Skill 能加载但模型不按流程走描述不明确、流程顺序歧义观察模型下一轮输入是否包含 Skill 内容细化触发条件把关键判断写成脚本而不是让模型自由发挥MCP Server 启动后连接失败transport 不匹配、端口冲突、握手失败单独用客户端发 initialize 请求检查启动命令、端口、日志确认协议版本MCP tools/list 返回空工具注册失败或 Server 启动异常查看 Server 端日志确认注册函数被正确加载检查依赖版本多个工具重名导致调用冲突命名空间未隔离打印工具完整名称工具名加前缀或在注册时手工重命名批量任务中途卡住超时设置过长或异常未捕获查看任务日志和并发数量加单任务超时、失败重试和队列策略本地推理场景显存或内存异常模型推理与 Agent 逻辑共用资源分别观察服务进程的显存和 CPU 占用将模型服务与工具服务分离部署排查顺序建议固定为“服务端 - 协议层 - 模型层”。先确认服务能连通再确认协议消息正常最后再检查模型判断和提示词问题。按这个顺序可以快速缩小范围。9. 总结与下一步把三个概念放回同一张图里结论非常清晰Tool Calling 是模型表达工具调用意图的机制是基础能力Skills 是 Agent 按需加载的标准化流程包是能力复用手段MCP 是统一工具接入的开放协议是服务集成标准。三者解决不同层次的问题不是竞争关系。如果你的项目刚开始建议先写一个 Tool Calling 的最小 demo定义一个函数让模型调用一次确认第二轮回填逻辑正确。这个闭环跑通后再把常用的复杂流程抽成 Skill 文件。当出现多个客户端共享工具或工具由独立团队维护时再封装 MCP Server。最容易踩的坑有两个一是把 Skills 当成万能方案实际上模型对复杂 Skill 的理解能力有限关键流程能写脚本就写脚本二是跳过安全设计直接暴露工具服务尤其是 MCP Server务必限制访问范围、做好认证和日志审计。涉及文件操作、数据库写入、外部系统调用时先走权限最小化原则。批量任务也建议先小规模验证再逐步加并发。这三个技术方向更新都很快尤其是 Skills 和 MCP 的生态仍在膨胀。写代码前先确认你所依赖的 SDK 和客户端版本避免收藏一套过时 API。建议收藏这份对照表后面遇到 Agent 工具接入问题可以先回来定位层次。