分清MCP与Skills，AI Agent的正确打开方式！一文解析两者区别及使用场景。
核心内容：
1. MCP的定义与作用：Model Context Protocol作为中间层标准化外部数据调用
2. MCP与提示词工程、上下文工程的区别：明确不同AI应用场景的处理逻辑
3. MCP解决的关键问题：安全、标准地将外部数据和工具接入AI模型

哪些时候该用MCP，哪些时候更适合Skills。

读完之后，你会了解它们各自的使用场景以及区别。

首先，从大模型自身谈起。

大模型可以被理解为一台预测机器：它阅读过大量书籍、网页、文档和论坛帖子，再依据其中呈现的模式回答不同问题。

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

再问如何检查一个数据库，它也了解一些通用方法。

不过，要让它真正给出正确答案，仅仅“知道很多”还远远不够。

更为关键的是给它提供正确的上下文。

上下文中可能包含许多不同信息。

例如，你要求数据采用什么格式输出。

又如，你所在团队怎样配置数据库。

还可能是某个工具刚完成数据库查询，并把结果交还给模型。

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

当格式要求、外部数据、工具返回以及业务规则被一并提供，让模型根据这些上下文作出判断时，这就更接近上下文工程。

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

所谓上下文工程，更像是准备好模型作出判断所需的信息。

于是问题出现了：

怎样才能把正确的上下文交给AI？

又该如何在此基础上构建真正能够工作的Agent？

先来了解MCP。

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

一种较为粗糙的做法，是把该系统的API文档和访问凭证都交给大模型，然后告诉它：

请更新这位客户的联系方式，务必不要出错。

这种做法听起来并不稳妥。

因为这等于要求模型自行理解文档、判断接口调用方式，并独立处理认证与请求格式。

MCP，即Model Context Protocol，正是为了解决这一问题。

它的作用，是将AI模型与各种数据源之间的沟通方式进行标准化。

可以将它看作一个中间层。

服务API会被它封装成大模型更易使用的格式，认证、权限以及读写范围等事项也由它处理。

在背后，AI应用或开发环境发出的请求会由MCP server接收。模型先提出所需信息，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则像模型执行某类任务时使用的说明书与工具包。

登录查看剩余 70% 内容