做 AI Agent，先分清 MCP 和 Skills

什么时候用MCP，什么时候用Skills。

看完，你就会清楚他们的使用场景和区别。

首先，我们先从大模型本身说起。

你可以把大模型理解成一个预测机器。它读过很多书、网页、文档、论坛帖子，然后根据这些信息里的模式，去回答各种问题。

比如你问它，唐朝的发展历史。它会知道。

你问它，怎么检查一个数据库。它也知道一些通用做法。

但真正想让它给出正确答案，光靠“它知道很多”是不够的。

更关键的是，你要给它正确的上下文。

这个上下文可能包括很多东西。

比如你希望数据按什么格式输出。

比如你们团队的数据库是怎么配置的。

又比如某个工具刚刚去数据库里查了一次，把查到的结果返回给模型。

如果只是告诉模型一个角色、一个任务，让它回答问题，这通常叫提示词工程。

但如果你开始把格式要求、外部数据、工具返回、业务规则这些信息一起给它，让它基于这些上下文做判断，这就更接近上下文工程。

简单说，提示词工程更像是“怎么问”。

上下文工程更像是“怎么把它做判断需要的信息准备好”。

那问题就来了：

我们到底怎么把正确的上下文交给 AI？

又怎么在这个基础上，去做一个真正能干活的 Agent？

先看 MCP。

假设你的 Agent 需要读取 CRM，也就是客户关系管理系统里的数据。

一种很粗糙的做法是，把这个系统的 API 文档复制给大模型，再把访问凭证也给它，然后跟它说：

请你更新一下这个客户的联系方式，千万别出错。

这听起来就不太稳。

因为你其实是在让模型自己理解文档、自己判断怎么调用接口、自己处理认证和请求格式。

MCP，也就是 Model Context Protocol，解决的就是这个问题。

它做的事情，是把 AI 模型和各种数据源之间的沟通方式标准化。

你可以把它理解成一个中间层。

它把服务 API 包装成大模型更容易使用的格式，同时处理认证、权限、读写范围这些事情。

在背后，MCP server 会接到 AI 应用或开发环境里的请求。模型会提出自己需要什么信息，MCP server 再把这个请求翻译成真正的接口调用，比如一次查询请求，或者一次更新请求。

然后服务返回结果，再把结果放回模型的上下文窗口里。

这样一来，AI 不需要直接拿着一大段接口文档去猜，而是通过一个标准层去访问外部数据源。

所以，MCP 更适合解决什么？

一句话，解决“怎么把外部数据和工具安全、标准地交给模型”。

但这里还有一个问题。

MCP 可以帮模型拿到外部数据，可是它不一定知道你们团队希望这些数据怎么被处理。

比如同样是从 CRM 里读取客户资料，你们销售团队可能要求每次都按固定格式输出：

客户姓名，联系方式，最近一次沟通记录，还有客户更偏好的沟通方式，比如微信、电话，还是企业微信。

这个例子很具体，但问题也很真实。

如果你希望模型每一次都用同一种格式、同一种规则、同一种流程来做事，只靠临时提示词就会比较累。

因为大模型本身不是完全确定的，同一个任务，它可能今天这样写，明天那样写。

这就是 Skills 的价值。

Skills 更像是给模型准备的一套可复用能力包。

里面可以有一个 Markdown 文件，写清楚这个 Skill 叫什么、什么时候使用、具体该怎么做。

它还可以带上一些资源文件、示例，甚至脚本。

比如你经常用大模型清理 Excel 文档，检查代码，运行某种验证，或者做合规检查。

这些固定提示词、固定步骤、配套脚本，都可以打包成一个 Skill。

更重要的是，Skill 可以在需要的时候自动加载进模型上下文里。

比如你问的是代码错误，它才加载代码调试相关的 Skill。你问的是文档整理，它再加载文档整理相关的 Skill。

这样就不用每次手动把一大堆规则重新复制给模型。

现在再回到刚才的问题：

什么时候选 MCP，什么时候选 Skills？

如果你的 AI 应用需要访问实时数据，而且要用比较受控、有权限边界的方式访问，那 MCP 更合适。

比如你想问，某个客户的最新信息。

这些都属于“AI 需要去外部系统拿数据或调用工具”。

但如果你只是想给 AI 增加一个可复用的自定义能力，那配置 MCP 可能就有点重。

这时候 Skills 更合适。

因为 Skills 比较轻量，它教模型怎么做一件事。

比如获取投资数据并分析，或者使用 Skill 里附带的脚本和示例来完成某个任务。

所以你可以这样理解：

MCP 更像是 Agent 和外部工具之间的集成层。

Skills 更像是模型完成某类任务时的说明书和工具包。