工具调用、MCP、Skill……这些 AI 术语到底在说什么?

随着 AI Agent 的快速发展，特别是像 OpenClaw 这样应用的大爆发，许多原本只在开发者圈子里流通的 AI 概念开始涌向普通用户：工具调用、MCP、Skill……用户接收了一堆术语轰炸，却不知道这些东西到底解决了什么问题，它们又是怎么一步步被发明出来的。

这篇文章的目的就是从源头讲清楚这些概念。我会沿着 AI 模型发展过程中真实遇到的问题，讲述每个概念被发明的背景和动机，让你理解它们为什么存在，以及它们之间的演进关系。

AI 模型在做什么

在聊各种花哨的概念之前，我们先回到最根本的问题：大语言模型（LLM）到底在做什么？

答案简单得出乎意料：预测下一个词。

当你输入「我今天去」这几个字时，模型并不是理解了你要表达的意思，然后给出回应。它做的事情是计算一个概率分布：在「我今天去」后面，接「公园」的概率是 45%，接「学校」的概率是 30%，接「超市」的概率是 25%，然后从中选一个输出。接着在「我今天去公园」后面继续预测下一个词，如此循环往复，直到生成完整的回答。

这就是所谓的自回归语言模型。整个 ChatGPT、Claude、Gemini 等对话 AI 的底层都是这个机制。它的训练数据来自互联网上海量的文本，通过学习词与词之间的共现关系，模型掌握了一套极其复杂的概率模型，这让它看起来好像”懂”了语言，但本质上仍然是一台精密的下一个词预测机器。

这个理解非常重要，因为它直接决定了后面所有概念存在的原因：一个只能输出文字的模型，如何能查天气、写代码、生成 PPT？这就引出了我们的下一个话题。

让 AI 使用工具

既然模型只能生成文字，那它怎么做到「查一下今天的天气」这种需要调用外部服务的事情呢？

这个问题最早的系统性解决方案来自 2022 年底的一篇论文，提出了 ReAct（Reasoning + Acting）框架。核心想法是让模型按照「思考 → 行动 → 观察」的循环来完成任务：

1. Thought（思考）：模型先分析当前情况，决定下一步应该做什么

2. Action（行动）：模型输出一个工具调用的指令，比如调用天气 API

3. Observation（观察）：系统执行这个调用，把结果返回给模型

4. 模型拿到结果后，回到第一步继续思考，直到任务完成

这个思路非常优雅，但在工程实现上，早期的做法却很粗糙。

最初的方案是在提示词里告诉模型：”当你需要调用工具时，请按以下格式输出”，然后由外部程序去解析模型输出的文本，提取出工具名和参数，执行后把结果喂回给模型。类似这样：

【调用工具】查天气【参数】城市 = 北京

这个方案能跑通，但问题很明显：

• 指令跟随差：模型经常不按约定格式输出，少个标签、多个换行、参数写错位置，都是常有的事

• 不稳定：同一个问题问两次，可能一次输出了正确的 XML，下一次就输出了一段自然语言解释

• 难以扩展：当工具数量增多、参数结构变复杂时，纯靠提示词约束模型输出格式变得越来越不可靠

这个阶段的工具调用，本质上是在靠「文字约定」来让一个「文字生成器」做「程序调用」的事，先天就不够可靠。

转折点出现在 2023 年 6 月，OpenAI 推出了 Function Calling 功能。这次不再是用提示词去「拜托」模型输出特定格式，而是在模型层面原生支持了工具调用：开发者预先告诉模型「你有哪些工具可以用、每个工具需要什么参数」，模型在需要时会直接输出格式严格的工具调用指令，而不是自由发挥的文本。

这是一个根本性的改进。模型经过专门的训练来理解和生成工具调用，输出格式固定、解析可靠、调用稳定。很快，Function Calling 成为了行业标配，Claude、Gemini、通义千问等主流模型都跟进支持了类似能力。

至此，让 AI 使用工具这个问题在技术层面基本解决了。但新的问题随之而来：工具从哪来？

MCP

Function Calling 解决了模型怎么调用工具的问题，但它没有解决工具从哪里来的问题。

想象一下这个场景：你正在开发一个 AI 助手应用，用户希望它能查高德地图的路线规划、能读写飞书日历、能搜索语雀的文档、能帮忙操作微信读书的书架。每接入一个服务，你都需要去读对方的文档、处理登录认证、编写对接代码、跟着对方的版本更新不断维护。

这对开发者来说是一场噩梦。每个企业的接口风格不同、认证方式不同、数据格式不同，而且这些接口还在不断变化。开发者不可能为每一个第三方服务都手动编写集成代码，这在工作量和迭代速度上都不现实。

2024 年 11 月，Anthropic（Claude 的母公司）提出了 MCP（Model Context Protocol，模型上下文协议） 来解决这个问题。

MCP 的核心思路是：制定一个统一的标准协议，让所有第三方工具都按照这个协议来提供服务，AI 应用只需要实现一次协议对接，就能接入任何符合标准的工具。

用一个类比来理解：MCP 就像 USB 接口标准。在 USB 出现之前，键盘、鼠标、打印机各有各的接口，买根线都要先搞清楚型号。USB 统一之后，任何设备只要符合标准，就能即插即用。MCP 对 AI 工具调用做的是同样的事：高德地图按照 MCP 的规范把路线规划能力包装好，任何支持 MCP 的 AI 应用拿来就能用，不需要再单独对接。

MCP 提出后，生态发展迅速。高德地图、飞书、支付宝、阿里云等国内主流服务纷纷提供了官方的 MCP 接入，国外的 GitHub、Slack 等也同步跟进。各大 AI 应用如 Cursor、Windsurf、Cherry Studio 等都支持了 MCP 协议。可以说 MCP 正在成为 AI 工具集成的事实标准。

Skill

到目前为止，我们有了能预测下一个词的模型、有了让模型调用工具的能力、有了标准化接入第三方工具的协议。但还有一个关键问题没解决：如何精确控制模型的行为？

这就是 Prompt Engineering（提示词工程） 的领域。我们可以给模型写一份系统提示词，告诉它应该扮演什么角色、遵循什么规则、按照什么流程来处理任务。比如一个客服机器人的工作手册可能会规定：先问候用户，然后分类问题，查询知识库，给出回答，最后确认是否解决。

提示工程在实践中非常有效，但随着应用场景变复杂，一个严重的问题浮出水面：

• 能读的内容有限：模型每次对话能处理的文本量是有上限的，当你需要模型掌握 20 种不同场景的处理流程时，这份工作手册会变得极其臃肿，塞不下

• 不管用不用，全部加载：即使用户这次只是想查个天气，模型也要读完所有场景的指令，这既浪费资源，也让模型的注意力被大量无关内容分散

• 难以维护和复用：当工作手册变成了几千行的万能说明书，修改一处就可能影响其他场景，不同应用之间也无法共享这些能力描述

Skill 就是为了解决这些问题而诞生的。

Skill 的核心理念是渐进式披露。与其把所有指令一次性灌给模型，不如只告诉模型你有哪些技能可以用，以及每个技能的简短描述和适用场景。当模型判断当前任务需要用到某个技能时，再去动态加载该技能的完整指令。

举个具体的例子。假设一个 AI 写作助手有以下几个 Skill：

• 学术论文排版 / 适用于用户要求写或修改学术论文格式时

• 小红书文案 / 适用于用户要求写种草、测评类短文案时

• 技术博客 / 适用于用户要求写技术教程或概念解释文章时

模型在接到任务时，先看这个简短的列表就够了。当用户说”帮我写一篇人工智能的教程”，模型判断需要「技术博客」这个 Skill，于是去加载它的完整内容，里面可能包含详细的结构模板、代码示例规范、配图要求等。而其他两个 Skill 完全不需要加载，节省了大量的空间。

这种渐进式的加载甚至可以嵌套。一个 Skill 的内部可能还有子模块，模型可以根据任务的具体需要，进一步选择性加载。

Skill 不仅仅是指令文本，它还可以包含完成任务所需的资源和脚本。比如一个「数据可视化」的 Skill，除了告诉模型怎么画图之外，还可以附带图表模板文件、配色方案、示例数据等。这让 Skill 从一段指令变成了一个完整的能力包。

从结构上看，一个 Skill 的核心就是一个 SKILL.md 文件，它的头部声明了该 Skill 的名称、描述和适用场景，正文包含详细的执行指令。这种设计让 Skill 天然具有可分享性，本质上它是一套标准化的 SOP，任何人都可以编写自己的 Skill 并分享给其他人使用。

上图是一个典型的 Skill 结构，这是一个处理 PPT 的 Skill，除了核心的 SKILL.md 文件外，还包括处理 PPT 文件的程序脚本，以及一些和程序脚本执行相关的文件说明。

需要强调的是，Skill 不是什么黑科技。它的本质仍然是提示词，底层机制和提示词工程一样。甚至 Skill 的按需加载本身，用的也是前面讲过的工具调用：应用把「列出可用 Skill」、「读取某个 Skill 的内容」封装成工具，模型在需要时主动调用这些工具来获取指令。所以 Skill 并没有引入任何新的底层机制，它只是在工具调用和提示词之上做了一层巧妙的组织。

它真正的创新在于两点：一是把加载时机的决策权交给了模型本身，实现了按需加载；二是统一了规范，让能力描述变得模块化、可组合、可分享。

总结

最后，让我们把整条线串起来。

大语言模型的本质是预测下一个词，它只能输出文字，不能直接操作外部世界；工具调用让模型突破了纯文字的限制，通过 Function Calling，模型可以调用外部服务来查天气、读文件、搜网页，虽然它自己只是输出了一条”请帮我调用这个工具”的指令，但配合外部程序的执行，效果就像它真的”动手”了；MCP 让工具接入变得标准化，就像 USB 统一了硬件接口一样，MCP 统一了 AI 工具的接入方式，让生态可以规模化发展；Skill 让模型的能力可以按需组装，不再把所有指令一股脑塞给模型，而是像技能树一样按需加载，让模型在有限的注意力里专注于当前任务。

这四层能力层层递进：模型产生语言，工具调用让语言驱动行动，MCP 让行动的范围无限扩展，Skill 让行动的质量精确可控。理解了这条演进脉络，你就不会再被层出不穷的新名词搞晕，它们本质上都是在回答同一个问题：怎么让一个只会写字的模型，变成一个真正能可靠做事的助手。